Excuse me the following question, maybe I am just looking over the answer all the time
What is the use of both together existence and occurences in case of a CSingleAtttribute.
And what if both have conflicting information?
For example, existence gives REQUIRED and occurrences gives minOccurs=0
Thanks for a short answer
Bert
Hi Bert,
existence is a property of CAttribute (multiple or single). It indicates if the attribute value (i.e. some object) must exists or can be null.
occurrences is a property of a CObject, and indicates how many instances of that object constraint can exist in the data.
It can be used on CObjects under CMultipleAttributes to indicate how many instances of each CObject (there can be multiple CObjects, e.g. systolic bp, diastolic bp etc, each of which could potentially have more than one instance in the data). Commonly, many objects under a CMultipleAttribute can only have one or zero occurrences, so occurrences is set to {0..1}
Occurrences on an object under a CSingleAttribute can only indicate 0..0 or 1..1 (based on an original value of 0..1). In theory, occurrences on an object under a CSingleAttribute could conflict with existence on the CSingleAttribute. Tools can easily check this (and they do).
hope this helps.
- thomas
I formulated the question a bit sloppy, but you picked it well up.
Your answer helps, Now I know that this is an acknowledged risk.
It is not a misunderstanding from my side.
thanks
Bert
How about this:
Since its function in CSingleAttribute is also done by CObject-attribute occurences, it could be removed from the CSingleAttribute. This would make tools that check this superfluous.
Bert
Hi Bert,
it can't really, because you can have CAttributes that have no CObject children. Setting the existence to {1} for example on such an attribute says that there have to be values, but says nothing further about them.
On the other hand, if there are child CObjects, these CObjects could each have occurrences set to {0..1} (e.g. if they are alternatives).
so it's not quite as simple as it seems. There probably is a simplification available in the future, but my suggestion for now, assuming you are using the Java library and existing openEHR archetypes, is to stick with the way the library works at the moment - I assume it does sensible things...
- thomas
I think, Thomas, the logic is as follows, the CSingleAttribute can, as in the specs, have one or more then one children (CObjects).
Only one can be chosen, the others are alternatives.
The CSingleAttribute can have existence 0..1 (OPTIONAL), 1..1 (REQUIRED) and 0..0 (NOTALLOWED).
The last one I don't understand, why having an attribute as it is defined to stay null.
But besides that, suppose you have a CSingleAttribute with REQUIRED set with more CObjects as alternatives in it.
All occurrences for the CObjects need then to be set to 0..1, every other setting is erroneous.
Occurrences 0..0 is useless, why define a CObject if it may never occur.
Occurrences 1..1 is useless, why define alternative CObjects if the one chosen is defined.
Maybe the occurrences of CObjects should not be looked at when child of a CSingleAttribute
I think, Thomas, the logic is as follows, the CSingleAttribute can, as in the specs, have one or more then one children (CObjects).
Only one can be chosen, the others are alternatives.The CSingleAttribute can have existence 0..1 (OPTIONAL), 1..1 (REQUIRED) and 0..0 (NOTALLOWED).
The last one I don't understand, why having an attribute as it is defined to stay null.
this is used in ADL 1.5 templates to remove attributes not required in that particular data set (only if the RM permits it of course).
But besides that, suppose you have a CSingleAttribute with REQUIRED set with more CObjects as alternatives in it.
All occurrences for the CObjects need then to be set to 0..1, every other setting is erroneous.
Occurrences 0..0 is useless, why define a CObject if it may never occur.
Occurrences 1..1 is useless, why define alternative CObjects if the one chosen is defined.Maybe the occurrences of CObjects should not be looked at when child of a CSingleAttribute
occurrences can be 1..1 if it is the only possibility.
occurrences can be 0..1 on two alternatives, with an additional rule that says that either A or B must be there (thus satisfying the 1..1 in the attribute itself)
-----
It is that I am looking further in the world then existing archetypes.
We had the discussion about the tried enforcing top-down-structure of archetypes and the consequences of this policy a few weeks ago.
I'm not sure how this relates to the technical issue we are discussing here...?
I am also looking further than the existing Java-libraries, but that I will soon announce more about this.
I am not claiming that the current specification approach is perfect. But the experience I know about elsewhere leads me to think it is pretty workable; we don't seem to have any problems in most tools or libraries on this issue.
If there are aspects you are thinking about in some other kind of archetype, please share it, that would help.
thanks
- thomas
But besides that, suppose you have a CSingleAttribute with REQUIRED set with more CObjects as alternatives in it.
All occurrences for the CObjects need then to be set to 0..1, every other setting is erroneous.
Occurrences 0..0 is useless, why define a CObject if it may never occur.
Occurrences 1..1 is useless, why define alternative CObjects if the one chosen is defined.Maybe the occurrences of CObjects should not be looked at when child of a CSingleAttribute
occurrences can be 1..1 if it is the only possibility.
My statement was that it is useless, it can be possible but has no meaning. Skipping the alternatives is more clear.
And if there are no alternatives, setting the CSingleAttribute.existence to REQUIRED does the same.
occurrences can be 0..1 on two alternatives, with an additional rule that says that either A or B must be there (thus satisfying the 1..1 in the attribute itself)
That is the only meaningful occurrence possible in the CObject. So if there is only one meaningful, what is the point of making it configurable?
-----
It is that I am looking further in the world then existing archetypes.
We had the discussion about the tried enforcing top-down-structure of archetypes and the consequences of this policy a few weeks ago.I'm not sure how this relates to the technical issue we are discussing here...?
It is because you advised me to use the existing OpenEHR archetypes and Java-implementation. I indicated why I don't do that exclusively.
I am also looking further than the existing Java-libraries, but that I will soon announce more about this.
I am not claiming that the current specification approach is perfect. But the experience I know about elsewhere leads me to think it is pretty workable; we don't seem to have any problems in most tools or libraries on this issue.
If there are aspects you are thinking about in some other kind of archetype, please share it, that would help.
No it is not perfect, and yes it is workable. My suggestions were partly that I was not sure to understand the construct well, and partly to discuss improvements.
When I have other issues, I will gladly discuss them.
Bert
Bert,
one very useful thing you can do is to identify guidelines for use of the current specification. E.g. statements of the form
if existence is set on a single-valued attribute, and there is only one child object, no occurrences should be set, since they can always be inferred from the owning attribute's existence.
and so on. These kind of statements I can add to the ADL 1.5 spec (which we should treat as the usable spec these days).
thanks
- thomas
I think this is a good idea. I appreciate that you will take care for that Bert
Hi Bert
I have been a little irritating about this in the past. The single attribute could be determined by occurrences but I am not sure of the downstream implications at this stage.
My interest has been in existence as a constraint. Clearly everything is logically optional at any level if existence is to have any relevance. Existence as a constraint is therefore binary – something is mandatory or prohibited. I have proposed in XML that we have existence as a binary statement 0 or 1.
The expression of existence is clearly a tertiary state – optional as well as mandatory or prohibited – it is only as a constraint that it is binary.
Cheers, Sam
Hi Bert, it always helps me to make correspondences between the AOM and UML class models (they are basically the same thing).
If you look at this: http://www.openehr.org/wiki/download/attachments/196630/openehr_entry_uml.jpg?version=1&modificationDate=1193397393000
You’ll note the [0..1] and [1] on attributes, that’s the “existence”, and the “occurrence” is the cardinality on relationships (that’s for relationships that are no collections, i.e. single_attributes) (e.g. 0..1 in the ACTION.instruction_details relationship with INSTRUCTION_DETAILS).
Also, “CMultipleAttribute.cardinality” for collection attributes is the “cardinality” on UML relationships like “INSTRUCTION.activities” or “ENTRY.other_participations”.
Hope that helps.
