optional existence, cardinality and occurrences.
2009/7/9 Thomas Beale thomas.beale at oceaninformatics.com: 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
optional existence, cardinality and occurrences.
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 typesso 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
optional existence, cardinality and occurrences.
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090709/958fbb08/attachment.html
optional existence, cardinality and occurrences.
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 at oceaninformatics.com 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 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- David Moner Cano Grupo de Inform?tica Biom?dica - IBIME Instituto ITACA http://www.ibime.upv.es Universidad Polit?cnica de Valencia (UPV) Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta Valencia ? 46022 (Espa?a) -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090703/025ca78c/attachment.html
optional existence, cardinality and occurrences.
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 From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of David Moner Sent: Friday, 3 July 2009 4:40 PM To: For openEHR technical discussions Subject: Re: optional existence, cardinality and occurrences. 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 at oceaninformatics.com 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 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- David Moner Cano Grupo de Inform?tica Biom?dica - IBIME Instituto ITACA http://www.ibime.upv.es Universidad Polit?cnica de Valencia (UPV) Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta Valencia ? 46022 (Espa?a) -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090703/6a004da5/attachment.html
optional existence, cardinality and occurrences.
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090703/c47f74e9/attachment.html
optional existence, cardinality and occurrences.
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
:-)
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 at oceaninformatics.com
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 ;-)
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
*
*
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
--
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es
Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090703/23e2cb88/attachment.html
optional existence, cardinality and occurrences.
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 On Fri, Jul 3, 2009 at 3:17 PM, Thomas Beale thomas.beale at oceaninformatics.com wrote: 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
