OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

topicmaps-comment message

[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