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

> {Thomas Passin]
> This would be easy to arrange from a programming point of view.  But
> consider that you use this interface to retrieve a single topic:
>
> <topic id='tt-flood-portsmouth-1936'>
>     <baseName><baseNameString> The Great Portsmouth
> Flood</baseNameString></basename>
>     <instanceOf><topicRef
>        
> link:href='http://theSourceOfTheMap.com/#tt-flood-portsmouth-1926'/>
>     </instanceOf>
> </topic>
>
> It turns out that you do not have the class topic with
> id='tt-flood-portsmouth-1936'.  As a person, you can read the
> baseNameString
> of the imported topic and perhaps know what it represents
> (depending on the
> actual name).   But your processor cannot.  It may not even
> be valid to
> insert this topic into your map, since it references an 
> unknown topic.

If you maintain your Topic Map based on xlink:href using URIs that point to GET requests, you will do this consequently.

In this case any *internal* class definition would also be referenced by a GET request.

The class topic tt-flood-portsmouth-1936 would not reside in the <topic> range that is returned by the first request, but it can be accessed in the same way, by reeding what  http://theSourceOfTheMap.com/?id=tt-flood-portsmouth-1926 returns.

If http://theSourceOfTheMap.com/#tt-flood-portsmouth-1926 is defined somewhere outside in an XML-document (using anchors), then there is no difference between the two methods.

Using GET requests means: whenever you find any xlink:href, just read to what this URI points and you will get exactly the related object, possibly containing xlink:hrefs itself which you can read in the same way, and so on, as long as you find some more.

> Even if you could use the topic as is, its associations and
> occurrences are
> probably what you really want, and they each have their own types,
> superclasses, etc.  You really want a whole subgraph, but how
> do you know
> what subgraph you want, and how do you ask for that subgraph?

You can easily implement a Service that returns subgraphs, i.e. all the associations of one topic + all the topics referred to by these associations + all class definitions, etc ..

But this is not what a topicRef wants. A topicRef points to exactly 1 topic. If you want to follow the links specified in the topic itself, just do it, endlessly. They don't have to be in one file alltogether.

> The interface to get associations by topic id definitely will
> help, but it's
> not really going to be enough, I think. 

> That's why I see
> this subject as
> complicated and important.

Right! I am repeating myself:
1) There must be a way that Topic Maps can be fully maintained in databases without any file dumps.
2) A HTTP GET request is a valid value for xtm:topicRef, just as an anchored URL.

Thomas Bandholtz