ADLParser exception :-/

Implementers (archive)
21

Mattias Forss wrote:

  

Agreed.

What I like about this approach is that it unifies all possible constraints
on QUANTITYs eliminating the need to use C_COMPLEX_OBJECT. This will reduce
the complexity of the RM object creation logic since essentially all leaf
node constraints can be covered by either C_DOMAIN_TYPEs and
C_PRIMITIVE_TYPEs.
    
There are leaf node constraints that won't be covered by either of
these, for example MULTIMEDIA.

MULTIMEDIA is not a "leaf node" from the point of view of ADL; only the
basic types are, and we will probably make the C_DOMAIN_TYPEs as well.

How would the RM object creation logic
complexity be simplified when the openEHR specs say that there should
be three ways to express constraints on the RM.

1) Standard cADL constraint e.g. defining_code matches { CODE_PHRASE ... }
2) Customised cADL constraint e.g. defining_code matches { [local::at0001] }
3) dADL constraint which represents an instance of an domain type constraint

So depending on how the constraint is expressed, different object
creation methods must be used...
  

there are really only two methods - 1) and 3) above; method 2) is just a
syntax level equivalent for 3), and the last two are interchangeable.

Personally, I think it's stupid to use more than one way to express
constraints, but in order to allow compatibility with EN13606
archetypes (which may have constraints expressed in standard cADL) the
complexity of RM object creation cannot be reduced.
  

the reason we have 2 ways to do it is that it is needed. The basic way
doesn't always produce the right result, so a special plug-in object is
needed. In our first prototype of an archetype-based system 5 years ago
in Australia, _all_ the archetype objects were expressed in C_XXX form
(we used to call it A_XXX classes back then). This was not generic
enough, and was clumsy, since it meant having a lot of classes in the
AOM that were directly dependent on the RM. Now we have a very generic
AOM with a few small plug-in C_XXX classes to cope with the a different
factoring of constraints that generic ADL doesn't give us....

It does mean that there are multiple creation methods, but the approach
in my view should be:

- if there is a plug-in C_DOMAIN_TYPE type available, always use it to
represent constraints for the corresponding RM type
- if there is a syntax equivalent for this type, then use it
- otherwise use generic ADL

Things may change in the future as we do more research. You have to
remember that ADL didn't exist anywhere in the world until a few years
ago - the only precedent was some disparate theoretical ideas in the
F-logic, terminology, semantic modelling and software engineering
domains. We are still on the leading edge, so it can be frustrating at
times...

- thomas beale

22

Mattias Forss wrote:
>
>> Agreed.
>>
>> What I like about this approach is that it unifies all possible constraints
>> on QUANTITYs eliminating the need to use C_COMPLEX_OBJECT. This will reduce
>> the complexity of the RM object creation logic since essentially all leaf
>> node constraints can be covered by either C_DOMAIN_TYPEs and
>> C_PRIMITIVE_TYPEs.
>>
>
> There are leaf node constraints that won't be covered by either of
> these, for example MULTIMEDIA.
MULTIMEDIA is not a "leaf node" from the point of view of ADL; only the
basic types are, and we will probably make the C_DOMAIN_TYPEs as well.
> How would the RM object creation logic
> complexity be simplified when the openEHR specs say that there should
> be three ways to express constraints on the RM.
>
> 1) Standard cADL constraint e.g. defining_code matches { CODE_PHRASE ... }
> 2) Customised cADL constraint e.g. defining_code matches { [local::at0001] }
> 3) dADL constraint which represents an instance of an domain type constraint
>
> So depending on how the constraint is expressed, different object
> creation methods must be used...
>
there are really only two methods - 1) and 3) above; method 2) is just a
syntax level equivalent for 3), and the last two are interchangeable.

Aha, maybe this is the same issue for CODED_TEXT as the one I found
with ORDINAL? If 2) is a syntax level equivalent for 3) it should then
be a leaf node:

ELEMENT... {value matches {[local::at0001]} }

However, it seems to me that [local::at0001] can be either a syntax
equivalent to CODE_PHRASE or C_DV_CODED_TEXT.

I have understood things this way. 2) is a syntax shortcut to 1) if
[local::at0001] is a CODE_PHRASE, but if [local::at0001] is a
C_DV_CODED_TEXT it is a syntax shortcut to 3) and then that could be
directly under the value attribute of an ELEMENT.

Could you explain how it should be. I'm getting confused about this part..

it that 2) are supposed to be real leaf constraints, in the example it
would be a C_DV_CODED_TEXT

It does mean that there are multiple creation methods, but the approach
in my view should be:

- if there is a plug-in C_DOMAIN_TYPE type available, always use it to
represent constraints for the corresponding RM type
- if there is a syntax equivalent for this type, then use it
- otherwise use generic ADL

I like this approach and this is the way I try to use it in the editor.

Things may change in the future as we do more research. You have to
remember that ADL didn't exist anywhere in the world until a few years
ago - the only precedent was some disparate theoretical ideas in the
F-logic, terminology, semantic modelling and software engineering
domains. We are still on the leading edge, so it can be frustrating at
times...

Yes I understand why the different methods exist. I didn't mean to
critisize, but as someone who aren't that experienced in this domain
it's sometimes easy to get frustrated. Your explanations and
suggestions above are good and should be documented somewhere because
they are important for people to know when and why the different
methods exist.

Mattias