Please see my letter on your important ideas to improve SDS, and the need to
gain experience doing KM in order to learn how to build better tools....
Jack Park wrote:
> Interesting that you should land on a paper about HyTime. HyTime, not
> presently standardized in XML (but nevertheless do-able in XML with a bit of
> fudging), is the answer to our prayers, me thinks. Linking, and Time.
> Together in one package; a most useful package, that.
> Your question hits the target I have been painting for some time now. This
> might be longish. Sorry.
> Consider this:
> What SDS does:
> provide a home for source information
> provide a linkage pool with commentary that connects various ideas,
> themes, temporal coincidence, and so forth together
> What SDS should do:
> all of the above, plus:
> provide a navigation engine
> Hah! You thought I'd list more than that under "should do". Well, there is
> more. It needs to develop on ontology for itself by which users can do the
> navigating. Doing that will allow SDS to link up with other SDS engines to
> form a web-based collaboratory. Then, you add, per Eric's suggestion, IBIS.
> This allows for a mechanism by which collaborative SDS implementations can
> communicate with each other. Of course, there are humans doing all this,
> but the engines can, and should automate some of the "backoffice"
> bookeeping. By automating that, we get uniformity in the ontology
> generation. Thus, we get (or, at least, strive for) semantic
> When you have done that, you have, in fact, constructed the three-layer
> architecture I have been harping about for some time now. I do not claim
> that the three-layer architecture is complete; rather, I suspect that it
> represents a kind of minimalist architecture for performing the OHS/DKR
> functionality. By way of brief review: at the upper level, topic maps and
> IBIS interface, plus import/edit facilities for generation of major "papers"
> to submit. In the middle, the vast array of ontology nodes and links. At
> the bottom, all the raw information, which includes: papers, scanned in
> books, email, personal commentary, IBIS argumentation records, and, well,
> perhaps the kitchen sink as well <gg>. Key concept: everything in the
> bottom layer is an instance of an "addressable thing" according to the OHS
> ontology that Howard is developing. Being an "addressable thing" means that
> all elements of the documents in the bottom layer are somehow addressable.
> It turns out that the Grove architecture (an SGML notion, now doable in XML)
> makes everything into an "addressable thing". In fact, a Grove gives you a
> uniform API for addressing a heterogenious pool of things, each of which
> might have a different API requirement (e.g. Word documents, XML documents,
> RDF documents, LaTex documents, Excel spreadsheets, etc). This all suggests
> that a part of the middle layer "engine" will be something akin to a Grove
> Yet another part of the middle layer is an engine that maintains "knowledge
> structures" (KS). Think of KS as nodes and arcs. Well, it's not going to
> be all that simple in the long run, but that's a place to start. KS must be
> capable of existing in an evolutionary environment, one which evolves as
> knowledge representation (KR) needs change. The engine must be, itself,
> evolvable. This implies extensibility, a plug-in architecture, and so
> forth. There are many other specifications I could list for the middle
> layer, but I'll hold that for later.
> With respect to the bottom layer, SDS as it is presently implemented,
> appears to duplicate all its raw data rather than link to original sources.
> This, to me, makes perfect sense if you exist, or plan to exist in an
> environment that should remain isolated and unreliant on the availability of
> source information. In some OHS applications, particularly those where,
> say, a large enterprise hosts a private OHS with lots of OHSettes scattered
> about its intranet, then a central repository makes some sense. For a major
> web-based OHS community, perhaps a central&mirrored repository makes sense.
> Now, to the notion of "daily working activity." There are two parts to
> this. One is the real-time automatic aspect, and the other is the
> individual contributions (e.g. Rod's summaries). Let's think about these
> two, one at a time, starting with individual contributions.
> Reading any of Rod's links shows that his contributions are comprised of two
> temporal and conceptual coupling -- links with summary statements
> personal commentary -- thoughts, extensional/projective,
> Given an evolving ontology, it becomes possible to perform some of the
> temporal and conceptual coupling automatically, and, even notification to
> subscribers of the links found such that those users now can come in and add
> their personal commentary -- perhaps through an IBIS interface.
> Automatic action should be real-time, always active. This means that, as new
> information is deposited into a repository (bottom layer), it is
> automatically scanned, reduced to its ontological elements (some will exist,
> others may be new to the system <note>this is the hard part</note>), and a
> linking engine started. <note>doing the ontology thing is saved for another
> post</note>. None of this exists in SDS at this time, so far as I can tell.
> My comments to Rod have always been that SDS needs this capability, but it
> cannot exist, IMHO, until some commitment to an ontology engine is made.
> When linking is done, subscribers are notified (e.g. by email), complete
> with appropriate response URLs which, presumably open an IBIS interface
> ready with the new information to which a response is solicited.
> I have just described a system that enables the collaborative construction
> of knowledge. Let me recite the underlying assumptions:
> knowledge, itself, is a human-centric notion and cannot be "contained"
> anywhere else but in meat-space.
> knowledge can be *represented* in the form of statements, icons, links,
> whatever, which evoke responses when meat-space is exposed to those
> knowledge representations are never the *territory*, they are only the
> *maps* to the territory.
> constructing a concensus ontology is:
> very hard (some would say, impossible)
> worth doing if semantic interoperability is desired
> concensus ontologies are most useful in specific (often called
> *vertical*) domains
> a common *upper* ontology to which all vertical domains are anchored
> allows for eventual discovery of links between domains (analogies, etc).
> <note>a favorite illustration of analogical links between domains, as often
> used in the AI community, is that of the mapping of the *divide and conquer*
> military notion into the radio therapy domain</note>
> In the very long run, the notion of hanging domains on a common *upper*
> ontology enables a background discovery process to run on a continuous
> And, IMHO, all of this supports the concept of Knowledge Management (KM).
> And, what is KM? Who knows? What I have stated here wants to surround
> Doug's notion of CODIAK ( http://www.bootstrap.org/augment-132811.htm ).
> Doug speaks of:
> Intelligence Collection (IC)
> Dialog Records (DR)
> Knowledge Product (KP)
> My three-layer architecture provides an archive and interface for
> information flowing in from some environment (IC). That environment
> includes users manipulating the archive (solely) by adding new commentary
> and participating in IBIS-based dialogs (DR). Finally, there is the KP.
> What is that, or what are those? Those, as Doug says, are the proposals,
> plans, budgets, contracts, and so forth as constructed by the participants
> and users of a particular OHS. KM is a process that enables KP.
> Can we contrast this view of an OHS to Rod's SDS? I think so, but my
> version will necessarily be incomplete given that I only have read-only
> access to the web product of SDS with no navigational aids except Rod's
> occasional references in this list.
> SDS clearly handles IC as evidenced in his links to *original* records. SDS
> also handles DR, as evidenced in the links he supplies us as entry points
> into his records. Is there KP in SDS? I believe so, but the only evidence
> we have for that lies in the enthusiastic way in which Rod smears this list
> with profound reminders of what we have said before, complete with his take
> on things. SDS has shown us one particularly important aspect of KM --
> keeping track and making sense of the record. Until SDS has a navigation
> tool, and until it provides us with an opportunity to interact with it, then
> it is not complete as a KM tool in so far as I am describing an OHS. SDS
> appears to be comprised of the elements Time, and Subject, and Records which
> are a cross-product of Time and Subject. That, it seems to me, represents
> the underlying structure necessary for KM. A user interface Rod uses must
> turn that structure into a useful KM tool. My proposals, here, add an
> Ontology as a central core that ties concepts to other concepts to time and
> to records.
> Should we perform a summary of documents as I originally suggested? Or,
> should we toss our energies at development of the navigational tools
> necessary to get a better handle on what we have been saying? We should
> probably do both.
> From: Rod Welch <firstname.lastname@example.org>
> > I tried your suggestion and wound up at...
> > http://www.infoloom.com/gcaconfs/WEB/barcelona97/angerst7.HTM
> > This location and the path that led to it seems like it could be very
> > How are you thinking of applying this to KM, as Doug lays out in his 1972
> > reviewed most recently on 000327....
> > http://www.welchco.com/sd/08/00101/02/00/03/27/094001.HTM#L391402
> > ...and evidently applied in his paper on 980128 for the "Technology
> > Project," that led to the DKR objective...
> > http://www.bootstrap.org/alliance-980.htm#0436
> > Is the idea to process daily working information with the engine discussed
> > your letter on 000623...,
> > http://www.welchco.com/sd/08/00101/02/00/06/23/114155.HTM#L441903
> > Sounds like a strong track, which might lead to putting the Subject Index
> on the
> > web in some form that would add a new dimension to finding stuff when
> > similar to SDS.
> > Rod
> This message is intended only for the use of the Addressee(s) and may
> contain information that is PRIVILEGED and CONFIDENTIAL. If you are not
> the intended recipient, dissemination of this communication is prohibited.
> If you have received this communication in error, please erase all copies
> of the message and its attachments and notify email@example.com
> eGroups Sponsor
> [click here]
> Community email addresses:
> Post message: unrev-II@onelist.com
> Subscribe: unrev-IIfirstname.lastname@example.org
> Unsubscribe: unrev-IIemail@example.com
> List owner: unrev-IIfirstname.lastname@example.org
> Shortcut URL to this page:
-------------------------- eGroups Sponsor -------------------------~-~>
It's Easy. It's Fun. Best of All, it's Free!
Community email addresses:
Post message: unrev-II@onelist.com
List owner: unrev-IIemail@example.com
Shortcut URL to this page:
This archive was generated by hypermail 2b29 : Mon Dec 04 2000 - 12:27:51 PST