optional existence, cardinality and occurrences.

Technical (archive)
1

Dear all,

as part of the specialisation semantics, which are nearly all
implemented in the ADL workbench, we have made existence, cardinality
and occurrences all optional. This is sensible for 'source' form
archetypes - i.e. it is natural that only overridden constraints be
stated in an archetype, if there is no override of either the reference
model or a specialisation parent archetype, where the latter is
relevant, then no constraint is needed.

The change is described in http://www.openehr.org/issues/browse/SPEC-303

We have not yet released a new version of the ADL workbench with this
change, but will soon. What I would like to know is if the implementers
of other archetype parsers, compilers etc can deal with this change.
Note that it would normally be part of implementing the wider ADL 1.5
semantics, since it is logically part of the specialisation semantics.

has anyone else considered implementing these semantics yet?

thanks

- thomas beale

2

I agree with the initial idea about the optionality of existence, occurrences and cardinality; there is no need to state them if they are not changed from the reference model.

But one problem arises with the cardinality. As far as I know, the only way to differenciate a C_Single_Attribute and a C_Multiple_Attribute while parsing the ADL and generating the AOM instance is through the ‘existence’ of the cardinality constraint. If we don’t have that keyword it is imposible to choose the correct attribute object.

At the Jira issue we can read “with reference model checking…”, but making the ADL parsers dependent of the RM is absolutely not a good idea in my opinion.

2009/6/30 Thomas Beale <thomas.beale@oceaninformatics.com>

3

Hi David,

We need to differentiate the AOM from ADL, just because the AOM makes cardinality optional doesn’t mean that ADL does not require a cardinality keyword. Remember that ADL is just a serialisation of the AOM just as the AOM can be serialised using XML.

On a related topic, I think that the attributes of cardinality may need to be optional for the same reasons as occurrences and existence. Therefore for the reasons that David states below, I wonder if it is reasonable to make cardinality mandatory and its attributes optional instead.

Regards

Heath

4

David Moner wrote:

I agree with the initial idea about the optionality of existence, occurrences and cardinality; there is no need to state them if they are not changed from the reference model.

But one problem arises with the cardinality. As far as I know, the only way to differenciate a C_Single_Attribute and a C_Multiple_Attribute while parsing the ADL and generating the AOM instance is through the ‘existence’ of the cardinality constraint. If we don’t have that keyword it is imposible to choose the correct attribute object.

yes, that was one of the reasons for making it mandatory originally. The way it has to be handled is in the presence of a RM checking component. I have implemented this in the reference ADL parser with no problems - by the time the compiler reads any ADL text, it as loaded the reference model and can find any attribute in it, and detect whether it is a container or not.

At the Jira issue we can read “with reference model checking…”, but making the ADL parsers dependent of the RM is absolutely not a good idea in my opinion.

not dependent on ‘the’ RM - just capable of loading any RM. In the reference parser, I have implemented a simple meta-model expressed in dADL - see this page for details - http://www.openehr.org/wiki/display/dev/Machine-readable+model+representations+of+openEHR (this will explain why I did not use an XML-schema, to those who will be horrified by such an act :wink:

As such, the reference parser now loads any RM you want, and parses any archetype against its correct reference model - so there is no dependency.

  • thomas beale
5

From my point of view, to load a RM meta-model in the ADL/XML/OWL/whatever parser is still an unappropiate dependance. That would mean that any change on the RM, if there is any, also implies changing that meta-model for the parser to correctly work.

In my mind, a dual model system implementation should support a minimal working environment totally independent of the RM. That is, if I receive an archetype of a RM that I don’t know, I should still be able to parse it and show it in a minimal form (maybe ugly and redundant, but at least functional). In fact, I have always thought that the parsing of C_Domain_Type is not yet a well resolved problem, but that’s another topic :slight_smile:

Moreover, if we finally suppose that a meta-model of the RM is available at the time of parsing, obviously it will be also available at the time of working with the AOM. And then, coming back to the occurrences problem, why do we need C_SINGLE_ATTRIBUTE and C_MULTIPLE_ATTRIBUTE classes at the AOM? I mean, why don’t just have C_ATTRIBUTE class with its members attribute and an optional cardinality attribute that will be interpreted as single or multiple attribute through the RM meta-model?

