[topicmapmail] TM/XML

[Lars Marius Garshol]

* Miles Thompson
| 
| That looks really interesting, exciting even! 

Thank you! :)
 
| The namespace-PSI relationship that you use is intuitively quite
| appealing to me and I think will make a lot of sense to potential
| TopicMap convertees.

Good!
 
| In any event (and please forgive my ignorance as you've probably
| addressed much of this elsewhere) here are some questions.

No worries. 
 
| 1. Would you say that anything expressible in XTM can be expressed
| in TM/XML and vice-versa)? How about TMDM<->TM/XML equivalence (if
| that is not the same thing).

TM/XML can express everything in TMDM and XTM except reification of
association roles. That could be supported, but it would bloat the
syntax a bit.

| Is it true provided that the XTM is sufficiently 'typed' (Sorry, I
| forget what you lot call it when every topic and occurrence has a
| super-type etc)?

Well, everything is now required to have a type in TMDM (except topics
and variant names), so in XTM you have to fill in a default type if
none is given. This works out very nicely for TM/XML, so that if you
want the default type you just use the PSI for it.

| 2. The existence of the "XSLT style sheet for converting from TM/XML
| to XTM" would seem to confirm the TM/XML -> XTM part of the above

The other direction is the real test, of course, but it seemed like
too much work (in XSLT) to be worth it.

| but you actually be willing to use this in a real application? That
| is, does it take a lot of CPU time or memory to process a large
| TM/XML fragment using the XSLT style sheet approach?

Not sure I understand what you mean here, but if you are working with
XML tools then I would vastly prefer TM/XML over XTM for processing
Topic Maps data. TM/XML should be a lot faster in XSLT than XTM could
ever be. Or did you mean something else?
 
| 3. I really like the idea that this format makes output data easier
| to render (for presentation) using XSLT. Would you say that such
| XSLT rendering was one of your main design goals when you came up
| with it?

Yes.
 
| 4. When converting from the TMDM to TM/XML I'm not 100% clear how
| one goes about 'cutting' the subject identifiers into namespace
| prefix and element name - can you explain that a bit more?

It's pretty easy. You divide the URI at the last '#' or '/' character.
What's after it becomes the local name, what's before becomes the
namespace URI. The prefix is a syntactic detail (even at the XML
level) so exporters are free to choose whatever prefix they like.

My prototypical TM/XML exporter for the OKS has a couple of built-in
prefixes, and then uses heuristics to try to produce nice ones if none
is built in. If the heuristics don't give anything usable we just go
for pre1, pre2, ...
 
| 5. I'm guessing it's possible to also automate the conversion from
| TMDM to TM/XML (assuming that the above can be automated) at least
| modulo the actual text used for namespace prefixes. Is that true and
| if so how do you / would you go about it?

The TM/XML paper in the TMRA'05 proceedings actually gives the
detailed procedure for that conversion. I've done prototypical
implementations in Jython and Java for the OKS, and it's not really
very difficult. The biggest hassle is the namespace declarations,
really.
 
| 6. Finally, if Ontopia has developed tools for doing the above, are
| you considering providing the code (or maybe just hints as to how to
| write the code) so that other people can do the same?

I doubt we'll release the source code, but the paper does have the
detail necessary. I'm allowed to publish the paper on my personal
site, but Springer asks that we wait until 12 months after the book is
published. I'm hoping to find time to write a proper spec for the
syntax, but until that's ready, anyone who wants to implement TM/XML
can just email me, and I'll email them the paper.

-- 
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
GSM: +47 98 21 55 50                  <URL: http://www.garshol.priv.no >