In message <038801c075dd$cf4ee410$7e65a8c0@isadra.com>, Jack Park writes:
>Lee,
>This is great stuff!
>However, it provokes me to comment that it really begins to resemble Topic
>Maps. Topic Maps are about separating paths from content. Nodes are called
>Topics, and Topics can have Associations (I'd prefer that be called
>'relations' but, sadly, its called 'associations'). Plus which, Topics can
>have Occurrences, and these are the content, and they can be versioned at
>will. A Topic contains a list of Occurrences, and those lists could be
>nested to keep track of versions. In such a case, it would make sense to
>leave attribution right on the Occurrence itself. Do node level versioning
>at the occurrence, not the node itself.
Ideally, the interfaces and structure I'm talking about are somewhat
orthogonal to the Topic Maps goals. If we use this infrastructure
for creating and managing arbitrary documents, then we can use it for
XTM or DocBook or XHTML docs.
In essence, it's at a much lower level than Topic Maps. In the grand
scheme of things, this comes back to my pyramid:
Content Management
(XML, XLL, etc.)
/ \
/ \
Knowledge Management <======> Context Management
(Topic Maps, etc.) (UI, User Agents)
What I'm referring to here is a Content Management method, since it is
purely structural. Topic Maps are an attempt to manage "meaning"
and as such come under the realm of Knowledge Management. The term
"Context Management" is an attempt to encapsulate all of the wide
realm of "user context sensitive" interfaces to both CM and KM
systems.
-------------------------------------------------------------------------------
Lee Iverson SRI International
leei@ai.sri.com 333 Ravenswood Ave., Menlo Park CA 94025
http://www.ai.sri.com/~leei/ (650) 859-3307
This archive was generated by hypermail 2.0.0 : Tue Aug 21 2001 - 17:57:58 PDT