Possible error in AOM 1.4

Specifications ADL
1

In C_MULTIPLE_ATTRIBUTE invariants:

Members_valid: members /= Void and then members.for_all(co: C_OBJECT | co.occurrences.upper <= 1)

Then we have archetypes like:

			events cardinality matches {1..*; unordered} matches {
				POINT_EVENT[at0002] occurrences matches {0..*} matches {

a. events is C_MULTIPLE_ATTRIBUTE
b. POINT_EVENT is a C_OBJECT in the CMA.members and COBJECT.occurrences.upper is *, which violates the invariant

Not sure if I’m missing something here, though the invariant doesn’t seem correct.

2

That seems an error, since it doesn’t allow any occurrence bigger than 1.

At first I though maybe it meant to be a >:

members /= Void and then members.for_all(co: C_OBJECT | co.occurrences.upper >= 1)

But why would we want to technically avoid something like this?

content existence matches {0..1} cardinality matches {0..*; unordered} matches {
    SECTION[at0001] occurrences matches {0..0} matches {*}  -- SECTION
    OBSERVATION[at0002] occurrences matches {0..*} matches {*}  -- OBSERVATION
}

Could it be that that invariant should be be assigned to the C_SINGLE_ATTRIBUTE instead? There it could make sense, for defining alternative C_OBJECTS. Since we only can have one of them at the instances, we don’t need to define any upper occurrence bigger than 1.

ELEMENT[at0006] occurrences matches {0..*} matches {  -- ELEMENT
    value existence matches {0..1} matches {
        DV_BOOLEAN[at0007] occurrences matches {0..1} matches {*}  -- DV_BOOLEAN
        DV_TEXT[at0008] occurrences matches {0..1} matches {*}  -- DV_TEXT
    }
}
3

I think that is probably right. Somehow this invariant ended up on the wrong class. In ADL2, there is only C_ATTRIBUTE, and no such invariant anyway. I will change this in the UML.

4

I agree the invariant is for SINGLE_ATTRIBUTE.

5

I have fixed the UML extraction so that the AOM1.4 model is finally included in the UML site output. See Software Engineering Portal

6

@thomas.beale about the UML correction, note the error is in the table invariants, not in the UML: Archetype Object Model 1.4 (AOM1.4)

@thomas.beale @damoca

I also detected something that might be missing:

When a C_SINGLE_ATTRIBUTE.alternatives().size() > 1, for all C_OBJECT in alternatives(), the C_OBJECT.occurrences.lower == 0

Because if any alternative has lower 1, it means that is the only alternative of object that can occur at that attribute (since it’s a single attribute).

I can’t find that constraint/invariant in AOM 1.4, and it’s key for modeling tools, and for archetype/template validation.

What do you think?

7

I found the corresponding rule in the Archetype Object Model 2 (AOM2) specifications

image
image992×113 5.68 KB

8

That’s what we validate in LinkEHR Studio:

image
image734×239 10.8 KB

However, now that I think about it, I have some doubts. From a purely technical approach it seems a valid rule since, otherwise, in the instances only one of the children C_OBJECT would be compliant with the archetype.

But if we look at the context, (i.e. we are defining an alternative inside a C_SINGLE_ATTRIBUTE) defining those lower occurrences to 1 is as good as saying that a C_SINGLE_ATTRIBUTE has two possible children, when that will never happen in the instances. Moreover, if we could not use those {1} occurrences, how would we constrain that an ELEMENT cannot be null? They only way to do that is by defining that the alternatives, which are exclusive, have a minimum occurrence of 1.

I believe that the second interpretation is the correct one.