[xtm-wg] The Topic Naming Constraint

[Geir Ove Grønmo <grove@ontopia.net>]

First of all I'd like to say that I wholeheartedly agree with Lars
Marius on this matter. The Topic Naming Constraint is [extremely]
painful and too awkward - in my eyes it is a real show-stopper.

I'll try to explain what I think is the problem with draconian Topic
Naming Constraint enforcement, which the standard(s) at this point
requires from an XTM processor. A conformant XTM processor has to
enforce these constraint, e.g. there cannot be _any_ exceptions if
you'd like to claim that your processor is conformant.

- - -

I see the usefulness of being able to do automatic namespace-based
merges. This is extremely useful, but unfortunately the problem is
that people (myself included) believe that base names are intended for
labelling purposes, not for identification.

Applications need to be able to display labels for topics. The obvious
way to do this is to use names. Occurrences are usually out of the
question, since _generic_ applications wouldn't be able to know when
to use a basename and when to display occurrences.

I believe that it is a problem [actually a bug] that base names are
subject for namespace-merges. As I said, I believe that
namespace-merges are _extremely_ useful. But we should not use base
names for this.

Proposal:

  o We need another kind of name, e.g. identifying-name. (I don't
  think that it makes sense for an identifying name to have variants
  like basenames do.)

  A name targeted towards namespace-based merges complements subject
  indicators. Instead of just identifying a topic by subject
  indicators (the _meaning_ of the resource content) you're then also
  able to identify a topic by the name resource _content_
  (byte-by-byte).

- - -

Here are some thoughts on why the TNC doesn't work in real-life in its
current incarnation.

Problem:

  Topics are merged even though the author(s) didn't intend them to
  merge because it is known by the authors that they have different
  subjects. This is what I believe is the main problem with the TNC in
  real life.

I see at least four ways that a processor can behave when merging two
or more topic maps:

  o The merge happens automatically and parts of the topic map no
    longer makes sense (is inconsistent), because resulting topics
    now represents more than one subject.

  o The merge is interactive. Unfortunately this requires the
    author(s) to be present when the merge happens. This is
    unacceptable in most cases. You cannot expect the authors to be
    present when a merge happens. Note that there are many [an
    unlimited number of] reasons why a merge happens.

  o The processor marks the topics as to-be-merged. This prevents the
    merged topic map to be presented to the user[!]. (A non-consistent
    topic map cannot be presented to the user by a conforming
    processor.)

  o The processor doesn't do merging based on the TNC. This is not
    allowed by the standard.

- - -

It has been pointed out that one of the reason why the base name
constraint exist is to avoid ambiguities when presented with identical
names. I agree with the usefulness of being able to avoid ambiguities.

Something to be aware of is that a name can be disambiguated by a
processor even without looking at the name scope:

  o A basename belongs to a topic, which itself represents a
    subject. The subject and subject descriptors _disambiguates_ the
    name!

  o The type-hierarchy and the classes of which the topic is an
    instance describes what the topic is about and that should to some
    extent disambiguate the name.

  o Basically all the other characteristics can be used by the XTM
    processor to further disambiguate a name to the end-user.

All of the forementioned information is always available to an XTM
processor.

- - -

Why is the TNC awkward?

1. It is impossible to universally scope basenames at the time of
   authoring to avoid unintended merges to happen in the future.

   You cannot know at a given point in time that you'll never have
   unintended merges caused by the Topic Naming Constraint.

2. Most merges will be done automatically by a computer (without user
   intervention).

   You cannot expect the authors of the two topic maps to be present
   the merge happens.

3. A computer cannot automatically correctly and sensibly scope names
   to avoid the TNC.

- - -

Conclusion:

   o Get rid of the TNC and introduce a separate content-based
     identifying name.

All the best,
Geir O.

------------------------ Yahoo! Groups Sponsor ---------------------~-~>
eGroups is now Yahoo! Groups
Click here for more details
http://us.click.yahoo.com/kWP7PD/pYNCAA/4ihDAA/2n6YlB/TM
---------------------------------------------------------------------_->

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

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

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/