Re: [topicmaps-comment] multilingual thesaurus - language,scope ,and topic naming constraint

["Thomas B. Passin" <tpassin@comcast.net>]

[Lars Marius Garshol]
>
> * Thomas Bandholtz
> |
> | In a single XML document, all attributes of type ID have to be
> | unique. A validating parser will check this. Generally this asures
> | as well that all internal references (using IDREF) are valid. Based
> | on this, two Topic Maps may use the same IDs while both of them are
> | valid by themselves. When you merge them into one document, you will
> | have to unify the IDs and IDREFs by replacing them in at least one
> | of the two source documents. This means: IDs are a moving target -
> | as long as I cannot asure that nobody else in the world uses the
> | same IDs like me.
>
> Actually, there are three standardized (or to-be-standardized) ways of
> identifying a topic:
>
>   1) by giving the URI of one of the topic's subject indicators,
>     (provided it has any, of course),
>
>   2) by giving the URI of the topic's subject, (provided the topic
>      actually does represent an information resource with a URI), or
>
>   3) give a URI that points to the topic's <topic> element. (This must
>      of course make use of the ID.)
>
> As you can see, none of these are subject to the ID collision problem.
> So this is actually a problem that topic maps do not have.
>

Seems like number 3) is exactly the case T.B. was talking about.  Whether a
topic is referred to by its ID directly (e.g., by a program instantiating
that map in memory), or by xlink:href is secondary, since the href is
supposed to refer to the topic by its ID as in

xlink:href='#thetopic'

This mean the ID is treated as a URI (when you normalize it to include the
base URI of the owning document).  Since this literally applies only to
interchange format (XTM, ISO), it is a bit unclear to me what is supposed to
happen when a map is instantiated in a program, but I think most people
would expect the program to use the same identifiers as if they were
actually URIs.

One additional point may be relevant here,which is (I think it is in PMTM4)
that two subjects may be considered to have the same subject if they have
the same subject constituters or indicators.   This means that if you import
a map and correctly merge topics, meaning that you come up with new ID
values for the merged topics, they can still be considered to have the same
subjects as the original topics, even though they now have new IDs (and
URIs, presumably).

Thie problem with this is that other processors are going to find it hard to
know that the changed URIs represent topics having the same subjects.  For
example, In one map, a topic known as http://mapco1.com/map1#zoo does not
seem to be the same as one known by http://mapco2/map2#animalpark, even
though the latter came about when MapCo2 merged MapCo1's map with one of its
own.

So it may happen that the URI's are not stable - if you see a topic as
representing a resource - and I see that as being contrary to the concept of
operations of the web. The only stability we really have as things are now
is 1) locally within any one map, and 2) PSIs.  You cannot really refer to a
topic in another map in a stable way, with certainty as to what it
indicates, without importing the foreign map.

It's easier for me to see this as a potential problem than to know what to
do about it.  Or maybe someone can explain why it is a non-issue.  Perhaps
it means only that the granularity of a topic map is the whole map itself.
But who wants to have import giant maps into their little one?

Perhaps we need a Rec analogous to xinclude, so we can import a topic or a
small set of topics without having to import an entire map.

Cheers,

Tom P