Maybe a solution could be to add a new keyword such as “container” or “multiple” to specify that an attribute is multivalued and that has nothing to do with the cardinality. Maybe something like:

ITEM_TREE[at0001] matches {
items container matches { … }
}

or if we want to redefine the cardinality:

ITEM_TREE[at0001] matches {
items container cardinality matches {1..*; ordered} matches { … }
}

Just some quick thoughts,
David

2009/7/3 Thomas Beale <thomas.beale@oceaninformatics.com>

6

David Moner wrote:

>From my point of view, to load a RM meta-model in the
ADL/XML/OWL/whatever parser is still an unappropiate dependance. That
would mean that any change on the RM, if there is any, also implies
changing that meta-model for the parser to correctly work.

Hi David,

a change in the RM won't change the meta-model, which is the 'model of
the model'. The kind of classes I have used to express the meta-model
you can see here:
http://www.openehr.org/svn/ref_impl_eiffel/BRANCHES/specialisation/libraries/common_libs/src/basic_meta_model/

If there is a change in the RM, it will of course mean a change in the
RM schema expressed in terms of the meta-model. But that's exactly what
we want - to know if current (and new) archetypes are going to be valid
against the latest RM.

In my mind, a dual model system implementation should support a
minimal working environment totally independent of the RM. That is, if
I receive an archetype of a RM that I don't know, I should still be
able to parse it and show it in a minimal form (maybe ugly and
redundant, but at least functional).

this is difficult for two reasons. Firstly, archetypes only express
constraints _on a reference model_, and _in addition_ to a reference
model - they only express the additional constraints that the underlying
RM does not provide. So in general, archetypes are a partial construct.
Secondly, specialised archetypes have to be expressed in 'differential'
format (the same concept as object-oriented software classes), which are
even more partial - they depend on their specialisation parent, which in
turn depends on the RM. Essentially, you can parse it (we do that now)
but without the RM it is not a lot of use.

At the moment, I have changed the reference parser to only use the RM
during the first pass parsing process to detect which attributes are
containers and which ones are not. If we decide that we don't want to do
this, we have to go back to putting some kind of marker on container
attributes to indicate them as being containers (what we have done
historically). To my mind this has always been unsatisfactory, since a)
it forces you to put a cardinality constraint in, even though you are
not wanting to constrain the cardinality and b) it could actually be
wrong, and this gives rise to another source of errors. Think about a) -
how did the authoring tool know that the attribute in question was a
container or not? It must have had access to the reference model in some
form to know this. So we agree that the tool that builds the archetype
in the first place must know about the RM, but not the parser? It
doesn't seem consistent to me.

In fact, I have always thought that the parsing of C_Domain_Type is
not yet a well resolved problem, but that's another topic :slight_smile:

Moreover, if we finally suppose that a meta-model of the RM is
available at the time of parsing, obviously it will be also available
at the time of working with the AOM. And then, coming back to the
occurrences problem, why do we need C_SINGLE_ATTRIBUTE and
C_MULTIPLE_ATTRIBUTE classes at the AOM? I mean, why don't just have
C_ATTRIBUTE class with its members attribute and an optional
cardinality attribute that will be interpreted as single or multiple
attribute through the RM meta-model?

