Re: [xtm-wg] The Topic Naming Constraint

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

* Steven R. Newcomb
| * Geir O. Gronmo
| >   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).
| 
| Right.  But what's wrong with calling the element type that contains
| the string to be matched <baseNameString>?  It's consistent with years
| of popular usage.  

Ok, lets turn it around and say that <baseNameString> is used for
identification. Then why can there be variants of the identifiers? Isn't
is more sensible to have variants on occurrences instead if that was the
case?

| > 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.
| 
| That can only happen if the authors don't know what <baseName> means.

If you mean that the current wording of the standard is in error that is 
certainly the case. I for sure cannot read from the standard that
basenames aren't used for labelling purposes.
 
| I guess you're saying that authors don't know what <baseName> means.
| Whose fault is that?  It's not the fault of the XTM Spec, nor of ISO
| 13250, both of which are crystal-clear about this.

I wouldn't say crystal-clear. :)

| > 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.
| 
| There is something fundamentally amiss in your underlying assumptions
| here.  You seem to be saying that merging happens without somebody
| taking responsibility for the merge.  

Yes! Merges can happen for any reason whatsoever. A merge is from my
viewpoint most likely a user-initiated action, not author-initiated.

| Neither 13250 nor the XTM Spec
| says or implies any such thing as automatic unattended merging of
| arbitrary sets of topic maps.  Both of the standards are strictly
| limited to saying how a *single* topic map document (or, in the case
| of XTM, a single <topicMap> element) should be interpreted.

Hmm, interesting. So, when a user is presented with two topic maps (e.g
Steve Pepper's Opera Topic Map and the CIA World Factbook Topic Map) and
she would like to get a combined view on those two topic maps - doesn't
the topics of those two topic maps have to be merged before presenting
them to the user?

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/