On 11/04/2016 11:07, Bjørn Næss wrote:
But if we want to avoid double results in querying, we need some sort of 
'is_derived' or 'is_copy' marker (and a link to original content) on the copy. 
At least that's where I got to the last time I thought about it.

Yes - I think we need some kind of marked. We have been thinking about adding 
this to the link. Some kind of "link to self". Then to avoid duplicates you 
MUST include that in every AQL. This is why we ended up with the proposal of a 
Composition category which solely of re-used (copies) data.

I'm not sure if this has the flexibility you (we) really want thought does it? 
It means that the entire Composition has to be treated as duplicate info to be 
excluded from query evaluation.

BNA: No you are right. It doesn't give the right level of flexibility when it 
comes to generating a Composition. So it is a trade off with the problem of 
duplicates when querying. We are working on a pattern for the user-inteface to 
cope with this problem. Because the end-user would like to "feel like" he is 
editing like before. But what is actually is doing is to create entries which 
will be referenced as copies.

And as you said : all the content of a given Composition MUST be treated like a 
copy. Only the metadata and mostly author and context.start_time should be new. 
This is not an ideal requirement/design - but the best of many worse choices so 
far....



The same pattern could be applied on several levels (ENTRY, CLUSTER). I.e. a 
Blood Pressure with an attribute 'is_copy' should by default be excluded from 
AQL queries.

Something like that?


Right. If we did it in the most general fashion possible, 
LOCATABLE<http://www.openehr.org/releases/RM/latest/docs/common/common.html#_archetyped_package>
 could have a Boolean flag 'is_copy'. But then you have a False Boolean on 99% 
of all data, which is not great data design. If we say that any copy has to 
have a LINK attached pointing to what it is a copy of, then your suggestion 
above is better (if I understand correctly) - put an 'is_copy' flag there. It 
could be argued that 'meaning' should encode whether something is a copy or 
not, but I think a separate flag would be better, and in any case 'meaning' 
might still carry different reasons for making copies.

BNA: Yes - I think we should maintain meaning to carry optional reason for 
making a copy. And then we need to have the specific flag to tell if it is a 
copy.

- thomas


Vennlig hilsen
Bjørn Næss
Produktansvarlig
DIPS ASA

Mobil +47 93 43 29 10<tel:+47%2093%2043%2029%2010>

Fra: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] På 
vegne av Thomas Beale
Sendt: mandag 11. april 2016 12.42
Til: openehr-technical@lists.openehr.org
Emne: Re: SV: Usage of Compositoin.Category

_______________________________________________
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Reply via email to