# CR to adjust identifier types in Support IM **Category:** [Implementers (archive)](https://discourse.openehr.org/c/implementers-archive/158) **Created:** 2007-02-19 09:52 UTC **Views:** 23 **Replies:** 4 **URL:** https://discourse.openehr.org/t/cr-to-adjust-identifier-types-in-support-im/14623 --- ## Post #1 by @thomas.beale There was a request from some time ago from Heath Frankel that I now just dealing with, in the Identification package of the Support IM \- see http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/architecture/rm/support_im.pdf The request is to make OBJECT\_VERSION\_ID a subtype of HIER\_OBJECT\_ID\. The latter type is the general type for Ids based on a UID of some kind, possibly with an extension\. The former type is a specific type based on a UID, whose extension happens to be the version\_tree\_id \+ creating\_system\_id\. For some reason I did not think to make this a subtype of HIER\_OBJECT\_ID at the time of modelling\. One place where this would help is in LOCATABLE\.uid, currently of type HIER\_OBJECT\_ID\. A related CR is that the uid of top\-level objects in openEHR \(Composition, EHR\_access, EHR\_status, Folder, Party etc\) should carry the uid of their version, i\.e\. Version\.uid \(rm\.common\.change\_control\)\. The point of this is that if you receive say an XML of a Composition, the uid at the top will be the uid of the Version, i\.e\. an OBJECT\_VERSION\_ID, giving not only the Guid of the Version container \(common to all Compositions that are in a version set\), but also the version\_tree\_id \+ creating\_system\_id extension, telling us that it is version 4 created in Royal Leeds Infirmary for example\. I think that the change to make OBJECT\_VERSION\_ID a subtype of HIER\_OBJECT\_ID is sensible on general principle anyway \(it means that an OBJECT\_VERSION\_ID can be used wherever HIER\_OBJECT\_ID is specified\)\. I also think that specifying/recommending the uid at the top of an top\-level object to be its OBJECT\_VERSION\_ID is sensible, but we can treat this as a separate change \(probably just a recommendation at this stage\)\. Doing the subtype change means that the functions of each class behave sensibly, and is easy to do \(it is obvious what to do on inspection\)\. reactions? \- thomas beale --- ## Post #2 by @Andrew_Patterson > top\-level object to be its OBJECT\_VERSION\_ID is sensible, but we can > treat this as a separate change \(probably just a recommendation at this > stage\)\. Doing the subtype change means that the functions of each class > behave sensibly, and is easy to do \(it is obvious what to do on inspection\)\. > > reactions? no problems here \- I presume that 'extension' for a OBJECT\_VERSION\_ID returns creating\_system::version\_tree as a string, and 'has\_extension' is always true? Andrew --- ## Post #3 by @thomas.beale I have made a CR for this change: http://coruscant.chime.ucl.ac.uk:8200/openEHR_Collector/projects/specifications/CR/239 and actually carried out the change\. I have uploaded the Support IM \- see http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/architecture/rm/support_im.pdf Note that I have done this in a slightly different way to my previous email proposal\. I have also done the change to the Common IM \- LOCATABLE\.uid is now of type UID\_BASED\_ID\. The only thing I don't really like about the change is the new class name, but I could not think of anything better\. Any suggestions welcome\. There are also many other textual improvements in the Support document\. I would appreciate anyone who wants to give it a close read providing feedback\. thanks \- thomas Andrew Patterson wrote: --- ## Post #4 by @Heath_Frankel2 Tom, I don't understand why you can't just have OBJECT\_VERSION\_ID inherit from HIER\_OBJECT\_ID\. This goes for why GENERIC\_ID is required and not just make OBJECT\_ID concrete, but we have been there before\. Do you have a principle that concrete classes must only inherit abstract classes? This results in more classes in the model and you have problems with naming them\. Now GENERIC\_ID has a scheme attribute which is not used in the other siblings so that makes sense, but HIER\_OBJECT\_ID adds no features over the UID\_BASED\_ID except being concrete\. Heath --- ## Post #5 by @thomas.beale Heath Frankel wrote: > Tom, > I don't understand why you can't just have OBJECT\_VERSION\_ID inherit from > HIER\_OBJECT\_ID\. because in many places where HIER\_OBJECT\_ID is used in the model, OBJECT\_VERSION\_ID is not sensibly substitutable\. > This goes for why GENERIC\_ID is required and not just make > OBJECT\_ID concrete, but we have been there before\. it is to do with preventing inappropriate substitutability \- if we made OBJECT\_ID concrete and specified it in the model in various places, you could get archetype\_ids or whatever where they cannot make sense\. > Do you have a principle > that concrete classes must only inherit abstract classes? This results in > more classes in the model and you have problems with naming them\. Now > GENERIC\_ID has a scheme attribute which is not used in the other siblings so > that makes sense, but HIER\_OBJECT\_ID adds no features over the UID\_BASED\_ID > except being concrete\. >   that isn't a problem; it is a standard pattern to ensure the correct substitutability\.\.\.\. \- thomas --- **Canonical:** https://discourse.openehr.org/t/cr-to-adjust-identifier-types-in-support-im/14623 **Original content:** https://discourse.openehr.org/t/cr-to-adjust-identifier-types-in-support-im/14623