virus alert(was Re: [xtm-wg] Topic Naming Constraint question)

["Nikita Ogievetsky" <nogievet@cogx.com>]

Lars, 

I believe that you are considering 
<baseName> elements to be just labels.
If you just need a label, use 
<resourceData> with <instanceOf> #description or else.
Or, as Chris suggested, use <variant>. 

Otherwise <baseName> is just as important 
for <topic> identification as <subjectIdentity>. 
And so, the situation I described with PSI
is just as potential a conflict as the one you described.

In other words <baseName> is not for labeling!!!
Argument that this is inconvenient (I agree) is not sufficient.
There are to many inconvenient things here.
We still do not have straightforward ways of expressing probability 
weights and other metadata ... Something that I am struggling with
for over a year now.

The name that you want to specify is a piece of metadata,
not important for mapping. (because you can not use it for identifying)
XTM is about mapping so you have to struggle.
Hopefully answer will come from RDF.

I was actually suggesting to put <variant> element as an optional child
of all <XTM> elements, not only of <baseName>
That would solve many-many problems.

[Lars]
> * Nikita Ogievetsky
> | what if topic A has PSIa1 and PSIa2
> | and topic B has PSIb1 and PSIb2
> | 
> | such that 
> | PSIa1=PSIb1
> | and 
> | PSIa2 != PSIb2
> | 
> | Is this a normal situation?
> 
> Probably. There is at least nothing problematic about it.  The result
> will be a topic C that has subject indicators PSI(a|b)1, PSIa2, and
> PSIb2. (F.5.2 and F.5.1.)

It is just as problematic as your <baseName> conflict
If I am merging my "good" <topicMap> with some
hell-knows-from-where <topicMap> and if
I had 
<topic> A with PSI1
and 
<topic> B with PSI2

and in the hell-knows-from-where <topicMap> 
there is 
<topic> C with PSI1 and PSI2 

As a result, all of a sudden <topic>s A and B (and C) are merged.
Now how do I rollback after I realize that
hell-knows-from-where <topicMap> 
is actually a VIRUS?
(there is no way to distinguish between A and B characteristics anymore)

>  
> | Other problems are if A and B have same base names in one scope and
> | different names in different scopes.
> | 
> | Should they be merged?
> 
> Yes. The result is a topic that has the the union of the base names of
> A and B. Annex F is crystal clear on this (F.5.1).
> 
...

> * Steve Pepper
> |
> | The TNC does indeed apply in this case. I put forward a proposal
> | along the lines you suggest in Paris, but it didn't carry the day. I
> | guess the campaign against the TNC was a bit too late getting
> | underway.
> 
> * Nikita Ogievetsky
> | 
> | Actually in this case a program should detect a conflict and do
> | nothing other then mark this suspect topics and present a list of
> | them for a human operator to decide.
> 
> Any processor which does this does not conform to the specification.
> F.5.3 says the topics should merge, F.5.1 says the resulting topic has
> the union of their subject indicators.

I thing that some F.5.* are contradictory and open doors for viruses.

Thanks,

Nikita.

----------------------------------------------------------
Nikita Ogievetsky               Cogitech Inc
XML/XSLT/XLink/TopicMaps   Consultant
nogievet@cogx.com   --   (917) 406-8734
http://www.cogx.com     Cogito Ergo XML



------------------------ 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/