[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