Archetyping links
Hmm, interesting idea. H -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Peter Gummer Sent: Wednesday, 10 June 2009 5:50 PM To: For openEHR technical discussions Subject: Re: Archetyping links Rong Chen wrote: I would say our use case for the link is also between compositions. For the reasons you mentioned, it would be nice to just use the archetypeId in the constraint for the value (URI) of the link. Then it starts to look like a mini query. It starts looking like a kind of slot too, but whereas a slot has aggregation semantics (i.e. the data in the slot is owned by the containing archetype), a link is just an association. So maybe links could use the same regular expression patterns that slots use. - Peter ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Archetyping links
yes, I meant properties of their targets as grounds for constraining them Grahame -Original Message- From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Heath Frankel Sent: Tuesday, June 23, 2009 10:00 AM To: 'For openEHR technical discussions' Subject: RE: Archetyping links Hi Grahame, No, I don't think, not directly anyway. The URIs are based on paths which obviously utilise the archetype and node IDs from Archetypes, but each implementation of a particular archetyped concept may be in a different location within a composition (i.e. a different template) so the path part of the URI will be different. In addition, URIs are for a particular instance, more like an Instance identifier than a concept code. Therefore, the only things that I think can be used to constrain a EHR URI is meta-data about the target (rm_type_name, archetyped parent archetype ID, archetype path) rather than the runtime URI of the target itself. Perhaps this is what you meant. Heath -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Grahame Grieve Sent: Wednesday, 3 June 2009 9:45 AM To: 'For openEHR technical discussions' Subject: RE: Archetyping links Hi Heath Doesn't this imply that a URI's are like codes that are references to some concept - that there's the same interest in controlling the concepts that they point to, and a similar delegation of control as with terminologies (as in, early vs late binding, implementation provision issues)? So that would suggest that the existing terminology stuff in archetypes and templates points towards a solution? Grahame -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Heath Frankel Sent: Wednesday, June 03, 2009 9:55 AM To: 'For openEHR technical discussions' Subject: RE: Archetyping links Hi Rong, Ocean certainly has runtime support for LINKs. The Ocean Archetype Editor used to (and perhaps it is still there) have an initial implementation of constraining LINKs but it became unclear if this was viable, useful or appropriate. We tend to now think it is a template constrain if anything. The common use cases we have used links is between compositions, whereas your example below tends to be a relative uri within the current compositions, which is quite legitimate but I want to ensure we consider the more general case. For absolute URIs, the URI pattern becomes difficult to determine because you have version specific URIs, relative version URIs (e.g. latest_trunk_version), and system specific URIs. In addition, your example assumes an exact understanding of the composition structure in which the target is located, i.e. that the diagnosis exists within some section. This is most likely not know at the time of creating the archetype with the LINK and likely to be variable. Wildcards and RegEx patterns can make this possible but start to get very complicated. It is for these reasons that it became unclear how we can constrain the target URI in an archetype. I have considered some extensions to AQL to be able to query compositions that contain LINKs to specific object types. I would need to review these thoughts but from memory it was along the lines of the following. ... CONTAINS LINK CONTAINS EVALUATION e[openEHR-EHR-EVALUATION.diagnosis.v1] ... WHERE e/... The point here (and it may not be clear from my attempt to relate it to AQL) is that there may need to be some indirect constraint required for LINKs, i.e. something that does not physically exist in the current instance such as a constraint on the target URI, but something that makes a assertion about the real target of the URI. I don't think there is an easy answer to these questions and only implementation and ongoing discussion is likely toi find viable solutions. Heath -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr- technical- bounces at openehr.org] On Behalf Of Rong Chen Sent: Tuesday, 2 June 2009 7:04 PM To: For openEHR technical discussions Subject: Re: Archetyping links Just want to be more specific about the questions (Daniel and I are working together on this issue), I created the ADL following the example from Daniel's post. ELEMENT[at0002.1] matches { -- Diagnosis value matches { DV_CODED_TEXT matches { defining_code matches {[ac0.1] } } links matches { LINK[at0003.1] matches { -- complication of target matches { DV_EHR_URI matches { Value matches {/content/items[openEHR-EHR-EVALUATION.diagnosis.v1]/} } } } } The ADL is created manually, so it might not have
Archetyping links
Rong Chen wrote: I would say our use case for the link is also between compositions. For the reasons you mentioned, it would be nice to just use the archetypeId in the constraint for the value (URI) of the link. Then it starts to look like a mini query. It starts looking like a kind of slot too, but whereas a slot has aggregation semantics (i.e. the data in the slot is owned by the containing archetype), a link is just an association. So maybe links could use the same regular expression patterns that slots use. - Peter
Archetyping links
Yes, indeed! It's a choice between composition versus association. Cheers, Rong 2009/6/10 Peter Gummer peter.gummer at oceaninformatics.com: Rong Chen wrote: I would say our use case for the link is also between compositions. For the reasons you mentioned, it would be nice to just use the archetypeId in the constraint for the value (URI) of the link. Then it starts to look like a mini query. It starts looking like a kind of slot too, but whereas a slot has aggregation semantics (i.e. the data in the slot is owned by the containing archetype), a link is just an association. So maybe links could use the same regular expression patterns that slots use. - Peter ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Archetyping links
Hi Rong, Ocean certainly has runtime support for LINKs. The Ocean Archetype Editor used to (and perhaps it is still there) have an initial implementation of constraining LINKs but it became unclear if this was viable, useful or appropriate. We tend to now think it is a template constrain if anything. The common use cases we have used links is between compositions, whereas your example below tends to be a relative uri within the current compositions, which is quite legitimate but I want to ensure we consider the more general case. For absolute URIs, the URI pattern becomes difficult to determine because you have version specific URIs, relative version URIs (e.g. latest_trunk_version), and system specific URIs. In addition, your example assumes an exact understanding of the composition structure in which the target is located, i.e. that the diagnosis exists within some section. This is most likely not know at the time of creating the archetype with the LINK and likely to be variable. Wildcards and RegEx patterns can make this possible but start to get very complicated. It is for these reasons that it became unclear how we can constrain the target URI in an archetype. I have considered some extensions to AQL to be able to query compositions that contain LINKs to specific object types. I would need to review these thoughts but from memory it was along the lines of the following. ... CONTAINS LINK CONTAINS EVALUATION e[openEHR-EHR-EVALUATION.diagnosis.v1] ... WHERE e/... The point here (and it may not be clear from my attempt to relate it to AQL) is that there may need to be some indirect constraint required for LINKs, i.e. something that does not physically exist in the current instance such as a constraint on the target URI, but something that makes a assertion about the real target of the URI. I don't think there is an easy answer to these questions and only implementation and ongoing discussion is likely toi find viable solutions. Heath -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Rong Chen Sent: Tuesday, 2 June 2009 7:04 PM To: For openEHR technical discussions Subject: Re: Archetyping links Just want to be more specific about the questions (Daniel and I are working together on this issue), I created the ADL following the example from Daniel's post. ELEMENT[at0002.1] matches { -- Diagnosis value matches { DV_CODED_TEXT matches { defining_code matches {[ac0.1] } } links matches { LINK[at0003.1] matches { -- complication of target matches { DV_EHR_URI matches { Value matches {/content/items[openEHR-EHR-EVALUATION.diagnosis.v1]/} } } } } The ADL is created manually, so it might not have the correct syntax. But you probably get the idea anyway. The general question is if LINK is intended to be a runtime facilitator or something that could be used in design time (archetyping) as well? Secondly, what's the status of tooling support, both in authoring environment (archetype editors) and runtime systems (querying for instance)? Any feedback will be appreciated! Cheers, Rong 2009/6/1 Daniel Karlsson daniel.karlsson at imt.liu.se: Dear Everyone, what are the possibilites of constraining the LINK.target attribute (DV_EHR_UIR datatype) in an archetype? This was possible in earlier versions of the Ocean Archetype Editor (although its use never was clear to me). Let's say that I want to constrain a link from an archetype to only allow linkage to instances conforming a specific set of archetypes (e.g. allowing linkage only to Diagnosis-archetype instances for links with complication of meaning.) Is it allowed to use a regexp constraint on the DV_EHR_URI and include the archetype id? Is it guaranteed that the archetype id can be used in the path as in 11.2.3 in Architecture overview in run-time systems? Regards, Daniel ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Archetyping links
Hi Heath Doesn't this imply that a URI's are like codes that are references to some concept - that there's the same interest in controlling the concepts that they point to, and a similar delegation of control as with terminologies (as in, early vs late binding, implementation provision issues)? So that would suggest that the existing terminology stuff in archetypes and templates points towards a solution? Grahame -Original Message- From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Heath Frankel Sent: Wednesday, June 03, 2009 9:55 AM To: 'For openEHR technical discussions' Subject: RE: Archetyping links Hi Rong, Ocean certainly has runtime support for LINKs. The Ocean Archetype Editor used to (and perhaps it is still there) have an initial implementation of constraining LINKs but it became unclear if this was viable, useful or appropriate. We tend to now think it is a template constrain if anything. The common use cases we have used links is between compositions, whereas your example below tends to be a relative uri within the current compositions, which is quite legitimate but I want to ensure we consider the more general case. For absolute URIs, the URI pattern becomes difficult to determine because you have version specific URIs, relative version URIs (e.g. latest_trunk_version), and system specific URIs. In addition, your example assumes an exact understanding of the composition structure in which the target is located, i.e. that the diagnosis exists within some section. This is most likely not know at the time of creating the archetype with the LINK and likely to be variable. Wildcards and RegEx patterns can make this possible but start to get very complicated. It is for these reasons that it became unclear how we can constrain the target URI in an archetype. I have considered some extensions to AQL to be able to query compositions that contain LINKs to specific object types. I would need to review these thoughts but from memory it was along the lines of the following. ... CONTAINS LINK CONTAINS EVALUATION e[openEHR-EHR-EVALUATION.diagnosis.v1] ... WHERE e/... The point here (and it may not be clear from my attempt to relate it to AQL) is that there may need to be some indirect constraint required for LINKs, i.e. something that does not physically exist in the current instance such as a constraint on the target URI, but something that makes a assertion about the real target of the URI. I don't think there is an easy answer to these questions and only implementation and ongoing discussion is likely toi find viable solutions. Heath -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Rong Chen Sent: Tuesday, 2 June 2009 7:04 PM To: For openEHR technical discussions Subject: Re: Archetyping links Just want to be more specific about the questions (Daniel and I are working together on this issue), I created the ADL following the example from Daniel's post. ELEMENT[at0002.1] matches { -- Diagnosis value matches { DV_CODED_TEXT matches { defining_code matches {[ac0.1] } } links matches { LINK[at0003.1] matches { -- complication of target matches { DV_EHR_URI matches { Value matches {/content/items[openEHR-EHR-EVALUATION.diagnosis.v1]/} } } } } The ADL is created manually, so it might not have the correct syntax. But you probably get the idea anyway. The general question is if LINK is intended to be a runtime facilitator or something that could be used in design time (archetyping) as well? Secondly, what's the status of tooling support, both in authoring environment (archetype editors) and runtime systems (querying for instance)? Any feedback will be appreciated! Cheers, Rong 2009/6/1 Daniel Karlsson daniel.karlsson at imt.liu.se: Dear Everyone, what are the possibilites of constraining the LINK.target attribute (DV_EHR_UIR datatype) in an archetype? This was possible in earlier versions of the Ocean Archetype Editor (although its use never was clear to me). Let's say that I want to constrain a link from an archetype to only allow linkage to instances conforming a specific set of archetypes (e.g. allowing linkage only to Diagnosis-archetype instances for links with complication of meaning.) Is it allowed to use a regexp constraint on the DV_EHR_URI and include the archetype id? Is it guaranteed that the archetype id can be used in the path as in 11.2.3 in Architecture overview in run-time systems? Regards, Daniel ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Archetyping links
Dear Everyone, what are the possibilites of constraining the LINK.target attribute (DV_EHR_UIR datatype) in an archetype? This was possible in earlier versions of the Ocean Archetype Editor (although its use never was clear to me). Let's say that I want to constrain a link from an archetype to only allow linkage to instances conforming a specific set of archetypes (e.g. allowing linkage only to Diagnosis-archetype instances for links with complication of meaning.) Is it allowed to use a regexp constraint on the DV_EHR_URI and include the archetype id? Is it guaranteed that the archetype id can be used in the path as in 11.2.3 in Architecture overview in run-time systems? Regards, Daniel
Archetyping links++
Sorry, forgot the final question: Is this (see preceding email) implemented in openEHR-based systems? Regards again, Daniel -- Daniel Karlsson, PhD. Department of Biomedical Engineering/Medical informatics Link?pings universitet SE-58185 Link?ping Sweden Tel. 013-227573, Mobil: 070-8350109, Skype: imt_danka