[Responding to
Rod Welch's letter
on November 28, 2000... ]
.. 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
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 interoperability.
.. 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 engine.
.. 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
parts:
temporal and conceptual coupling -- links with summary statements
personal commentary -- thoughts, extensional/projective,
stream-of-conscious
.. 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
representations.
.. 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
basis.
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 [Knowledge Product] 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.
..
Sincerely,