[topicmapmail] Web Services

[Murray Altheim]

[wrote this earlier and I guess forgot to send it...]

Miles Thompson wrote:
> Hey Murray,
> 
> Hmm Why is this really?
> 
> I understand that XTM is just a serialization format for the model,
> being Topic Maps. And that XTM doesn't have any "valid meaning" until
> its loaded into a TM Application. However,
> what I don't understand is where precisely things would start to go
> wrong with an approach that adds/removes/updates specific XTM fragments
> by ID using Xupdate. 

You're correct in that XTM is "just" a serialization format. The
thing is, the model allows for a lot of constructs that are not
represented in the tree structure of XTM and are only capable of
being interpreted in the Topic Map graph, the thing that is
created upon a parse of the XTM document. That graph is no longer
quite like the original XTM document, in that say, twenty or thirty
<topic> elements, each having different XML IDs, might potentially
be merged according to various topic identity rules. Likewise, you
may search for a topic according to its XML ID, or even a subject
identifier (a URI), but not receive in your returned results all
of the topic characteristics, given that the <topic> element your
query found was not merged with all of the other potential <topic>s,
which might have provided the base names, occurrences, roles played
in associations with other topics, etc.

In short, if you treat an XTM document as an XML document and deal
with it as such, you simply won't be getting the whole story. There've
been efforts to define a canonicalization and "fully-merged" Topic
Maps, but that still won't provide you the things necessarily you'd
need. You really need a Topic Map engine behind the scenes to fully
process the incoming XTM content and then the query upon the resulting
Topic Map graph (now "in memory").

> You could tell the XTM application to 'mergemap' the entire tree again,
> at the end of each update, thus merging topics if that were necessary ?

Yes, but you'd need more feedback than what XUpdate provides to know
exactly what was happening, basically a richer API.

> Or if this would not work, how different would an XTM specific version
> of Xupdate have to be?

How different? A tough question. It's kinda like apples and oranges,
really. XUpdate was developed to deal with XML documents as tree
structures, with the XML model behind it all. An XUpdateTM would
have to be developed to deal not with an XML tree, but with the
Topic Map graph directly (with the TM model behind it all), avoiding
references to XML entirely -- you couldn't even rely on a specific XML
ID being present after a parse.

Note that there are a number of syntaxes for serializing or expressing
Topic Maps, and ISO is working towards development of a model for
Topic Map applications. What you/we really need is an API for updating
the *result* of parsing any syntax (XTM, LTM, AsTMa), *after* it's in
the engine. E.g., I've got Topic Maps that are the result of five or
six different XTM and LTM documents, where I call one and they all
ask for each other to come running. The result is the composite of all
of them, and sometimes I'm not even sure what an appropriate base URI
is for the result. I'm happy we created XTM, but honestly, the
confusion between Topic Maps-as-Topic Maps and Topic Maps-as-XML has
been dogging us all along.

Murray

......................................................................
Murray Altheim                    http://kmi.open.ac.uk/people/murray/
Knowledge Media Institute
The Open University, Milton Keynes, Bucks, MK7 6AA, UK               .

    [...] all matters of authority and responsibility are ultimately
    matters of social practice, and never matters of ontology (that
    is, never just a matter of how things in fact are in the nonhuman
    world). [...] just as we should not look to ground our moral
    judgments in the nonhuman authority of a god, so we should not
    look to ground our empirical judgments in the nonhuman authority
    of an external world.                          -- Robert Brandom
    http://www.tilgher.it/brandom.html