I might just add that I am not aware of experienced clinical modellers ever making use of cardinality constraints. It has just proven too hard for people to get their head around, even when there are some potential uses e.g expressing an XSD-type 'choice'.
There was also a known feature of the original Archetype Editor which (correctly) incremented the cardinality minimal constraint whenever an item within the container was made mandatory. However, it did not decrement the cardinality constraint if a child item was subsequently made non-mandatory. This is probably correct behaviour, since the intention of the modeller in this case cannot be known but it has meant that cardinality minimal constraints have appeared unintentionally. Ian Dr Ian McNicoll mobile +44 (0)775 209 7859 office +44 (0)1536 414994 skype: ianmcnicoll email: i...@freshehr.com twitter: @ianmcnicoll Co-Chair, openEHR Foundation ian.mcnic...@openehr.org Director, freshEHR Clinical Informatics Ltd. Director, HANDIHealth CIC Hon. Senior Research Associate, CHIME, UCL On Thu, 29 Nov 2018 at 10:54, Thomas Beale <thomas.be...@openehr.org> wrote: > Hi Georg, > > the other answers are right, but for reference you may want to read the > relevant part of the ADL specification (ADL2 version > <https://www.openehr.org/releases/AM/latest/docs/ADL2/ADL2.html#_constraints_on_complex_types>; > ADL1.4 version > <https://www.openehr.org/releases/AM/latest/docs/ADL1.4/ADL1.4.html#_structure_3>). > The main thing to understand is that 'cardinality' applies to container > attributes, and that 'occurrences' defines how often an object node may > appear in the data. > > The ADL2 version gives the clearer explanation, and the main semantics of > cardinality and occurrences have not changed from one to the other. > > - thomas > On 29/11/2018 10:09, Georg Fette wrote: > > ------------------------------ > > Hi Diego, > The items inside the CLUSTER look like this: > > CLUSTER[at0001] matches { > items cardinality matches {2..*; ordered} matches { > ELEMENT[at0002] matches { > value matches { > DV_COUNT matches {*} > } > } > ELEMENT[at0003] matches { > value matches { > DV_TEXT matches {*} > } > } > } > } > > It could be that I not yet fully understand ADL, therefore I would need to > verify/falsify some assumptions I make: > > - Both elements (at0002, at0003) have an implicit cardinality of "1..1" ? > - The keyword "ordered" just indicates that the items inside an instance of > the cluster at0001 have to maintain the order in which they were defined. The > order does not affect an enforced order of the types of the elements inside > the cluster ? > - What is true?: > * The cluster at0001 may include the elements at0002 and at0003 in any > order an unlimited amounts of them as long as the cluster includes at least 2 > of them. The specification inside of at0001 just gives the set of possible > elements that may appear as items of at0001. E.g. "at0003, at0003, at0002, > at0003, ..." > * The cluster at0001 has to include at least 2 elements in the order > given in the at0001 definition and the order may be repeat an unlimited > amount of times, e.g. "at0002, at0003, at0002, at0003, ..." > > Greetings > Georg > > >Hello Georg, > > > >What (and how many) objects you have inside the items attribute? > >Think the cardinality as the "vector" capacity, and inside you can put them > >in order (depending on their occurrences, they may even not appear at all) > > > >Regards > > > >El jue., 29 nov. 2018 10:31, Georg Fette <georg.fette at uni-wuerzburg.de > ><http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org>> > > >escribió: > > > Am 29.11.2018 um 10:30 schrieb Georg Fette: > > Hello, > I have an archetype with a complex object derived of CLUSTER with > "items cardinality matches {2..*; ordered}" > and those two items are also defined inside the complex object. > I understand the semantics of this definition that both items always have > to appear together inside the cluster but the package of those two items > may appear any number of times. > Is it allowed for instances of this archetype to have an uneven number of > items > 2 inside this cluster, because that would still suffice the > restriction of having 2..* children. Or do the instances always have to > have both elements as a package that are defined as items in this cluster. > As I am not the author of the archetype I do not completely understand how > the definition has to be interpreted. > Greetings > Georg > > > -- > --------------------------------------------------------------------- > Dipl.-Inf. Georg Fette Raum: B001 > Universität Würzburg Tel.: +49-(0)931-31-85516 > Am Hubland Fax.: +49-(0)931-31-86732 > 97074 Würzburg mail: georg.fe...@uni-wuerzburg.de > --------------------------------------------------------------------- > > > _______________________________________________ > openEHR-technical mailing > listopenEHR-technical@lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > -- > Thomas Beale > Principal, Ars Semantica <http://www.arssemantica.com> > Consultant, ABD Project, Intermountain Healthcare > <https://intermountainhealthcare.org/> > Management Board, Specifications Program Lead, openEHR Foundation > <http://www.openehr.org> > Chartered IT Professional Fellow, BCS, British Computer Society > <http://www.bcs.org/category/6044> > Health IT blog <http://wolandscat.net/> | Culture blog > <http://wolandsothercat.net/> | The Objective Stance > <https://theobjectivestance.net/> > _______________________________________________ > openEHR-technical mailing list > openEHR-technical@lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >
_______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
