Hi Erik, I am still catching up from some time-off, interesting discussion seem to happen while I am away...
I will start with my comments at the start and likely to respond to later responses. Heath > Some of the interesting bits I've picked up so far from discussions: > - Maybe it would be a good idea to make LINK inherit from LOCATABLE > and thus become archetypable in itself [HKF: ] LINK does not need to be LOCATABLE to be archetyped unless you are talking about LINK being the archetype root. I don't see why we need to do this, a LINK only make sense to me within the context of its parent. If there truly is a need for LINK to be an archetype root then perhaps the ARCHETYPED association should be moved to PATHABLE. > - Tooling support for using LINK in archetypes is currently poor or non > existent [HKF: ] This is partly my fault, Sam started supporting LINK in the openEHR Archetype Editor but I could not see how the constraints being specified could be usable at the archetype level, so we stopped its development until we had better understanding of the requirements. > - There is very little (if any) reported usage experience of LINK in > openEHR [HKF: ] True, although this is changing, we are using it in a significant development exactly in the way that Rong talks about his response, to relate content within the same thread of care, in particular an indication of proposed care and the plan of actions for that proposal. We are implementing these in the application without archetyping them because we still think this is not something that can be archetyped and we are learning how they can be used at the template level (as indicated by Rong). > - I believe the NHS has somewhat explored LINK usage in LRA using ISO > 13606 > - If archetyping LINKS, then it would in _some_ cases be desirable to > be able restrict the type of the "target", especially defining what > archetypes the target objects must adhere to (similar to the archetype > slot mechanism). [HKF: ] Absolutely, this is was evident to me when I asked Sam to stop his support for LINKs using RegEx on the target uri. It needs to be some sort of AQL or A-Path expression. Tom's target type is somewhere towards it but as indicated elsewhere we need to constrain it further to an archetype ID or even an archetype path, but definitely not a data path/uri. > Please fill in with nore details and thoughts. > > Implementers, would it have a big impact on your implementations if > LINK was made LOCATABLE? (Let's say in v 1.0.3) [HKF: ] I am against this proposal. I originally thought this was necessary for PARTICIPATION to allow it to be archetyped, but now I don't. I realised that for an item to have a node_id in the archetype, it doesn't need to have a node_id attribute in the class. As long as the constraints on the class attributes in the archetype are distinct for each class constraint (when you have multiple LINK constraints, the meaning/type/target_* combinations are disjoint), then we have enough information to match a data instance at runtime. The node_id in the archetype is only necessary to allow further constraints to be applied on the node in specialised archetypes/templates. The need to populate a name on each LINK would be quite painful and redundant as it is now for every other LOCATABLE. Although the existing Type attribute could be made a function taking the value of Name as is done in the Demographic RM. If this is necessary so that we can create a LINK archetype then I suggest moving the association to the ARCHETYPED class to the PATHABLE class, this would be a non-breaking change. > I wonder, is it currently safe to archetype the DV_EHR_URI used in the > "target" attribute of LINK just using a string matching pattern or do > we need additional mechanisms? The URI value represents an identifier > of some node inside a versioned object, do string patterns matching > DV_EHR_URI values cover for all kinds of target range restrictions > we'd likely want to express if archetyping LINKs? [HKF: ] As I indicated, I don't believe this is useful and why we stopped development of LINK in the archetype editor. > Maybe they actually do work using wildcards in the right places? [HKF: ] Yes, I guess if you ignored all the first part of the URI and just provide the data path part, then it may be possible. But as I indicated above, I think it needs to be more of an archetype path than a data path. I realise difference is semantic but relevant in this case. I think A-Path or AQL (or ADL rules) would be a better representation than a URI. I know Sam was of the opinion early that URIs could be used for queries, and this support by the RESTful service community, this is probably the origins of his intent to use a URI constrain for LINK target. I just don't see URIs supporting more complicated query requirements, hence AQL (and I am also a fan of A-Path) > How tricky will it be to > implement that constraint checking at runtime data creation? [HKF: ] Anything is possible if the constraint is easily mapped into some kind of query, but like everything with integrity checking, there will be a significant performance overhead.
