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

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

* Nikita Ogievetsky
| 
| I believe that you are considering <baseName> elements to be just
| labels.

Exactly.

| If you just need a label, use <resourceData> with <instanceOf>
| #description or else.

I don't want a label, I want names for my topics that will be
displayed by all topic map software.  The trouble is that when I make
such names the TNC intervenes and I can't really find a good solution
to avoiding that intervention. I can't expect any software to display
my topics correctly if I do as you suggest.

| Or, as Chris suggested, use <variant>. 

See my reply to him.
 
| Otherwise <baseName> is just as important for <topic> identification
| as <subjectIdentity>.

I don't buy that. What makes you say this, and how do you envision
this working?

| In other words <baseName> is not for labeling!!!

I am having real trouble following you here. Our navigator displays
basenames as the names, or labels, if you wish, of topics. Do you mean
to say that it should stop doing this?

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

What kind of probability weights do you mean?  And what metadata is it
you want to attach that using occurrences will not let you attach?
 
| The name that you want to specify is a piece of metadata,

Well, yes, but it's a special kind of metadata, for which we have a
special construct. It's a name. A label. And I want all topic map
software to display it.  That's what a base name is for, surely?

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

It would also create many problems, since it would be a major change
to the model and require all topic map implementations to be
significantly changed.
 
* Lars Marius Garshol
|
| 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.)
 
* Nikita Ogievetsky
|
| 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)

Just about any construct can be abused in this way, Nikita. There is
nothing special about PSIs in this regard. You could say the exact
same thing about the 'import' statement in Python, the 'eval' of Lisp,
Perl, Python, ..., the 'execute external file' of many SQL clients,
the external entities of XML and so on and so forth.

The answer is that if you have a 'hell-knows-from-where <topicMap>'
you shouldn't merge it in before you know what it is. I don't see that
it is any more difficult than that.

* Lars Marius Garshol
|
| 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.
 
* Nikita Ogievetsky
|
| I thing that some F.5.* are contradictory and open doors for viruses.

Well, it's too late now.  We have a specification and we have to
either follow it or fix it.  You can't just shrug of a major part of
the specification in this way.  If you think the entire thing is
broken you should be up there on the rooftops shouting now.

--Lars M.


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