[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [topicmaps-comment] referring to a topic from outside a TM
-----Original Message-----
From: Bandholtz, Thomas [mailto:thomas.bandholtz@koeln.sema.slb.com]
Sent: Wednesday, March 06, 2002 12:10 PM
To: 'topicmaps-comment@lists.oasis-open.org'
Subject: 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC