Op 29-04-11 03:03, Heath Frankel schreef: > > I agree with Thomas, the reverse relationships should be derived from > the forward relationships. The RM doesn't necessarily need to be > reflected in the persistence model. >
Thanks Heath, this is indeed a pitfall, trying to reflect the RM. I sometimes fall into it too. > Having said that, we do have a fundamental issue regarding OBJECT_REF > with regard to using VERSIONED_OBJECT uid or VERSION uid, in some > cases it is desirable to use the former because you want the > relationship to exits even if the referenced object is revised, whilst > in other case this may not be safe practice. I think this issue > deserves some discussion and a Wiki page for the outcome. > A PartyRelationship can change in its details without change to the source and target-attribute. For example, the meaning of the Relation can change, a wife can become an ex-wife. Still the same target and source. As the specs are now: When this happens the target-party will need a new version because one of its attributes have changed (because the LocatableRef changed), and the PartyRelationship needs a new version, because its details changed. I think it is desirable that in a case like this, only the PartyRelationship need a new version, not the target-party, and if I am right, it is sufficient to use a PartyRef as ReverseRelation instead of a LocatableRef This idea is extra confirmed because it does not seem logically to write a new version of a PartyRelationship in case the source of the target change, because, in that case, the relation doesn't exist any more, I cannot imagine a situation in which there would be a reason to prolong the lifetime (write a new version) of a PartyRelationship when the relation finish to exist. But, I am not sure. Bert -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110429/7738699f/attachment.html>
