Re: [topicmaps-comment] TMs & XTM [Was: skills to create topic maps]

[Murray Altheim <murray.altheim@sun.com>]

Lars Marius Garshol wrote:
[...]
> * Murray Altheim
> |
> | I can see* three types of "normalized" topic map, each possibly a more
> | successively processed document:
> |
> |   1. XTM-normalized
> |      This would be a "sorted" view of an XML document, sorted following
> |      some agreed-upon algorithm such as by-ID, by-scope, by-name-within-
> |      scope, occurrences-by-URI, etc.  This would allow two XTM documents
> |      to be compared using common XML and diff tools, but would not take
> |      into account differences due to merging, authoring approaches, etc.
> 
> I think this may be quite dangerous. It suggests that it is OK to
> import and export an XTM document without doing all the required
> processing on it. The XTM specification as rewritten by ISO (described
> elsewhere[2], BTW) will make this form of XTM look quite strange.

It's no more "dangerous" than any other XML-based form of topic map,
no more dangerous than say, XTM itself. I thought I'd been fairly 
clear that #1 leads perhaps on to #2 and then on to #3 in terms of
complexity and accuracy to the topic map processing model, and further
and further away from the concept of an XML document. #1 is useful in
that it can be processed as an XML document under restricted circum-
stances, so long as it is understood that certain types of processing
have not been performed. I don't consider this dangerous, except for
those who can't RTFM.
 
> We'll have a model, a specification describing how to process XTM
> documents into instances of that model, and a normative recommendation
> for how to get back to XTM documents. The first step will require
> certain kinds of merging to be performed.

Yes, and I mentioned that #1 would require this merging. Check that
last sentence.

> How will you explain the role of this form of normalized XTM in this
> context? I'm not necessarily against this, but I'm concerned that we
> need to end up with a coherent set of specifications at the end of the
> day. SC34's plans are now quite clear and coherent, and we need to
> make sure that we don't mess that up.

I think what you want is #2, below.
 
> |   2. XTM-merged-and-normalized
> |      This would the exported output from a compliant topic map engine
> |      that performed all required topic map merges (and other functions
> |      such as duplicate suppression), but still maintains in some fashion
> |      the XTM features that might be considered "author intentions" such
> |      as ID names and other things necessary for interoperability. For
> |      example, if three <topic> elements are merged, their IDs would
> |      be still maintained as almost-empty <topic> elements that pointed
> |      to the merged/conglomerated <topic>, so that ID references would
> |      still function.
> 
> This sounds like the result of following the XTM import/export
> procedure to be described by ISO, and then sorting the topics by some
> agreed procedure in the exported file. Sounds perfectly fine to me, as
> it would enable topic map work to be done using less powerful tools,
> which in effect makes topic maps easier to work with and easier to get
> started with.

Exactly. And a tool that did this I believe would be quite useful. 

> I don't think this is necessarily the same as what Tony is talking
> about, but it's getting pretty close to cannonicalization, since there
> has to be an agreed-upon order for the topics (and associations). So
> probably this could be specified very easily by cobbling together bits
> and pieces from the updated ISO standard.

I agree. 

> |   3. graph normalized
> |      This would be a topic map that throws XTM interoperability to the
> |      wind and might not even be in XTM syntax, perhaps something akin
> |      to Steve and Michel's topic map graph DTD syntax. This might discard
> |      name variants, for example, and might have some type of algorithm
> |      for handling references to topics (since XLink, links and links to
> |      IDs are an XML thing, not necessarily a topic map graph thing).
> 
> This one I don't understand. What is it intended to achieve? How is it
> going to do that?

This represents a fully-processed XTM document, as according to the 
PMTM4 spec (or whatever is the end product of the ISO committee), but
exported back to XML. The DTD for this would be similar to the one that
Steve and Michel have provided on their topicmaps.net web site.

> | I think each would have uses, and as I mentioned above, might be
> | part of a chain of processing.
> 
> I think #2 may have some uses. The need for #1 and #3 I don't see, but
> more explanation might convince me.
> 
> | * BTW, I didn't spend more than about ten minutes thinking about
> | this, so there's likely many issues that would be brought to the
> | surface by a more methodical analysis. But this issue has certainly
> | been on my mind over the past month or so.
> 
> What issue, Murray? I see lots of them here, and I'm not sure which
> one it is you're looking to address.

By "issue" I mean the whole issue of canonicalization or representation
of XTM documents in a way that allows checking for similarities or
differences. In researching use of XTM in a conceptual graph/ontology
usage I believe this will be necessary, esp. if an inference engine 
were to be desired.

Murray

...........................................................................
Murray Altheim                         <mailto:murray.altheim&#x40;sun.com>
XML Technology Center, Java and XML Software
Sun Microsystems, Inc., MS MPK17-102, 1601 Willow Rd., Menlo Park, CA 94025

               Rally against the evils of iceburg lettuce! 
            Grab a kitchen knife and join the Balsamic Jihad!