OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

topicmaps-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [xtm-wg] Topic Naming Constraint considered harmful



I have now given this subject more thought, and would like to raise
the issue one last time before this problem infects XTM 1.0 as well.

I think that having the topic naming constraint as an obligatory part
of the standard is a bad idea, and that it should be removed.  There
are several differnt reasons for this, which are described below.



--- MODELING

Different subjects often have the exact same name.  Paris, Texas and
Paris, France are very good examples of this.  Both are called Paris,
but they are different subjects, and should not be merged.  In order
to keep topics representing these subjects from being merged due to
the TNC the base names have to be differently scoped.

But scoping the name of Paris, Texas with Texas, USA or even America
is wrong, because this implies that the validity of the name is
somehow constrained to this area, which it is not; that city is named
Paris even if you are on the moon.


Another example might be the ancient Romans, which used personal names
consisting of three individual names. The first was always chosen from
a list of 7 names, the last was the family name and the middle also
had some form of group membership implication, the exact details of
which I forget.  For women, things are even worse, since the women of
one family would all have the same name...

In any case, lots and lots of Romans have the exact same name. The
question is how to scope them in order to keep the population of the
Roman nation from imploding through forced merging. I can think of no
reasonable method for doing so, nor do I think that I should be forced
to do so.


The source of the entire problem is that names are inherently
unreliable indicators of subject identity, and so requiring automated
merging based on names is in my opinion wrong.



--- REACTIONS

I have seen a number of proposals floating around that suggest various
ways of avoiding the problems caused by the TNC. One suggestion was
that the scopes of all base names should inherit the types of the
parent topic. This would keep, for example, the topic Arabic (type
language) from merging with the topic Arabic (type script).

Another was to not make baseNameString required within baseName, so
that people could create variantNames instead and avoid the TNC.

The last suggestion was that in many applications where topic maps
were auto-generated from large data collections junk base names would
have to be generated in order to avoid unintentional merging.

To me, this implies that the TNC is causing such problems for so many
people that it should be dropped.



--- IMPLEMENTATION

When generating a topic map from a large data collection, for example
a large database of some kind, the topic naming constraint will in
many cases be very costly to implement, since it will require matching
all basenames (with their scopes) across the entire resulting topic
map. 

Chances are also that in order to avoid unintentional merging the
scoping mechanism will have to be abused. (That is, themes that by no
means imply limited validity of the name will be used to scope the
name in order to avoid the TNC.)



To summarize, the topic naming constraint is inherently wrong in that
it implies that names provide a suitable basis for merging, people are
finding that it causes problems for them and it is difficult and
costly to implement.

In short, I think it should be removed.


The arguments that have been proposed in its favour, mainly by Steve
and Peter Newcomb are excellent arguments for the use of scopes on
names. In my opinion they are not, however, arguments for the topic
naming constraint.

I think the topic naming constraint belongs in applications which help
users merge topic maps that were never authored with the intention
that they be merged later. In such an application it would be useful,
but even there the author should be allowed to override it.

We have about 10 days to remove this problem. In my opinion we will
suffer for it if we don't.

--Lars M.


To Post a message, send it to:   xtm-wg@eGroups.com

To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC