[sc34wg3] Question on TNC / Montreal minutes

[Jan Algermissen]

Lars Marius Garshol wrote:
> 
> * Jan Algermissen
> |
> | How interesting...this raises the question if the
> | 'causeTNCbasedMerge'-flag is a property of a) the basename or b) the
> | particular association between the topic and its base name.
> 
> There is no Reference Model draft yet, but it seems clear to me that
> in the Reference Model this will be represented using two different
> assertion types. The XTM syntax chosen to some extent obscures what is
> conceptually going on: topics can have two kinds of base names,
> identifiers (subject to the TNC) and labels (not subject to the TNC).
> 
> So the answer is neither a) nor b).

Oh yes, sure. I have been thinking of making a statement about the particluar
assertion ("this assertion does not cause a TNC based merge') but you are of course
right that introducing another assertion type is the way to go. There would then
be something like ..#ap-topic-basename and ...#ap-topic-name .

But shouldn't the merge attribute then be on <baseName> rather than <baseNameString>, to
reflect the idea that it is a property of the assertion rather than of the basename.


Jan

> | If it is a) then the above topic map would not be valid I think,
> | because a basename would either be triggering a merge or not. This
> | also seems to demand that the value of the merge attribute has to be
> | the same for all basenames that are equal.
> 
> Requiring that would basically break the whole solution, since the
> point of being able to say merge="off" is to avoid unwanted merges.
> 
> | But then, isn't it the topic map processor that eventually decides
> | how it interpretes 'equal' ?
> 
> No. The SAM specifies this very clearly. Strings are equal if they
> consist of identical sequences of abstract Unicode characters. In
> other words, matching is case-sensitive and Unicode normalization is
> assumed.
> 
> To leave this up to processors would mean that subject identity would
> not be treated reliably, which would more or less guarantee breakage
> of topic maps upon interchange.
> 
> *Applications*, on the other hand, are free to use whatever rules for
> merging they please, but that's different from what *processors* are
> required to do.
> 
> | This would then lead to a situation where a map might be valid in
> | the context of the author (suppose the author thinks of
> | 'char-by-char' equality) but might be invalid for some topic map
> | engines (that propably apply a case insensitive interpretation of
> | 'equal')....???
> 
> Exactly.
> 
> | If it is b) then the merge attribute should be on the <baseName>
> | element and would mean: "whatever other pieces of the map say, don't
> | merge this topic with other topics that happen to have the same name
> | (in the same scope).
> 
> The attribute is on <baseNameString>, because it does not apply to the
> variants, but it does say what you think here.
> 
> --
> Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
> ISO SC34/WG3, OASIS GeoLang TC        <URL: http://www.garshol.priv.no >
> 
> _______________________________________________
> sc34wg3 mailing list
> sc34wg3@isotopicmaps.org
> http://www.isotopicmaps.org/mailman/listinfo/sc34wg3

-- 
Jan Algermissen
Consultant & Programmer

Tel:   ++49 (0)40 89 700 511
       ++49 (0)177 283 1440
Fax:   ++49 (0)40 89 700 841 
Email: algermissen@acm.org
Web:   http://www.topicmapping.com