[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: virus alert(was Re: [xtm-wg] Topic Naming Constraint question)
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/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC