[Sigia-l] Distributed thesaurus?

Lars Marius Garshol larsga at garshol.priv.no
Sun Sep 22 16:00:02 EDT 2002


* Eric Scheid
| 
| All this implied knowledge is dandy. The problem is that "spidering
| around" can only follow links, and if all these links only point to
| subject indicators and they don't point elsewhere (ie. other
| topic-maps), how will you ever get from source A to source B.

So I misunderstood you, then, not the other way around. :-)

There's lots of ways you can learn about other sources, actually:

  - a topic map can explicitly refer to other topic maps it wants
    merged in with <mergeMap/>, but unless the user explicitly says no
    they will be loaded, and so this may not be what you want,

  - you can also point to specific topics and have their topic maps
    loaded, with the same caveat,

  - or you can use occurrences to do it, which is probably the right
    way in this case.

In the FOAF world this is perhaps best done with occurrences of
people, saying "here's this person's FOAF file". 
 
| That answers the problem of how the spider gets around to other
| topic maps then. Question is, does it treat those links as an entry
| point to a wider topic map, or simply as a subject indicator URI?

Simply as a subject indicator URI. The idea is that the thing at the
other end will be human readable, and so it will be incomprehensible
to a topic map processor.
 
| I'm guessing it would, if the content of the subject indicator URI
| happens to have a doctype declaring it to be a topic map. Right?

You could do that, but in a large topic map the processor would then
have to download thousands of indicators only to discover they are
dead ends. It wouldn't be very efficient. Better then to use
occurrences where you can say what the thing at the other end is.
 
| No, this isn't what I mean. Setting aside subject indicators for the
| moment (aka. URIs to a canonical definition of the *concept*), I'm
| talking about connecting two topic nodes within a topic-map space,
| where one of those nodes happens to be in a topic map elsewhere.
| 
| For example, in my topic-map I might say "X is related by Y to Z",
| (where both X and Z also have subject indicator URIs, but we'll
| ignore that for the moment). Now, instead of Z being defined
| *within* my topic-map, it is defined in *your* topic-map, and I
| simply point to it.

Yeah, you can do that easily. The trouble is that most processors will
then go off and load that topic map. You can tell them not to, but it
really is sort of a pain. What you can do is make a minimal proxy for
the topic inside your own topic map (so that the thing gets a name,
for example), and then include a reference to a topic map that has
more information as an occurrence.
 
* Lars Marius Garshol
|
| If in a different topic map you then say the same thing a topic map
| processor will know that this is a single subject.
 
* Eric Scheid
|
| This assumes (1) the processor has knowledge of the other topic map,
| and (2) isn't distracted by dozens of other instantiations in even
| more topic maps, and (3) knows how to select which other references
| to that subject indicator I care about.

This sounds like a more concise statement of what I explain above.  Is
that right?
 
| Putting it another way, I want to say "if you want to know more
| about X, including a really good topic map I'm not embarrassed to
| link to, then go look at X over at [URI]. 

That's what I explain how to do above.

| Meanwhile, ignore any other references to X you might happen to
| know, as the context/quality/politics is suspect."

You can do this as well, by putting scope on the occurrence. The
canonical example was someone writing a topic map about the Russian
revolution from a Trotskyist point of view, and referring to a
Stalinist topic map, adding the scope "lies", so that anything loaded
from that topic map would be marked as a lie.

-- 
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
ISO SC34/WG3, OASIS GeoLang TC        <URL: http://www.garshol.priv.no >




More information about the Sigia-l mailing list