RE: [xtm-wg] Nikita's comments

[Daniel Rivers-Moore <daniel.rivers-moore@rivcom.com>]

Ah, now I understand.

Actually, this harks back to some comments I made earlier (before the Paris
meetings), when I said I thought there was an item of structure missing from
the syntactic construct. (I won't repeat the point here - it is well
documented in a number of my earlier emails).

For me, rhw member element in the family association we are discussing meant
"the players of the daughter role in this family". For you, it means "Astri,
as player of the role daughter in this family"

I believe the correct way to say what you want to say is to create 
separate associations - in one of them, Astri plays the daughter role, and
in the other, Silje plays the daughter role. They are not the same
association. They are individual person-family relationships.

If you need a single association that brings together all the people that
play the role of daughter, you can do that, but you'd better create a
subject identifier, or at least a description occurrence, that makes clear
to readers or other co-authors that this is what is intended, so no-one will
be tempted to treat an association that means "The association between all
the daughters and the family, and Silje is one" as being synonymous with
"The daughter association between Silje and her family".

Does this help, or just further confuse?

Daniel

-----Original Message-----
From: Lars Marius Garshol [mailto:larsga@garshol.priv.no]
Sent: 09 February 2001 12:34
To: xtm-wg@yahoogroups.com
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. 



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://click.egroups.com/1/11231/0/_/337252/_/981724926/
---------------------------------------------------------------------_->

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

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