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

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

Lars Marius Garshol wrote:
> 
> * Lars Marius Garshol
> |
> | 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.
> 
> * Murray Altheim
> |
> | Yes, and I mentioned that #1 would require this merging. Check that
> | last sentence.
> 
> I did check it, but misunderstood it. If #1 requires all that merging
> to be performed I have absolutely no problems with it, but then I
> don't know what the difference between #1 and #2 is. Could you
> explain?

No, you're misunderstanding me. #1 would require "all that merging" to
keep it from being misused, but under certain conditions #1 is still
useful. #1 is basically useful for taking an XTM document and sorting
it, making its whitespace consistent, checking for XML validation
problems (such as duplicate or erroneous IDs), etc. It's the format 
that is still processable as XML. And YES, that has problems if one
doesn't RTFM.

#2 is essentially what a topic map engine would produce if it exported
XTM syntax, but in some more canonical form that might seem the random
variety of export approaches as taken on by multiple developers making
multiple design decisions. While Ontopia and Mondeca's XTM export might
be completely valid both as XML and XTM (semantically), a semantically-
identical topic map might produce different XTM export documents. #2
would essentially be a specification for a target export, a flavour of
XTM document that would specify a common way to express in syntax the
various topic map components. As Sam mentioned, something like sgmlnorm
for XTM syntax.

[...]
> * Lars Marius Garshol
> |
> | [graph-normalized]
> |
> | This one I don't understand. What is it intended to achieve? How is it
> | going to do that?
> 
> * Murray Altheim
> |
> | 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.
> 
> I understood that, but I wanted to know what you saw the purpose of
> that as being.

Well, it's the only format that could *truly* compare the semantics
of two topic maps. It certainly can't be done from XTM. For example,
an "instance-of" relationship can be expressed directly in XTM syntax
or by use of an association. Only in the graph would all of these
internal relationships be exploded, merged, etc. into the essential
graph structure, which looks nothing like XTM and would likely lose
the original author's syntactical expression (ie., you'd no longer
no whether the original document had <instanceOf> or the association).

> It's also worth noting that as currently planned there will be no
> difference between documents processed according to the XTM syntax
> spec and those processed in terms of the reference model (PMTM4).
> 
> If you read document 0278 you'll see that the plan is for the
> deserialization specifications to map into the Standard Application
> Model (a descendant of the infoset model), which again will have a
> mapping to the reference model. So the graph and infoset
> representations of an XTM document will be 100% equivalent. In short,
> there will be only one "processing model".

That's great in theory, but it already sounds (even in the abstract)
like a much more complex system than current topic map engines. If
we make the bar too high nobody will attempt to build these things.
I've always hoped that simplicity would be considered the number one
item on the requirements list, but I know it's not in reality. How
far from that primary goal we stray will affect the acceptance of
topic maps as a technology. I think Hytime might have succeeded if
it'd been broken into smaller chunks and simplified about by half.
Of course, that's just my opinion.
 
[...]
> | 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.
> 
> This I don't follow. Why would you build an inference engine on top of
> a normalized XTM syntax instead of on top of a topic map engine? If
> you have a topic map engine you don't need a normalized syntax. And
> doing it on a topic map engine would be an awful lot easier.

I guess I've answered this under a different message, but yes, of 
course. I can't imagine anything being built on top of a syntax.
You need an engine. Sorry if this was unclear.
 
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!