On 10/01/2012 09:52, Sebastian Garde wrote: > Thomas, Rong and I had a similar discussion many moons ago, and in the > end I think we agreed to disagree ;-) > > A few other functional properties come to mind such as "type" in > PARTY_RELATIONSHIP and "is_integral" in DV_QUANTITY. > These are more or less frequently constrained in archetypes as well. > > At the very least my thinking is that it is counter-intuitive to > constrain them directly. > Also, for the Java validator that is also used in CKM, we had to > introduce a special hard-coded check for "commonly constrained > functional properties" such as the three mentioned here.
I am a bit surprised by that, because they can be represented easily in a standard way. Have a look at this schema <http://www.openehr.org/svn/knowledge2/TRUNK/rm_schemas/openehr_demographic_102.bmm>and search for 'is_computed'. > > Re "offset": > I wonder if offset could be expressed as an attribute with an > invariant for its validity. well then it would be redundant with the 'time' attribute of EVENT. > > In fact, looking at the specs, there already is an invariant > "Offset_validity": > inv: offset <> Void and offset = time - parent.origin > > Now I wonder what the point of this invariant is when offset is a > function that is already defined to be "time - parent.origin"? this is what defines it. Arguably it should have been a post-condition of the function rather than a class invariant. But the effect is essentially the same. - thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120110/971dcf7c/attachment.html>
