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

[psp <beadmaster@ontologystream.com>]

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

I can not seem to figure out how to unsubscribe.. as there is not line in the messages sent from this forum to help in this regard.

 

This is generally the case with forums, and the managers of this forum should make the correction.  You should be placing a line at the end that reminds folks how to unsubscribe rather than holding us captive to technical discussions that go nowhere and are aimed at nothing that I can make any sense of. 

 

I have listened to the topic maps discussion for over a year now, and there seems very little movement on any of the outstanding issues with respect to the notion of scope and situatedness.

 

My own work and occasional request for discussion on formative ontology is never even responded to with any acknowledgement.

 

So I wish to not receive the posts from Oasis... these are not comments about the nature and reality of topic maps (no one here is in a position to discuss the clear shortcomings) it is a technical discussion that serves to disguise the fact that the relationship between addressable subjects and non-addressable subjects is no longer of any technical importance to anyone - including the original group that so clearly spelled out the issues.

 

 

 

 

-----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