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] Nikita's comments



* Daniel Rivers-Moore
|
| The intent (I thought) was that it was indeed an error (in a
| Consistent Topic Map) for there to be two members in the same
| association with the same role,

That is what it says, but this means that an XTM document may
perfectly well have two members with the same role, but that an XTM
processor must pass on to its applications a topic map where those
two members have been merged.

| Nothing needs to be reified specially, since the topicRefs already
| point at topics which are the role players. 

This is correct, but what worries Nikita and me is that if someone has
reified one of those two members the reification will be broken by the
merge. Consider:

  <!-- taking some shortcuts here -->
  <association>
    <instanceOf>#family</instanceOf>

    <!-- #mother, #father -->

    <member id="d1">
      <roleSpec>#daughter</roleSpec>
      <topicRef href="#astri"/>
    </member>

    <member id="d2">
      <roleSpec>#daughter</roleSpec>
      <topicRef href="#silje"/>
    </member>
  </association>

  <topic id="t1">
    <!-- ... -->
    <subjectIndicatorRef href="#d1"/>
    <!-- ... -->
  </topic>


We now have a topic whose subject is defined by one of the members of
the #family association, so presumably the subject of this topic is
#astri's #daugther relationship to her #family.

The trouble is that in the object structure built from this XTM
document F.3.3 requires the two members to be merged, and this loses
the information about which of the members the topic t1 reifies.

The most reasonable way to represent this is to have a member object
that has a type (a topic) and a set of player objects, each of which
has a reference to the participating topic it represents.

Now, what does #d1 refer to?  In this case you can get by by making
#d1 the ID of the player object that refers to #astri, but if #d1 were
to contain several players (and #d2 remain as it is) this solution
would break down, since #d1 would no longer refer to a unique object.


The solution proposed in my previous email would solve this by
disallowing topicmaps where <member> elements get merged. So if you
want to reify only some of the players in a normalized <member> you
are forced to do it by other means.

Possible ways may be to create a topic that has <subjectIndicatorRefs>
to each <topicRef>, or, probably better, one topic per <topicRef> that
you want to reify and then an association to group them together, that
is then finally reified. It's an ugly solution, but better than the
alternatives, I think.

The main thing is that such a prohibition would ensure that you don't
blow your foot off accidentally without giving up the most practical
way to represent members.

--Lars M. 


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

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

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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC