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.
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
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
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...
> 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....
> ...and evidently applied in his paper on 980128 for the "Technology
> Project," that led to the DKR objective...
> Is the idea to process daily working information with the engine discussed
> your letter on 000623...,
> Sounds like a strong track, which might lead to putting the Subject Index
> web in some form that would add a new dimension to finding stuff when
> similar to SDS.
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 -------------------------~-~>
It's Easy. It's Fun. Best of All, it's Free!
Community email addresses:
Post message: unrev-II@onelist.com
List owner: unrev-IIfirstname.lastname@example.org
Shortcut URL to this page:
This archive was generated by hypermail 2b29 : Thu Nov 30 2000 - 11:00:36 PST