Anyone interested purely in the science and art involving the representation and transmission of information can learn valuable technical lessons from the official website of Jehovah’s Witnesses: jw.org. Religious views aside, the content management and distribution system is nothing short of astonishing.

The simple-looking interface is deceptive. From the landing page, a user can access identical textual messages in over 1,052 human languages—representing vastly disparate character systems. These are accurately encoded and rendered to your browser without requiring plugins or extensions. Similar feats are accomplished with video content, synchronized media streams, and translated audio.

The mind-blowing aspect is that no-one is paid to provide or deliver this system. This, I would venture to say, is worth a closer look.

The attached (or linked) visualization correlates the TCP model of internetworked systems, and proposes a distinction between “infrastructure” and “applications”, purely for practical working reasons.

Please contact me to let me know if you found some value in this diagram.

I outlined this perspective model in my private time, on my own computers while serving as the Infrastructure Architect for the City of Richmond, VA. Nothing happened, and please note that everything there is butterflies and rainbows and unicorns and bluebirds of happiness.

The attached visualization correlates the TCP model of internetworked systems to IT services, and proposes a distinction between “infrastructure” and “applications”, purely for practical working reasons. Please do contact me to let me know if you find some value in this diagram.

I’ll have to do some research and have a word with Sir Tim Berners-Lee on this one. I don’t believe it has been done yet. But the title has given it away, too :-)

The problem of “burgeoning complexity” has rendered the Internet almost useless as a tool to rapidly identify accurate and correct information. Distinguishing published “signal” from “noise” is a challenge that massive collaborative technology itself has not met.

Google, Wikipedia and other notable efforts exist to sort and aggregate the “noise.” Various innovations have approached ‘truth’ problems from important angles, but at best address only one or two critical failings (or logical fallacies) of previous efforts.

This work outlines a mathematical and technical methodology “Towards an Effective Global Information Management System.” I present ideas crossing disciplinary field boundaries; although no rigorous mathematics are presented, I assume the reader has a strong computer science, engineering, and/or mathematics background, and “architecturally” understands first principles of:

* Cryptography,
* Game theory,
* Distributed computing,
* Linguistics,
* Logic,
* Neural networking,
* Statistical analysis,
* Very Large Scale Intergation (VLSI), and
* Queuing theory.

In the course of researching this work, we applied biomimetics by simulating dual-processor systems programmed to function according to theoretical models of the human brain.

Investors are invited to learn more. For more information, please contact me using my first name (Dave) [at] streamlines [dot] biz.

Colleagues and friends have requested copies of this diagram, which was prepared for and presented at ESRI’s national workshop on “Community Risk Reduction”. Enjoy!

Still. Please stay tuned.

These are our experiences testing IBM’s LotusLive services. (NOTE: LotusLive is now being called “IBM SmartCloud for Social Business”, as of March 2012). We used LotusLive Notes (LLN) and LotusLive Engage (LLE) services over a period of one year.

The observations are presented in the chronological sequence that we
encountered them (earliest at the top). Perhaps the earliest points have now
been addressed by IBM. The last two points (9) and (10) merit consideration.
This information is accurate as at 2012-03-06.

