[topicmapmail] Stupid question---thanks

[W. Eliot Kimber]

Daniel Rivers-Moore wrote:
> 
> Eliot
> 
> I'm puzzled as to why you suggest that the notes in Suellen's example
> should be held *outside* the topic map. 

  Sure, they are "meta" information, but one of the beauties of
> the topic maps paradigm, in my view, is that because of its graph-like
> structure it is not tied to a single hierarchy and so there is no need
> to have a strict segregation of "meta" levels. After all, one man's meta
> is another man's passion ;-).

The problem I see is exactly that there is no strict segregation of meta
levels--that means that it's very difficult for a generic processor to
know which parts of a topic map are core "knowledge" and which parts are
metainformation about the topic map itself. It also means that, in the
absence of any standards or convention for the representation of
metadata for topic maps (regardless of how it's done) that there will be
little consistency in topic map metadata representation (no more than
any other use of topic maps will be consistent).

Of course, this is also an argument for which there is no absolute right
or wrong--it's a matter of practice. But everything in my experience of
designing information representation schemes suggests keeping
metainformation clearly distinct from core content, so that's the
approach I take. 

As I said in my post, you could use associations w/in the topic map to
also clearly distinguish core knowledge (the original topic) and
metainformation about the topic, but that seems like a lot of effort to
go to *if* you agree that the comments are rhetorically, not part of the
topic map.

One easy solution would be for the topic map markup to provide some
annotation facilities that let you say things about the topic map that
are not part of the abstract knowledge represented by the topic map
represented by the interchange document (and I don't want to hear about
"you can create your own representation syntax"--I'm only interested in
standardized syntaxes, which means whatevers comes out of SC34, Oasis,
or W3C at this point).

For example, the fact that there's no way in XTM syntax to embed any
metadata seriously complicates the interchange of topic maps in some
sort of work flow--all the metadata either becomes part of the map
itself (which I think is probably wrong, see below) or has to be held
outside the topic map in some way, e.g., by doing what I did in my post,
but in a necessarily non-standard way (because there's no standard for a
topic-map-encapsulating doctype). Contrast this with the STEP
interchange format for interchanging STEP data--it includes a fairly
robust metadata section that makes the data interchange package largely
self describing.

That is, if you stumble upon a topicMap document you have no way of
knowing anything about that document, as an artifact of interchange and
as a unit of information management in some process, by looking at the
document itself, unless the author used structured comments or encoded
the metainformation as topics and associations w/in the topic map.

If you have two topic maps that use topics to capture metainformation
about the topic maps as artifacts, what happens when you merge these two
maps to create a third map? It is almost certainly nonsensical to union
the metadata about the two input maps in the third result map. This test
alone suggests that it is inappropriate to use topics and associations
to capture metadata about the topic maps. 

Note that there is a larger problem, which is that the topic map
standards do not provide a clear way to define the identify of topic
maps as things distinct from their interchange representations.  This
makes it very difficult to talk about a topic map as a unit of
information management distinct from its various incarnations (system of
XML documents, in-memory representation, inherent/emergent abstraction,
etc.). This further clouds the issue of associating descriptive metadata
with topic maps. If, for example, I want to maintain metadata about my
topic map outside of the topic map itself, how do I reliably and
unambiguously point from the metadata to the topic map in a way that is
not dependent on a particular representation form? 

Cheers,

E.
-- 
W. Eliot Kimber, eliot@isogen.com
Consultant, ISOGEN International

1016 La Posada Dr., Suite 240
Austin, TX  78752 Phone: 512.656.4139