Date: Wed, 21 Feb 2001 10:24:22 -0500
Mr. Rod Welch
rowelch@attglobal.net
The Welch Company
440 Davis Court #1602
San Francisco, CA 94111 2496
415 781 5700
| Subject: | Action Plan |
Rod,
[Responding to your letter on February 20, 2001..... ]
You said [in the SDS record on February 11, 2001, linked to the record on February 17, 2001, which is cited in the letter on February 20, 2001....]
161725 - Most likely the principles are thinking of SDS as a component "data 161726 - base," rather than an "intelligence" support engine for carrying out 161727 - the work. Actually, you have provoked me to make some improvements to my /ohs/ web site which I cannot do at this time owing to getting a book manuscript to Addison Wesley within the next few weeks.Here is a summary of what I think I will illustrate there, in words. The punch line is this: I think you got it backwards.
I originally drew, with the help of Mary Keeler, a three layer architecture. At the top, I had a user interface -- a kind of viewing portal into the insides. The insides were comprised of two other layers. At the bottom, I called the layer the raw data (even legacy data) layer. In the middle, I had a knowledge layer. There, an ontology and link database would emerge while users at the top create more content at the bottom.
Lee Iverson drew a three-bubble diagram that in every respect does the same thing. One of his bubbles is called Content. That's my raw data layer. One of his bubbles is called Knowledge. Direct hit on my middle layer. His third bubble is called Context, which, I think is a much better way to describe my user interface layer. Lee did a much better job of thinking that layer through than I did.
In any case, SDS is functionality at the Context layer, and I think you can see how that makes sense.
Now, to fix what you said as listed above, SDS (in my view) is not a database. It is a content generator, one that clearly implies putting context on content. The Content/RawData layer will serve as the database for SDS. By doing that, mining SDS work product for ontology is automatic.
Here's where things get interesting. SDS, itself, generates links, all within the Content/RawData layer. It will be quite interesting for the Knowledge layer to think about the nature of those links, not to mention the words being used.
In some sense, I think SDS is an extremely interesting Content generator. What is particularly interesting is that its work product represents an individual user's *view* of events that it composes. Imagine what happens when several individuals place SDS work product based on the same events into the same Content space. That's food for a great IBIS discussion, which, itself, is another Content generator. The possibilities here are endless. I would think that such a system, in the context of Lexus/Nexus-like work would be of enormous value, not to mention thinking about the energy crunch, etc.
Jack
Jack Park
jackpark@verticalnet.com
John J. Deneen"
Copy to: