Re: [xtm-wg] Questions about Merging.

[Steve Pepper <pepper@ontopia.net>]

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


------------------------ Yahoo! Groups Sponsor ---------------------~-~>
eGroups is now Yahoo! Groups
Click here for more details
http://click.egroups.com/1/11231/0/_/337252/_/982703268/
---------------------------------------------------------------------_->

To Post a message, send it to:   xtm-wg@eGroups.com

To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com