RE: [topicmaps-comment] referring to a topic from outside a TM

["Bandholtz, Thomas" <thomas.bandholtz@koeln.sema.slb.com>]

Title: RE: [topicmaps-comment] referring to a topic from outside a TM

> > [me]
> >....We need an addressing
> > method that can
> > provide on-line access to the addressed node.
> [Bernard Vatant]
> Agreed. That's the first step. Then you have to figure what
> you retrieve when you get that
> handle and pull it. Another story.

OK.
 
> XTM is a document interchange format, and certainly not fit
> for query. Ditto for any XML
> format ...
> BTW in Mondeca we use Oracle + Graph Manager. XTM is for
> import-export only, as could be
> RDF or customized XML.

Any XML document is "fit for query" using Xpath (or, coming, XQuery. But you need a processing engine for that.
We use "customized XML" in Tamino XML server which is of category "native XML database".
The very abstract view of XTM does not make it easy to use Xpath. That's another story as well.
 
> Exact. Processing Gigabytes of XTM is crazy.
>
> > The PSI activities today are dominated by file-oriented thinking.
> > I think this is very risky.
>
> I think you're right. In present recommendation draft of PubSubj TC
> http://www.oasis-open.org/committees/tm-pubsubj/docs/recommendations/psdoc.htm
> ... there is no explicit reference in Part 5 to any form but "addressable documents" -
> including XTM, RDF, XHTML.

Any XML format in a database can be seen as an "addressable document". I.e. the URI

[url of tamino-server]?_XQL=topicMap

will address the complete document, while

[url of tamino-server]?_XQL=topicMap/topic[ID='_4711']

addresses a single topic..... I will look at that more closely answering Thomas Passin.

> But the notion of having PSI living in databases have been discussed in the TC, and I
> think we should plough that notion further on, and include it in recommended practices.
Right.

> OTOH look closely to the general recommendation - Part 4 - you will not find anything
> contradictory with data base PSIs.

You may be right. I only have a problem with using fragment identifyers instead of queries - wait for my next posting -
But the recommendation - as far as I understand - is to use a persistent URL reference - not necessarily containig a fragment identifyer.

So the "docHeads" may use fragment identifyers and "dbHeads" may use queries. The only problem is: When you move over from doc to db (or vice versa) your URI will not longer be persistent. 

> There has even been progress towards less document-oriented approach, since we've come
> back to "Subject Indicator" after a passage through "Subject Definition Document". But we
> have still "Published Subject Documentation Set", and the recommendation is about
> "Documentation" of Published Subjects. Hmmm ...

Well, "documentation" needs not to be a "document" (used as a synonym for "file"). A document may be stored in a database (see above).

> Bottom line - Thomas, you are bringing interesting insights there. What about joining
> PubSubj TC - as your Schlumberger colleague Mary Nishikawa?
I have thought about that, and I have discussed it with Mary as well. When I decided to get involved in the process, I happened to find the gepLang CFP, and I am engaged in projects that will publish a gazetteer, so this seemed to fit.

As you are asking me (like Mary), and I am contributing anyway, why not also join PubSubj? Would that mean another phone conference on 10th, starting at 2:00 in the morning in GMT+1 :-) ?

Thomas