that is a fair question. In fact you are correct - it can be done
exactly as you say - in fact that is how the reference parser has done
it. However...I have to say that I would prefer to convert it to the
other model, not really to follow the AOM religiously (which we should
be doing but aren't;-) but to simplify the software. I might be wrong,
and maybe it is already simpler as it is....

Maybe a solution could be to add a new keyword such as "container" or
"multiple" to specify that an attribute is multivalued and that has
nothing to do with the cardinality. Maybe something like:

ITEM_TREE[at0001] matches {
                items container matches { ... }
}

or if we want to redefine the cardinality:

ITEM_TREE[at0001] matches {
                items container cardinality matches {1..*; ordered}
matches { ... }
}

I am not religiously against this, although personally I would not
favour it. But if the community preferred to go this way, and the
arguments seem solid enough, it could obviously be done without too much
difficulty. I think we need to think about the question I raised above:
how does the authoring tool reliably know whether an attribute is a
container or not? If this is via access to the RM, then does it make
sense to prevent the parser (and don't forget, an authoring tool much
parse archetypes to read them in in the first place) from seeing the RM?

- thomas

7

Hi there,
I need to check out the source code to for details, but at the moment I am using the combinations of cardinality, occurance and existence to figure out the semantics of certain choice operations.
For example, when a clinician wants a field with zero or up to N options, having these in AOM is the only way I can understand it. In UI this corresponds to a field with a label (Abdominal exam results) and a couple of checkboxes, where all or none of them or a combination of them may be selected. I am not sure I can clearly see the logic behind this choice though.
If I get it right, it is “now that we have reference model checking, we don’t need to express these in AOM, since expressing a constraint when it actually does not constraint anyting is not nice”. Am I correct?
Now in general I’d like to have RM model checking as an option that I can resort to when I want to. If RM model checking becomes a necessary piece of the way AOM is used, does not this introduce a spillover effect for those who want to use ADL + AOM in other RMs? At the moment ADL+ AOM is quite disconnected from RM, kind of a late binding type, but if RM checking replaces some of the things handled by AOM now, even if we get some sort of type safety, I feel this may make some things harder for us in the feature. (I hope the type safety, late binding early binding example is right)
A solid example is: I have the intention of expressing RM class like constructs with ADL in order to describe decision support related constructs. With the current AOM implementation, everyting that describes the structure is within AOM, but if some of this is shifted to RM, then in my case, I’d also need a modified RM checker to make use of AOM.
Now, if I’m getting all of this right, I’d rather have anything related to RM checking as an optional capability. This is not the only case we are using a constraining attribute to express no constraints at all. Free text in a field is defined with a constraint with allowed values of * , is it not? I can adopt to changes here, hoping that Java parser will adopt to them, but I’d love to have a couple of real life cases that demands these changes in exchange for my hours that’ll go for coding

Best Regards
Seref

8

Seref Arikan wrote:

Hi there,
I need to check out the source code to for details, but at the moment I am using the combinations of cardinality, occurance and existence to figure out the semantics of certain choice operations.
For example, when a clinician wants a field with zero or up to N options, having these in AOM is the only way I can understand it. In UI this corresponds to a field with a label (Abdominal exam results) and a couple of checkboxes, where all or none of them or a combination of them may be selected. I am not sure I can clearly see the logic behind this choice though.
If I get it right, it is “now that we have reference model checking, we don’t need to express these in AOM, since expressing a constraint when it actually does not constraint anyting is not nice”. Am I correct?

yes, that’s correct. Currently (ADL 1.4), we have existence, cardinality and occurrences as either mandatory, or with a default, so that they are always in the AOM parse tree, even if not set in the archetype. But the overall semantics of archetypes are ‘additional constraints on an underlying model’; it doesn’t make sense to have any of these multiplicity-related constraints either mandatory, or to have defaults for them. What we should have is each archetype containing only constraint ‘overlays’ on the ‘next model down’, which for unspecialised archetypes is the RM, and for specialised archetypes is the ‘stack’ of specialisation parents + the reference model - in much the same way as object-oriented class definitions work.

Now in general I’d like to have RM model checking as an option that I can resort to when I want to. If RM model checking becomes a necessary piece of the way AOM is used, does not this introduce a spillover effect for those who want to use ADL + AOM in other RMs?

no, it just means that they should give the reference model checking component a different RM schema to use. The openEHR schema I have used (this is not standardised!) is here - http://www.openehr.org/svn/ref_impl_eiffel/BRANCHES/specialisation/apps/adl_workbench/app/rm_schema.dadl (see http://www.openehr.org/wiki/display/dev/Machine-readable+model+representations+of+openEHR for explanations); clearly the same kind of schema could be defined for ISO 13606 or any other object model (I can’t say for sure about HL7v3 RMIM artefacts, because they are a custom construct, but an approximation could now doubt be made).

At the moment ADL+ AOM is quite disconnected from RM, kind of a late binding type, but if RM checking replaces some of the things handled by AOM now, even if we get some sort of type safety, I feel this may make some things harder for us in the feature. (I hope the type safety, late binding early binding example is right)

I would suggest that this thinking is seeing archetypes as a replacement for an information model, rather than a constraint facility for it.

A solid example is: I have the intention of expressing RM class like constructs with ADL in order to describe decision support related constructs. With the current AOM implementation, everyting that describes the structure is within AOM,

but is it? There are many attributes that most archetypes never mention, e.g. ENTRY.subject is rarely archetyped; COMPOSITION.context is only sometimes archetyped; there are many other such attributes whose values can’t sensibly be constrained before runtime.

but if some of this is shifted to RM, then in my case, I’d also need a modified RM checker to make use of AOM.
Now, if I’m getting all of this right, I’d rather have anything related to RM checking as an optional capability.

The problem with this is that you can’t check the validity of the archetypes in the first place (and don’t forget, the system’s job is to create RM instances ultimately - the archetypes are just a guide).

Now, you might argue that your system consumes only archetypes that are assumed to have been checked already (see the diagram http://www.openehr.org/wiki/display/spec/Development+and+Governance+of+Knowledge+Artefacts for an idea of the overall system in which this might occur). This is fair enough - it just means that another part of your system has already done the checking. The next thing you might say is: ok, but now if cardinality is no longer mandatory, my components can’t tell which attributes are container types and which are not. This would be true if your components were working from source artefacts only. In the near future however we need to move to a situation where the ‘compilation’ operation produces operational i.e. runtime-ready artefacts, which are:

  • inheritance-flattened
  • represented as an object serialisation of the AOM, e.g. in XML, dADL or whatever. They could be serialised still in ADL, but this is not the most useful format, because it doesn’t carry all the information - it needs the RM to be present.

This is what happens in object-oriented programming environments, although most of us never see it. People who know about C++ vtables, Eiffel ‘flat-forms’ and whatever the equivalents are in Java and C# are will know about this.

Admittedly we are not quite there today (I don’t know what the progress in the Java ADL compiler for supporting either RM checking or flattening is), so the question is: do we add a new keyword to ADL like David Moner suggested to indicate that an attribute is a container? As a long term idea, I don’t really like it, but as a short term fix, it would probably not be that hard to do (obviously easy for the parser, but the question of what effect on current archetypes is more difficult to answer).

This is not the only case we are using a constraining attribute to express no constraints at all. Free text in a field is defined with a constraint with allowed values of * , is it not? I can adopt to changes here, hoping that Java parser will adopt to them, but I’d love to have a couple of real life cases that demands these changes in exchange for my hours that’ll go for coding

the ‘*’ constraint means ‘anything goes’, i.e. no constraint. But normally there is no reason to mention an attribute at all, if there is no constraint to put on it.

It would be useful to know what state the Java ADL parser is in…

  • thomas beale
9

Seref Arikan wrote:

Hi there,
I need to check out the source code to for details, but at the moment I am
using the combinations of cardinality, occurance and existence to figure out
the semantics of certain choice operations.
For example, when a clinician wants a field with zero or up to N options,
having these in AOM is the only way I can understand it. In UI this
corresponds to a field with a label (Abdominal exam results) and a couple of
checkboxes, where all or none of them or a combination of them may be
selected. I am not sure I can clearly see the logic behind this choice
though.
If I get it right, it is "now that we have reference model checking, we
don't need to express these in AOM, since expressing a constraint when it
actually does not constraint anyting is not nice". Am I correct?

yes, that's correct. Currently (ADL 1.4), we have existence, cardinality and
occurrences as either mandatory, or with a default, so that they are always
in the AOM parse tree, even if not set in the archetype. But the overall
semantics of archetypes are 'additional constraints on an underlying model';
it doesn't make sense to have any of these multiplicity-related constraints
either mandatory, or to have defaults for them. What we should have is each
archetype containing only constraint 'overlays' on the 'next model down',
which for unspecialised archetypes is the RM, and for specialised archetypes
is the 'stack' of specialisation parents + the reference model - in much the
same way as object-oriented class definitions work.

Now in general I'd like to have RM model checking as an option that I can
resort to when I want to. If RM model checking becomes a necessary piece of
the way AOM is used, does not this introduce a spillover effect for those
who want to use ADL + AOM in other RMs?

no, it just means that they should give the reference model checking
component a different RM schema to use. The openEHR schema I have used (this
is not standardised!) is here -
http://www.openehr.org/svn/ref_impl_eiffel/BRANCHES/specialisation/apps/adl_workbench/app/rm_schema.dadl
(see
http://www.openehr.org/wiki/display/dev/Machine-readable+model+representations+of+openEHR
for explanations); clearly the same kind of schema could be defined for ISO
13606 or any other object model (I can't say for sure about HL7v3 RMIM
artefacts, because they are a custom construct, but an approximation could
now doubt be made).

At the moment ADL+ AOM is quite disconnected from RM, kind of a late binding
type, but if RM checking replaces some of the things handled by AOM now,
even if we get some sort of type safety, I feel this may make some things
harder for us in the feature. (I hope the type safety, late binding early
binding example is right)

I would suggest that this thinking is seeing archetypes as a replacement for
an information model, rather than a constraint facility for it.

A solid example is: I have the intention of expressing RM class like
constructs with ADL in order to describe decision support related
constructs. With the current AOM implementation, everyting that describes
the structure is within AOM,

but is it? There are many attributes that most archetypes never mention,
e.g. ENTRY.subject is rarely archetyped; COMPOSITION.context is only
sometimes archetyped; there are many other such attributes whose values
can't sensibly be constrained before runtime.

but if some of this is shifted to RM, then in my case, I'd also need a
modified RM checker to make use of AOM.
Now, if I'm getting all of this right, I'd rather have anything related to
RM checking as an optional capability.

The problem with this is that you can't check the validity of the archetypes
in the first place (and don't forget, the system's job is to create RM
instances ultimately - the archetypes are just a guide).

Now, you might argue that your system consumes only archetypes that are
assumed to have been checked already (see the diagram
http://www.openehr.org/wiki/display/spec/Development+and+Governance+of+Knowledge+Artefacts
for an idea of the overall system in which this might occur). This is fair
enough - it just means that another part of your system has already done the
checking. The next thing you might say is: ok, but now if cardinality is no
longer mandatory, my components can't tell which attributes are container
types and which are not. This would be true if your components were working
from source artefacts only. In the near future however we need to move to a
situation where the 'compilation' operation produces operational i.e.
runtime-ready artefacts, which are:

inheritance-flattened
represented as an object serialisation of the AOM, e.g. in XML, dADL or
whatever. They could be serialised still in ADL, but this is not the most
useful format, because it doesn't carry all the information - it needs the
RM to be present.

This is what happens in object-oriented programming environments, although
most of us never see it. People who know about C++ vtables, Eiffel
'flat-forms' and whatever the equivalents are in Java and C# are will know
about this.

Admittedly we are not quite there today (I don't know what the progress in
the Java ADL compiler for supporting either RM checking or flattening is),
so the question is: do we add a new keyword to ADL like David Moner
suggested to indicate that an attribute is a container? As a long term idea,
I don't really like it, but as a short term fix, it would probably not be
that hard to do (obviously easy for the parser, but the question of what
effect on current archetypes is more difficult to answer).

This is not the only case we are using a constraining attribute to express
no constraints at all. Free text in a field is defined with a constraint
with allowed values of * , is it not? I can adopt to changes here, hoping
that Java parser will adopt to them, but I'd love to have a couple of real
life cases that demands these changes in exchange for my hours that'll go
for coding

the '*' constraint means 'anything goes', i.e. no constraint. But normally
there is no reason to mention an attribute at all, if there is no constraint
to put on it.

It would be useful to know what state the Java ADL parser is in....

Hi all,

Sorry for being late on this.

Currently the Java ADL parser only does the parsing and produces the
AOM objects from ADL (pure parsing). RM based AOM validation is done
in a separate component "archetype-validator", which is now being used
in the CKM (thanks to Sebastian =)

The archetype-validator has access to the RM classes definitions
through a RMInspector class using Java reflection. More specifically,
the annotations in the Java implementation of RM classes are extracted
and used for RM related validations. The same RM inspection mechanism
is also used for other purpose in the rest of the Java implementation,
e.g. RM data binding between dADL, XML and in-memory RM objects. The
use of Java classes as the computer-readable form of RM definitions is
to minimize the maintenance since the Java classes are supposed to be
up-to-date according to the specs.

However, the platform-independent RM definition in dADL proposed by
Tom seems very attractive to me. It could be the single source of the
RM definitions for all major implementations. It clearly has
advantages against platform-specific solutions. Besides, dADL based RM
representation could be used to represent different versions of RM
releases to enable co-existence of different RM versions in the same
runtime system.

Regarding the question raised by Tom and David, I would prefer a
generic C_ATTRIBUTE with an optional cardinality attribute. So the
parser will only fill the list and cardinality when necessary without
really checking or guessing if it's a single or multiple attribute
it's dealing with. The necessary validation will only be done in late
stage when the RM definitions is available. The correct use of
C_ATTRIBUTE constraint will reply on the knowledge of underlying RM
classes, which should always be available to the authoring environment
and the EHR runtime systems.

This does differ from the current design that requires the parser to
decide if the attribute is single-valued or multiple-valued, which in
turn requires an extra keyword (e.g. "container") or mandatory
"cardinality" keyword. In my view, such keyword isn't really necessary
for parsing and doesn't really add any value in this stage.

Cheers,
Rong

10

Rong Chen wrote:

Hi all,

Sorry for being late on this.

Currently the Java ADL parser only does the parsing and produces the
AOM objects from ADL (pure parsing). RM based AOM validation is done
in a separate component "archetype-validator", which is now being used
in the CKM (thanks to Sebastian =)

The archetype-validator has access to the RM classes definitions
through a RMInspector class using Java reflection. More specifically,
the annotations in the Java implementation of RM classes are extracted
and used for RM related validations. The same RM inspection mechanism
is also used for other purpose in the rest of the Java implementation,
e.g. RM data binding between dADL, XML and in-memory RM objects. The
use of Java classes as the computer-readable form of RM definitions is
to minimize the maintenance since the Java classes are supposed to be
up-to-date according to the specs.
  
and this is the natural way to do this, in any language...

However, the platform-independent RM definition in dADL proposed by
Tom seems very attractive to me. It could be the single source of the
RM definitions for all major implementations. It clearly has
advantages against platform-specific solutions. Besides, dADL based RM
representation could be used to represent different versions of RM
releases to enable co-existence of different RM versions in the same
runtime system.
  
just to explain a little: in an idea world, of course, we could have a
single beautiful UML model expressed in comprehensible XMI (as opposed
to the XMI that we really have) and it would have a guaranteed reliable
mapping into all the programming languages and XML-schema. However, this
doesn't exist today; the programming languages all have different models
of things like inheritance, genericity; most can't implement UML; XSD
isn't even OO and has a messy mixture of additive and subtractive
semantics over inheritance, plus other problems to do with representing
container types....so in the real world, we have to have a plan B. What
I have done is a plan B, which seems the best I could do given the messy
facts of life!

Regarding the question raised by Tom and David, I would prefer a
generic C_ATTRIBUTE with an optional cardinality attribute. So the
parser will only fill the list and cardinality when necessary without
really checking or guessing if it's a single or multiple attribute
it's dealing with. The necessary validation will only be done in late
stage when the RM definitions is available. The correct use of
C_ATTRIBUTE constraint will reply on the knowledge of underlying RM
classes, which should always be available to the authoring environment
and the EHR runtime systems.

This does differ from the current design that requires the parser to
decide if the attribute is single-valued or multiple-valued, which in
turn requires an extra keyword (e.g. "container") or mandatory
"cardinality" keyword. In my view, such keyword isn't really necessary
for parsing and doesn't really add any value in this stage.
  
Nor do I really, unless we accept David Moner's argument that we should
be able to do some level of archetype-based parsing without having any
access to the reference model. But as I already responded: how did the
original archetype author know which attributes were containers and
which ones not - which he/she has to know to be able to build the
archetype properly - unless the authoring tool knows about the reference
model.

Simplifying the AOM to only C_ATTRIBUTE would be fine by me;
consequences that we would need to think about: the published ISO 13606
standard would be out of date (but it already is due to other changes
anyway); are there other tools or scripts etc that rely on the current
1.4 AOM spec structures?

- thomas