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


Reply via email to