Jack,
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....
http://www.welchco.com/04/00067/61/00/11/3002.HTM#0001
Thanks.
Rod
Jack Park wrote:
>
> Rod,
> 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
> 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 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.
>
> Jack
>
> From: Rod Welch <rowelch@attglobal.net>
> >
> > 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
> useful.
> > How are you thinking of applying this to KM, as Doug lays out in his 1972
> paper,
> > 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
> Template
> > 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
> in
> > 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
> needed,
> > 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 postmaster@verticalnet.com
> immediately.
> ============================================================================
>
> eGroups Sponsor
> [click here]
>
> Community email addresses:
> Post message: unrev-II@onelist.com
> Subscribe: unrev-II-subscribe@onelist.com
> Unsubscribe: unrev-II-unsubscribe@onelist.com
> List owner: unrev-II-owner@onelist.com
>
> Shortcut URL to this page:
> http://www.onelist.com/community/unrev-II
-------------------------- eGroups Sponsor -------------------------~-~>
eLerts
It's Easy. It's Fun. Best of All, it's Free!
http://click.egroups.com/1/9699/0/_/444287/_/975961030/
---------------------------------------------------------------------_->
Community email addresses:
Post message: unrev-II@onelist.com
Subscribe: unrev-II-subscribe@onelist.com
Unsubscribe: unrev-II-unsubscribe@onelist.com
List owner: unrev-II-owner@onelist.com
Shortcut URL to this page:
http://www.onelist.com/community/unrev-II
This archive was generated by hypermail 2b29 : Mon Dec 04 2000 - 12:27:51 PST