1. The LotusLive onboarding business process seemed unclear even to IBM employees. We initially contacted IBM on December 17, 2010, and were clear in our service request. We had already ensured that the only technical requirement for us to engage IBM’s service was for us to “flip a switch”—a ten-second change. It took IBM nearly a full two months to process the business aspects of our engagement and to then direct us to flip the switch. Our service began mid-February 2011.
2. One year of commitment on our part was mandatory.
3. The mechanism for us to submit our payments by credit card to IBM (via their website) failed.
4. IBM lost some of our mail (PMR #01445,000,000- 1008), at a point in time well after we had confirmed that mail for our users was successfully being delivered to IBM servers. Something happened on the IBM side which caused their systems to lose about a week’s worth of messages. We missed business-critical information and lost opportunities as a result.
5. Security issues were observed and reported in March 2011: uninvited “guests” (mostly with IBM domain email addresses) were showing up in our LotusLive lists of users and contacts. A fix was applied May 7, 2011.
6. There is no programmatic way to upload (or import, if you prefer) our historical mail data (to thereby create a single searchable mail repository for us). This fact forced us to maintain access to two systems simultaneously (e.g. for practical business use, e.g. in order to search historical data)
7. We requested an API key for programmatic integration ( submitted exactly as described in IBM’s documentation), but received neither the key nor a reply to our actions performed as directed (https://www.lotuslive.com/en/businesspartners/info).
8. The LLN web interface offers no way to insert HTML code (e.g. tabular-formatted data from an external app) into messages. This is being handled as an “enhancement request.” We are unaware of a projected date for a resolution.
9. LotusLive Engage public surveys display a warning at the top of the survey form, including the words “Warning: …Submit only if you trust the user.” This message is shown to all potential survey responders, and creates distrust on their part.
• Responders are reluctant to click on any Web content displaying such a warning.
• Any business value of a LLN public survey is diminished (or lost entirely). A public survey should not display a warning when viewed by the public.
• This behavior was initially handled as a “defect” on a support ticket (RTC Defect Ticket #: 73375), but later was flagged as an “enhancement request”. We are unaware of a projected date for a resolution.
10. LotusLive Notes customers using a “no-Domino server on premises” model are unable to retain their company’s data in any common readable or usable format. IBM provides no mechanism, programmatic or otherwise, for mail data retention or migration. There is no way to transition the data from LotusLive Notes to LotusLive iNotes (which might allow easier local retention). IBM’s support has advised one of these options for Notes customers to retain mail data:
• Install a local Notes client, then
• For each user, configure Notes to download and save a local NSF file (a
  useless proprietary file without a local Domino server)
• Convert the NSF to something useful with a purchased third party solution/service
• Install a local Notes client, then
• For each user, drag 55 emails at a time into a local folder, thereby creating 55 EML files.
• Repeat until all desired messages are saved as EML files.

This last item (10) is critical; We would sincerely welcome feedback from IBM
partners (or any other IT providers) for a data retention solution. Please share
one here if possible, or else contact me privately ( dave [at] streamlines [dot]
biz ).

We intentionally omit mentioning feedback we received from IBM when we requested consideration of these matters. The feedback itself is—in our opinion—sufficient for making a business decision for your enterprise and/or your Clients. Again, please contact me privately if you are interested.

Taken together, the collection of observations is leading us away from IBM LotusLive (now SmartClould for Social Business) for our solutions. Robust and mature alternatives exist and in some cases are free. As an example, consider our selected solution to item (9)—we replaced this IBM functionality with this Google Apps capability. The superiority of this Google Apps solution over IBM’s is self-evident.

We hope this information proves useful to anyone considering IBM SmartCloud for Social Business.

Traditional plain old telephone systems (POTS) worked with a simple binary result. From a design perspective, a call was either made (the line rings) or the line was busy.

Later, voicemail extended that model by introducing something than can be considered as an intermediate system state, depending on the duration of the ring. Functionally, the original communication is intercepted, the message queued for later delivery.

Today, smartphones, network provider capacity, and IP telephony allow complex communication system scenarios among hardware vendors, application developers, and telcos.

We propose that a given caller, in the event of a “busy” or “service unavailable” condition, should be able to receive a CUSTOMIZED message, pre-recorded by the subscriber and matched to the identity of the inbound caller. Several architectural executions of this function are possible.

In practice, let’s say you knew your phone’s battery was about to die, or let’s say you knew beforehand that you’d be in a lobby where no cellular calls are permitted. Or perhaps you are going to be driving and don’t want to be distracted by any conversation. Nonetheless, you are expecting important calls.

Our proposed system would recognize the inbound caller (by caller ID), and deliver a unique message (which you have pre-designated only for that caller and/or that time of day). Three different callers might try to reach you (at around the same time) while you (not your machine) are in this state, and our system processes them, as follows:

Your calling family member might hear: “Honey, I’m tied up but I’ll be there in 15 minutes!”
Your calling boss might hear a more professional: “I’m not available right now, but I’ll definitely get the report off before the end of the day!”
You client might hear: “I’m not at my desk right now, but please leave me a message.”

Our system can define groups of inbound callers for a single message. It may ensure that certain specific callers always receive your unique denial of service message (irrespective of the device/or network’s availability). Further, these and other features may be configured, then enabled or disabled at will by the subscriber, using the handset only.

The end result is a dynamic network that is personally tailored—adapting to and serving the desired state of the human endpoint (as opposed to simply the handset’s state).

Mobile subscribers today are still forced to work within service constraints that evolved from the POTS. Unfortunately, they have come to believe that “accept call” or “reject call” are the only decisions they can make to govern their service and describe their availability status—“Let it go to voicemail” or not. Given today’s technologies, that model is outmoded and mediocre, at best. Our proposed adaptive messaging platform empowers creative communication patterns among subscribers, and may even encourage future generations to re-discover the value of human interaction via the spoken word.

Questions? Call Dave at 352-505-7885.

The fundamental failure of IBM’s “Watson” is that it was designed to ANSWER questions. It should have been designed to ASK them.