On 10.01.2012 17:13, Thomas Beale wrote: > 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'. Sure - that's the sound approach if you need all functional properties. We just needed these three, because these seem to be the only ones that are a) functional and b) commonly constrained. I have never seen another functional property constrained so far. With Peter's input, it is then probably only 2 (because 'type' needs to be revisited anyway).
In our case, we didn't have to care about computed properties at all - or so we naively thought until we discovered these three! Until then we thought, that if a property is_computed, then we can actually compute it and don't need anything else... >> 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. Yes. I think the real reason why we are having this discussion is that we two different viewpoints here: Yours is coming from data-instance of an archetype point of view, whereas mine is coming from an archetype constraining point of view. In my view, having this redundancy would be better/clearer/more maintainable than having to constrain functional properties when creating archetypes. Your view, that in the data instance of the archetype, the actual time should be directly recorded (and not calculated via origin + offset) is valid of course. I guess the choice is do yo want computable items clear and tidy OR no redundancy in the attributes?? >> 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. What you are doing in this whole scenario is probably 100% correct, feasible, etc. On the other hand, it seems that it is a bit counter-intuitive for people like me who work more in the archetype creation world, rather the data instance of an archetype world, see above. Sebastian -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120111/a563a0a4/attachment.html>
