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

[Lars Marius Garshol <larsga@garshol.priv.no>]

* Lars Marius Garshol
|
|   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.

* Thomas B. Passin
| 
| 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'

That's the point, Tom: the 'href' attribute can contain a full URI.
It's perfectly legal give a complete absolute URI.
 
| This mean the ID is treated as a URI (when you normalize it to
| include the base URI of the owning document).  

Yes, although you can't use the base URI; you must use the document
URI. 

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

If I understand you correctly you are describing what happens: the IDs
get turned into 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).

Yes, this is the same no matter what model you use.
 
| 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.

It depends how you use the software. If you load the two topic maps
into an engine, then merge them, the engine should keep track of both
URIs. Of course, once you export back to XTM syntax this will be lost,
but until then you have both URIs. 

The Standard Application Model and the syntax specifications is going
to make this whole process a lot clearer. We hope to have good drafts
of these by Barcelona.
 
| 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.

This is absolutely correct. So far I've seen no problem with that. If
you do I'd like to hear about it.
 
| 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?

You're making lots of usage assumptions here that I can't follow. I
haven't yet seen this to be a problem, but I'm open to the possibility
that there might be one. If you could explain what you think that is
I'd like to hear it.
 
| 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.

Why?

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