[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [xtm-wg] Questions about Merging.
Thank you, Steve. Your answers were extremely helpful! Jason. > -----Original Message----- > From: Steve Pepper [mailto:pepper@ontopia.net] > Sent: Tuesday, February 20, 2001 10:41 AM > To: xtm-wg@yahoogroups.com > Subject: Re: [xtm-wg] Questions about Merging. > > > At 23:18 10/02/01 -0800, Jason Diamond wrote: > >Regarding Annex F (XTM Processing Requirements), if these are > requirements > >why are they labelled informative and not normative? > > This is a little inconsistent, I agree. Basically, a decision > was taken in Paris that this annex would be informative, and for > various reasons, not least the lack of time, it wasn't deemed > appropriate to try and rectify this. But there is very definitely > a sense in which Annex F becomes normative by dint of the ways in > which it is referenced from the rest of the spec. > > The AG will have to clarify this in Paris. One thing to note is > that Annex F is in some sense a stop-gap measure intended to > state [some of] the most important principles while awaiting the > outcome of the TopicMaps.Org Processing Subgroup's deliberations. > These may or may not end up with a complete processing model, a > data model, a canonical form, a test suite, and various other > bits and pieces that might become part of the further development > of XTM. > > >Why is there no "Subject Equivalence Principle"? Is this assumed to be > >derived from Section 2.4 (Merging)? > > Yes, in conjunction with other equivalence principles. > > >Section 2.4 (Merging) states that topics have the same subject > if "they have > >one or more subject indicators in common". Is this meant to include the > ><topicRef> elements located inside the topics' <subjectIdentity> > elements or > >just the <subjectIndicatorRef> elements? > > Both. Two topics with a <subjectIdentity>:<topicRef> in common > have the same subject as the referenced topic and hence the same > subject as each other. All three would get merged. > > >Postcondition 3 of F.5.1 (Topic merge operation) says "The set of subject > >indicators of M is equal to the union of the set of subject > indicators of A > >and B." Does this also include <topicRef>s? If so, then if a > <topicRef> and > ><subjectIndicatorRef> are determined to be equivalent using F.3.1 > >(Equivalence of <subjectIndicatorRef> and <topicRef>), which one is > >discarded? This might be a moot point since B.4 (Referencing the Subject) > >only shows that a Topic has zero or more SubjectIndicators. Unless, of > >course, this includes <topicRef>s. > > Since a <subjectIdentity>:<topicRef> leads to merging with the > referenced topic it gets discarded in any case, whether or not > there are equivalent <subjectIndicatorRef>s. In other words, > <topicRef>s in <subjectIdentity> only make sense *before* processing; > after processing, the merging that has taken place renders them > superfluous. (There is no point in establishing identity with oneself!) > > >What I'm wondering is this: do XTM processors differentiate between > ><subjectIndicatorRef>s and <topicRef>s after deserializing an > XTM document? > >So, if the in-memory topic map was reserialized, should the > ><subjectIdentity> element contain identical <topicRef> and > ><subjectInidcatorRef> elements as the original document? > > I think my answer to this is that it depends on what you want the > application to do. <topicRef>s are really only <subjectIndicatorRef>s > with the special property that they can only reference topic elements. > So in one sense they can be blindly replaced by <subjectIndicatorRef>s. > On the other hand, in order to achieve round-tripping, an application > could choose to retain knowledge of the original form of serialization > and provide the option of using this when reserializing. > > >Postcondition 2 of F.5.1 (Topic merge operation) says "The set of name > >characteristics of M is equal to the union of the set of name > >characteristics of A and B." If two topics are deemed to have the same > >subject according to 2.4 (Merging) by virtue of having one > subject indicator > >in common but both topics have different base names in the same > scope, which > >base name gets discarded? The reason I ask is because 2.2.2.1 (Base Name) > >says "Base names are subject to the topic naming constraint, > which prohibits > >a processed topic map from containing multiple topics with the same base > >name in the same scope." (The definition for topic naming > constraint, by the > >way, doesn't state this although the definition for base name does.) > > No base name would get discarded. Any given topic can have multiple > (different) names in the same scope, so the names would simply be > accumulated. The TNC prohibits TWO topics from having the SAME name > in the SAME scope. It doesn't prohibit ONE topic from having MULTIPLE > names in the SAME scope. > > >Does the topic naming constraint apply to base names in the unconstrained > >scope? Topic "t35" in F.5.1 (Topic merge operation) contains two > base names > >in the unconstrained scope. If multiple base names within the > unconstrained > >scope are allowed then does Topic A (with only one base name in the > >unconstrained scope) address the same subject as Topic B (with two base > >names in the unconstrained scope) if Topic A's base name matches > only one of > >Topic B's or would Topic A be required to have both of Topic B's? > > The topic naming constraint does indeed apply to base names in the > unconstrained scope, and it is sufficient that A and B have one name > in common in any given scope. The complete set of names in that scope > (unconstrained or other) does not have to match exactly. > > Thank you for your many questions. This is what we like. Feel free to > ask more. > > Steve > > -- > Steve Pepper, Chief Technology Officer <pepper@ontopia.net> > Convenor, ISO/IEC JTC1/SC34/WG3 Editor, XTM (XML Topic Maps) > Ontopia AS, Maridalsveien 99B, N-0461 Oslo, Norway. > http://www.ontopia.net/ phone: +47-22805465 GSM: +47-90827246 > > > > To Post a message, send it to: xtm-wg@eGroups.com > > To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com > ------------------------ 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