Re: [xtm-wg] Topic Naming Constraint

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

* Steven R. Newcomb
| 
| Either names are meaningful, or they aren't.  If names have nothing
| to do with identity, why am I never called "Artur Rubinstein" or,
| for that matter, "Species 8472"?  My point is that names have a very
| great deal to do with identity, and identity has a very great deal
| to do with topic merging.

Names certainly have a lot to do with identity, but they are too
unreliable to serve as a basis for globally enforced merging. Names
are much like hash codes. If they are different the subjects signified
by them are almost certainly different. If they are equal the subjects
_may_ be equal, but there is no guarantee.  

In Norway there are six people named Kristine Ødegaard, and Norway is
a very small country.  How do you propose that we handle this problem,
if someone were to create a topic map of the entire Norwegian
population?

| In informatics, the normal and primary purpose of naming a thing is
| to allow it to be identified -- i.e., addressed -- unambiguously and
| reliably.

Yes, but in a formal context, and not when modelling the real world.
In relational database design it is exceedingly rare to declare name
fields as UNIQUE.

| The primary design goal of topic maps was always to make it possible
| to merge finding aids for corpora of information.  You seem to be
| saying that names should be excluded from being used in service of
| that goal, because the discipline that the topic maps paradigm
| imposes on the use of names (the topic naming constraint) is not
| worth the trouble it causes.

I think a distinction should be drawn here between requiring all
topics in all topic maps to always be merged on the basis of names,
and using this as a strategy in a tool designed for facilitating topic
map merging.

| The value of being able to merge finding aids can scarcely be
| overstated; if we lay aside all the hype, that value is the real,
| revolutionary importance of topic maps.  If we weaken the
| mergeability of topic maps, we beg the question, "What can topic
| maps do for me that I can't already do with plain-vanilla
| hyperlinks?"  

I think the weakening of mergeability by removing the TNC is very
small, and, as I've argued in a separate email, the TNC is inherently
problematic. Making it required creates new problems, without really
making it any easier to merge topic maps, since the TNC will force the
use of name scoping to be unnaturally contorted.

| If we take the position that the specification of scopes is
| unnecessary, or that it should be avoided, we have nothing but a
| plain-vanilla hyperlink architecture.  

This is a completely different position from the one I am taking.
Scope is useful, and names should be scoped as appropriate, but the
TNC should not be required.

| First of all, what is the topic naming constraint?  It is that no
| two topics can have the same name (basename) in the same scope
| (topic namespace).  Why is that important?  Because, otherwise, the
| names of topics cannot be used to look them up directly; names do
| not identify topics.

Of course you can use them to look up topics, even without the TNC!
What you lose is the guarantee that you will only get one or zero
topics back. To me, that is only reasonable. If I look up the name
"Kristine Ødegaard" the only reasonable result is that I get six
topics back.

If the TNC were required and I were to use your suggested mechanism
for lookup I would have to guess what a reasonable scope for the
particular Kristine I was looking for would be. Since there is no such
reasonable scope this mechanism is a problem and not a help.

| The usefulness of topic names -- and topic maps -- would be severely
| compromised if topics could not be unambiguously addressed by their
| names.

Can you give examples of why this is useful?

| The idea of regarding "The Steve Newcomb who lives on Flagler Court"
| as a controlled-vocabulary term is absurd, and it's the wrong way to
| think about topic names.  

Agreed!

| You seem to be determined to avoid the use of scope for making
| distinctions between names, but the fact is that if you don't use
| scope for your names, you are bound to have trouble.  Scope is
| fundamental to topic maps.

One is bound to have trouble, but as far as I can tell, only because
of the topic naming constraint.  If there are other things that would
cause trouble I would be happy to hear of them.
 
| Your statement that "the topic naming constraint requires apriori
| knowledge of the vocabulary of all topic maps with which the topic
| map being created is used" is simply not true.  When merging
| multiple topic maps, it's trivially easy to distinguish the names
| applied by various topic map documents (more precisely, <topicMap>
| elements) from one another, so as to avoid name clashes across topic
| map documents.

Provided that topic map documents are involved, yes, but this is
likely to be the exception rather than the rule. (See my previous
email.)
 
| Finally, if you don't like the facilities that the topic maps
| paradigm provides for names, you certainly don't have to use them.
| Just don't give your topics any names, and, instead, you can define
| an occurrence type (or an association type) for your "name-like
| things" that has whatever application-defined semantics you want it
| to have.  Such occurrences will not be treated as names, and they
| will therefore not be subject to the topic naming constraint.

That they will not be treated as names is precisely the problem. It is
not reasonable to expect applications and development frameworks to
handle this as they would handle topic names, and so this is likely to
cause a lot of extra work.

I would rather remove the TNC than force people into such solutions.

--Lars M.

[1] <URL: http://www.ssb.no/navn/sok.cgi?lang=n&base=kvinne&fornavn=Kristine&etternavn=%D8degaard >


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

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