[sc34wg3] Question on TNC / Montreal minutes
Thu, 05 Sep 2002 09:11:04 +0200
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.
> | 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
> 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')....???
> | 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
Consultant & Programmer
Tel: ++49 (0)40 89 700 511
++49 (0)177 283 1440
Fax: ++49 (0)40 89 700 841