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

["Bandholtz, Thomas" <thomas.bandholtz@koeln.sema.slb.com>]

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

Steven, sorry for the delay.

> -----Original Message-----
> From: Steven R. Newcomb [mailto:srn@coolheads.com]
> Sent: Saturday, February 02, 2002 9:59 PM
> To: Bandholtz, Thomas
> Cc: 'topicmaps-comment@lists.oasis-open.org';
> topicmapmail@infoloom.com
> Subject: Re: [topicmaps-comment] multilingual thesaurus - language,
> scope ,and topic naming constraint
>
>
> "Bandholtz, Thomas" <thomas.bandholtz@koeln.sema.slb.com> writes:

> > 3. A basename is a basename and not an association.
>
> The above remark is both true and false, depending on
> how you read it.
>
> It is true that a <basename> element is not an
> <association> element.
>
> However, at the most fundamental level of the semantics
> of topic maps, a basename (the name indicated by the
> content of a <baseNameString>) is itself a subject.
> Every <baseName> element makes the assertion that a
> specific subject has, as one of its names, a specific
> name, which itself is a subject.  At the most
> fundamental level, the only difference between such a
> "topic-basename" assertion, and any other kind of
> assertion (including all the kinds of assertions that
> one might make via <association> elements) is the
> semantics of the assertion type.

I would not like to call the name of a subject a subject itself.
In the end we would have a world consisting only of two categories: subjects and assertions between them.
Of course this is a legal high-level abstraction - but what is it good for?

If I publish a subject and i say "my subject has a name" then I do not want to make the name itself my subject.  The name is just an attribute.

I find it useful to distinguish both categories.

> > 4. Back to the roots: The identifier of a topic is ID
> > and not basename.
>
> The deepest roots are not fully visible in the syntax.
> Again, the above remark is both true and false,
> depending on how you read it.
>
> It is true that the identifier of a <topic> element is
> its ID.
>
> It is also true that, in the Standard Application Model
> (SAM) of the Topic Maps paradigm, a subject can be
> addressed by means of its base names.  In fact, the
> primary reason for the Topic Naming Constraint is to
> preserve the possibility of unambiguous addressing of
> subjects by means of their base names.  (The Topic
> Naming Constraint is that no two subjects can have the
> same name in the same scope.)

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.

I think this shall be overcome by the TNC. But - what I said about IDs is also true about "naming characteristics". How to know every naming characteristic used somewhere in the world to avoid duplicates?

OK, TC PubSubj and TC geolang are working in this field, but only for Published Subject Indicators - not for naming characteristics.

ISO13250 has a solution to this problem:
<<<<<<<<<<<
NOTE 36: If any two topic maps that are to be merged conflict with one another because they happen to provide the same name within the same scope for two different subjects, the merger of the different subjects can be prevented by applying different added themes to one or both of their containing topic map documents, using one or more addthms elements. The added themes specified by such addthms elements can serve to distinguish the two identical names, because they will no longer appear within exactly the same scope.

>>>>>>>>>>>
But this not machine-detectable! A machine can find naming duplicates, but it cannot decide that these just have "happened" and should be corrected, or that the topics should be merged.

ISO13250 contains many more constraints about when topics may be merged (The most exact rule is about "Public Subject Descriptor" checking, and this is now applied by the Published Subject Identifier TCs).

> > If you refer to a topic you use IDREF and not the
> > basename.
>
> Correct.  The XTM syntax doesn't provide any constructs
> that would explicitly support the addressing of a
> particular subject by means of one of its basenames.
> (Nevertheless, the underlying SAM is designed to
> support it, and applications are free to do it.)

See my note on the local scope of ID/IDREF above. PSI use xlink:href, not IDREF nor basenames. xlink:href is of type xsd:anyURI, so you may use any kind of URI, that means: it may be a URN, which is a unique name in a unique namespace only - not a working web address like URL.

I am currently implementing a Web Service that gives access to a topic (or a ranked topic list) by several search conditions (including basename, of course).

This one will use SOAP messages that are described in a WSDL document.
Did you see my postings:
http://lists.oasis-open.org/archives/tm-pubsubj-comment/200202/msg00010.html ([tm-pubsubj-comment] using UDDI for PSI ), and

http://lists.oasis-open.org/archives/geolang-comment/200202/msg00045.html (a summary of my TM-related work).

Looking forward to continue this thread,

Thomas Bandholtz
XML Competence Center
SchlumbergerSema
Sema GmbH
Kaltenbornweg 3
D50679 Köln/Cologne
++49 (0)221 8299 264