Hi Thomas,
Other than the requirement for specialisation, am I correct in thinking that
this would give us 'named choices' which I have suggested in the past (along
with named slots)? This would be very helpful in understanding the thinking
behind the choice construction which is not always evident, particularly
when selecting appropriate an appropriate choice at template time.
Does a similar issue apply to archetype slots? A common construct is to
place archetype slots within a cluster so that they can be 'named'. This
seems to me to unnecessarily overcomplicate the archetype.
Ian
Dr Ian McNicoll
office / fax +44(0)141 560 4657
mobile +44 (0)775 209 7859
skype ianmcnicoll
Consultant - Ocean Informatics ian.mcnicoll at oceaninformatics.com
Consultant - IRIS GP Accounts
Member of BCS Primary Health Care Specialist Group ? www.phcsg.org
2008/7/15 Thomas Beale <thomas.beale at oceaninformatics.com>:
>
>
> Here is a technical problem which is so far very rare, but probably
> requires a better solution than we have now. In the current release of the
> ADL specification, section 5.3.3 describes rules for constraints on a
> single-valued attribute:
>
> 5.3.3 Single-valued Attributes
> Repeated blocks of object constraints of the same class (or its subtypes)
> can have two possible meanings in cADL, depending on whether the cardinality
> is present or not in the containing attribute block. With no cardinality,
> the meaning is that each child object constraint of the attribute in
> question is a possible alternative for the value of the attribute in the
> data, as shown in the following example:
>
> ELEMENT[at0004] matches { --
> speed limit
> value matches {
> QUANTITY matches {
> magnitude matches {|0..55|}
> property matches {"velocity"}
> units matches {"mph"} -- miles
> per hour
> }
> QUANTITY matches {
> magnitude matches {|0..100|}
> property matches {"velocity"}
> units matches {"km/h"} -- km per
> hour
> }
> }
> }
>
> Here, the cardinality of the value attribute is 1..1 (the default), while
> the occurrences of both QUANTITY constraints is optional, leading to the
> result that only one QUANTITY instance can appear in runtime data, and it
> can match either of the constraints.
>
> Two or more object blocks introduced by type names appearing after a
> single-valued attribute (i.e. for which there is no cardinality constraint)
> are taken to be alternative constraints, only one of which needs to be
> matched by the data.
>
> Note that there is a more efficient way to express the above example, using
> domain type extensions See Customising ADL on page 117 for examples.
>
>
> In the current work I am engaged in to tighten up the semantics of
> specialisation, we have the problem that if the above kind of constraint
> were stated, and needed to be specialised in a child archetype, it is
> difficult to achieve without [at-code] markers as we have on higher-level
> nodes in archetypes. Currently, no at-codes are used on objects nodes
> defining constraints on the ELEMENT.value attribute, becasuse none is needed
> - it does not add anything useful, and would require pointless pollution of
> the archetype ontology with obvious definitions like 'quantity constraint'.
> However, in a very small number of cases, I believe that the above kind of
> construction, using more than one alternative is actually used. To allow
> specialised archetypes to redefine such constraints, we would need to
> mandate the use of at-codes where such alternatives were created.
>
> If the impact was minimal, I would be tempted to propose that this rule be
> added to ADL, to ensure that specialisation can always work unambiguously.
>
> any feedback on this idea welcome.
>
> - thomas beale
>
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080715/cd267caf/attachment.html>
