Hi all, I also think constraining functions, i.e. computed attributes, in the reference model classes can be counter-intuitive and probably unnecessarily complex.
In clinical modelling space, a function is supposedly less obvious to modeler than an ordinary RM class attribute. Since the result of the function is derived from several member attributes and the algorithm is documented in the RM specs, it's reasonable to assume that a constraint expressed on derived values is less understood than that on an attribute. If a derived value is so commonly used and indeed necessary in archetyping, why not make it an attribute in the first place. In the engineering space, constraints on static attributes seem to be more straight-forward to work with. Default data instance can be safely generated by the combined definitions of archetypes/templates. Upon saving the data instance, the invariants, or rules in the latest specs, would be used against the instance for final validation. Now considering how to handle the constraints on functions, they can't really be used for instance generation since they are dependent on other attributes. So they would probably only be used in the final validation just as rules/invariants. So indeed, why not implement these function constraints as invariants/rules to start with? In summary, I would vote for only allowing constraints on ordinary, static attributes. Use invariants or rules to achieve same effects as constraints on functions. Cheers, Rong On 11 January 2012 11:19, Sebastian Garde <sebastian.garde at oceaninformatics.com> wrote: > > > 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 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 > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >
