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 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 > > _______________________________________________ > 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
