# AOM: how do you differentiate between sibling C_OBJECT if both are ARCHETYPE_ROOT and have the same archetype_id? **Category:** [ADL](https://discourse.openehr.org/c/adl/40) **Created:** 2022-09-25 04:20 UTC **Views:** 805 **Replies:** 36 **URL:** https://discourse.openehr.org/t/aom-how-do-you-differentiate-between-sibling-c-object-if-both-are-archetype-root-and-have-the-same-archetype-id/3013 --- ## Post #1 by @pablo I'm working with some complex OPTs, verifying data validation rules. From the OPT I'm generating a COMPOSITION instance and then validating the COMPOSITION against the OPT. This OPT has several SECTION in COMPOSITION.content and have the same archetype openEHR-EHR-SECTION.adhoc.v1, but each SECTION has it's own items, some have OBSERVATIONS, other ACTIONS, etc. When I have a SECTION instance from the COMPOSITION object, need to get the defining C_OBJECT from the OPT, then finding by archetype_id doesn't work because the COMPOSITION.content has many alternatives with the same archetype id in the OPT, and the archetype_node_id is always the archetype_id because are all ARCHETYPE_ROOTs. So I'm wondering how other implementations deal with this case? Is there any other attribute that you use to find the correct C_OBJECT to validate a certain RM object? As a workaround I used the C_OBJECT text from the term definitions to match the LOCATABLE.name.value, this works in TOM 1.4 since the OPT can only have one translation, so the COMPOSITION language should be the same as the OPT language. But in AOM 2 I think one OPT allows multiple languages so this workaround doesn't work there. Attached is the "problematic" OPT, just in case anyone want's to check it. [aboriginal_and_torres_strait_islander_health_check_master.opt|attachment](upload://4sl8ybBLZLppAjC9HzZOnGj1vMz.opt) (2.7 MB) --- ## Post #2 by @pablo @thomas.beale @sebastian.iancu @Seref @ian.mcnicoll @yampeku :pray: --- ## Post #3 by @yampeku the answer would be by its uid, but I'm pretty sure there is no extended support for that. I've seen queries by the name too, which is wrong in so many different ways --- ## Post #4 by @pablo Ha, never thought of that, but non-root objects don't have UID, I mean the compo might have an UID, but then the SECTIONs in COMPOSITION.content won't. With the current model I don't think it's possible, maybe I'm wrong. I think this would require some template-level ID, so each node in the template has it's own unique ID independently from the archetype ID or node ID, since for sibling nodes that are ARCHETYPE_ROOTs the path would also be the same, so the path can't be used as an ID for a unique C_OBJECT. Then in the RM instance that ID would be used as a mandatory field, so it doesn't depend on implementation decisions (current LOCATABLE.uid is optional). --- ## Post #5 by @yampeku Buy uid is in locatable, should be available in every archetype class --- ## Post #6 by @pablo Yes but that doesn't solve then issue: having an RM instance and for it's nodes get the corresponding C_OBJECT from the template. The uid is optional for all locatable, but if you set it for all nodes in the RM instance, you can't still get the C_OBJECT. A unique identifier of C_OBJECTs inside the OPT is needed, then that value should be on each node of the RM instance. The case I described is an OPT like this: - COMPOSITION (openEHR-EHR-COMPOSITION.generic.v1) -- SECTION (openEHR-EHR-SECTION.generic.v1) --- content A -- SECTION (openEHR-EHR-SECTION.generic.v1) --- content B Both sections are siblings, both are ARCHETYPE_ROOT, in archetype_node_id in the COMPOSITION instance both SECTIONs have the SAME archetype_id, but in the instance, the SECTION items are different. Then from the first SECTION in the instance I need the correct C_OBJECT, the one that defines content A, but there is no identifier that allows to differentiate between those SECTIONs C_OBJECTs in the OPT. Also note since both SECTIONs are defined in COMPOSITION.content, inside a C_MULTIPLE_ATTTIBUTE, and have the SAME archetype I'd, both will have the same path, so the path is neither an ID of the C_OBJECT here. That is the issue and it happens in the OPT attached on my first message. --- ## Post #7 by @damoca [quote="pablo, post:6, topic:3013"] Both sections are siblings, both are ARCHETYPE_ROOT, in archetype_node_id in the COMPOSITION instance both SECTIONs have the SAME archetype_id, but in the instance, the SECTION items are different. Then from the first SECTION in the instance I need the correct C_OBJECT, the one that defines content A, but there is no identifier that allows to differentiate between those SECTIONs C_OBJECTs in the OPT. [/quote] I do not know about the internal structure of OPT, but if there is no other identifier to differentiate sibling nodes of the same archetype, the only way to differentiate them would using their name (the name you give to those nodes in the Archetype Designer). Fortunately, the AD does not allow that two sibling nodes have the same name, so from the editing point of view is a safe approach. ![image|374x226](upload://pKl3TsLodHJqT5xS3Z9mCRrrhtd.png) Now, the second part of the problem is where to put that name in the data instances to validate them. The only place i can think of is the name attribute, since theoretically it should take the same name as the one in the template. The problem will be if there are multiple languages, there could be a mismatch and then you will be forced to lookup for a match among those languages. ![image|635x322](upload://qoYnmUax58HHaN09wxd5HR98t0H.png) A more formal place for this information would be in archetype_details.template_id, but in that case, we would still need to have an identifier in the OPT to differentiate the sibling nodes. --- ## Post #8 by @thomas.beale [quote="pablo, post:1, topic:3013"] This OPT has several SECTION in COMPOSITION.content and have the same archetype openEHR-EHR-SECTION.adhoc.v1 [/quote] This is essentially an archetype that does almost no constraining on the RM - so it's like raw RM structures. I would have expected that specialised archetyes would be used for each distinct Section structure - that's what you would do in ADL2 - either specialised archetypes (re-usable) or template level overlays (which still have distinct archetype ids). See [here in ADL2 spec](https://specifications.openehr.org/releases/AM/latest/ADL2.html#_example) and scroll down a bit. This us another one of those ADL 1.4 problems that ADL2 solves... --- ## Post #9 by @pablo Yes, that is what I used, but feels unreliable. In ADL2, since templates could have many languages, it requires a lookup for the translation based on the language on the RM instance (i.e. COMPOSITION), but FOLDER, EHR_STATUS or PARTY don't have a language attribute, only the COMPOSITION has one, and this issue could happen on those types too. In OPT 1.4 it works since the OPT supports only one language so no lookup is needed. --- ## Post #10 by @damoca I thought on a patch solution. Given that OPT is an XML, and XML is ordered, and "IF" OPT regeneration respects that order, you could use the complete XPath, including the position, to each subsection as an Id. Of course this won't work if the template is modified by adding or removing other sibling nodes, but in that case probably we should be also considering that you are creating new versions of the template. ![image|561x130](upload://nBhVaqi72eWeGv0LnIsA9vKUuWT.png) --- ## Post #11 by @ian.mcnicoll Controversy alert!! This is really not such an issue in practice. We can put uids on any LOCATABLE but would virtually never do so, other than on ENTRYs. I would advocate putting uids at Entry level and e,g. event of activity level, to resolve this problem of distinguishing sibllings but in most cases it is not really that important (export to FHIR being an exception). Using name is ugly, I agree but is where we are until we can use template-level internal codes to safely distinguish them - but that is generally at ELEMENT or CLUSTER level @Thomas - I can clearly state that we virtually 'never' use SECTION archetypes other then 'Ad-hoc' and rename them for the local usage. And I don't think I have ever specialised a SECTION. The use of headings is completely idiosyncratic and ultimately these should not carry any semantics. I can't think of any queries in systems I have built that would require me to query on a SECTION. --- ## Post #12 by @pablo @thomas.beale we can't rely on how a modeler will create models, the key point is that the specs allow this case, even if it's not common, it's possible. I don't know how ADL2 per se solve this problem, since it's related to how the modeler will create the archetypes and template, there are no constraints AFAIK that prevent a modeler to use these generic archetypes. --- ## Post #13 by @thomas.beale [quote="ian.mcnicoll, post:11, topic:3013"] And I don’t think I have ever specialised a SECTION [/quote] Fair enough - in that case, what you want to do logically is overlay. In ADL2, this creates distinct archetype ids for the overlays. The closest way to simulate that in ADL 1.4 is with specialised archetypes - which could be enabled by the tools. [quote="ian.mcnicoll, post:11, topic:3013"] I can’t think of any queries in systems I have built that would require me to query on a SECTION [/quote] Well we designed openEHR such that the semantics of Entries is never changed by what Sections they come under, and I believe that still holds (it should). There could still be querying for sections anyway (I am thinking more 'standardised' heading structures I see in US EMR data these days). I don't think the fact of querying being unlikely removes the technical need to be able to distinguish these sibling structures, or simulate overlays as per above. --- ## Post #14 by @thomas.beale [quote="pablo, post:12, topic:3013"] there are no constraints AFAIK that prevent a modeler to use these generic archetypes [/quote] If the modeller wants to distinguish sibling heading structures at the template, they are creating overlays (in ADL2-speak). That creates distinct archetype ids. ``` content ∈ { use_archetype SECTION[id0.1, openEHR-EHR-SECTION.t_patient_event_info_ds_sf.v1] occurrences ∈ {1} use_archetype EVALUATION[id0.2, openEHR-EHR-EVALUATION.t_clinical_info_ds_sf-1.v1] occurrences ∈ {0..1} use_archetype EVALUATION[id0.3, openEHR-EHR-EVALUATION.t_clinical_info_ds_sf-2.v1] use_archetype EVALUATION[id0.5, openEHR-EHR-EVALUATION.t_clinical_info_ds_sf-4.v1] occurrences ∈ {1..*} use_archetype EVALUATION[id0.6, openEHR-EHR-EVALUATION.t_clinical_info_ds_sf-5.v1] occurrences ∈ {0..1} use_archetype EVALUATION[id0.8, openEHR-EHR-EVALUATION.t_clinical_info_ds_sf-7.v1] occurrences ∈ {0..*} use_archetype EVALUATION[id0.9, openEHR-EHR-EVALUATION.t_clinical_info_ds_sf-8.v1] } ``` --- ## Post #15 by @pablo [quote="thomas.beale, post:14, topic:3013"] If the modeller wants to distinguish... [/quote] is that mandatory by the specs or left to the modeler's criteria? --- ## Post #16 by @ian.mcnicoll AD and TD enforce this at template-level by forcing a difference in name/value. Of course, that does not help where another item is created at run-time. THat's where if unique identification is important I'd enforce recording ENTRY.uid. --- ## Post #17 by @thomas.beale [quote="pablo, post:15, topic:3013"] is that mandatory by the specs or left to the modeler’s criteria? [/quote] In ADL2 it is automatic: you create any sort of further constraints on an included archetype, you get an overlay, and you get a new archetype id. It can't be avoided. That's why I say that specialising archetypes is the closest approximation possible in ADL1.4. Or better, just move to ADL2 ;) --- ## Post #18 by @pablo The issue is the UID in the RM instance doesn't help to match/find them corresponding C_OBJECT from the template (think of data validation). --- ## Post #19 by @pablo Thanks @thomas.beale though moving to ADL2 would take a major refactoring on most 1.4 compatible apps, that is why I also try to discuss solutions for 1.4. --- ## Post #20 by @pablo [quote="thomas.beale, post:14, topic:3013"] If the modeller wants to distinguish sibling heading structures at the template, they are creating overlays (in ADL2-speak). That creates distinct archetype ids. ``` content ∈ { use_archetype SECTION[id0.1, openEHR-EHR-SECTION.t_patient_event_info_ds_sf.v1] occurrences ∈ {1} use_archetype EVALUATION[id0.2, openEHR-EHR-EVALUATION.t_clinical_info_ds_sf-1.v1] occurrences ∈ {0..1} use_archetype EVALUATION[id0.3, openEHR-EHR-EVALUATION.t_clinical_info_ds_sf-2.v1] use_archetype EVALUATION[id0.5, openEHR-EHR-EVALUATION.t_clinical_info_ds_sf-4.v1] occurrences ∈ {1..*} use_archetype EVALUATION[id0.6, openEHR-EHR-EVALUATION.t_clinical_info_ds_sf-5.v1] occurrences ∈ {0..1} use_archetype EVALUATION[id0.8, openEHR-EHR-EVALUATION.t_clinical_info_ds_sf-7.v1] occurrences ∈ {0..*} use_archetype EVALUATION[id0.9, openEHR-EHR-EVALUATION.t_clinical_info_ds_sf-8.v1] } ``` [/quote] @thomas.beale rechecking your message, I understood the AOM2/ADL2 specs **require** that the archetype ID is modified when there are indistinguishable siblings in the archetype/template (e.g. two archetype slots to the same archetype ID). So I suppose in a LOCATABLE instance that complies with that archetype/template will have the archetype_node_ids set to the modified archetype IDs, is that correct? If so, that also implies in AQL we should use the modified archetype IDs not the original ones. So any tool that allows to edit queries should be aware of the modified archetype IDs. Doesn't that generate issues for querying when you want/need to query by the original archetype ID? Another design detail is that the modification on archetype IDs seems to be an actual codification of an extra field that contains some kind of numeric index, wouldn't be clearer to have such field separated from the archetype IDs in the AOM and the RM? That is also a solution I mentioned above for AOM/ADL 1.4: [quote="pablo, post:4, topic:3013"] I think this would require some template-level ID, so each node in the template has it’s own unique ID independently from the archetype ID or node ID, since for sibling nodes that are ARCHETYPE_ROOTs the path would also be the same, so the path can’t be used as an ID for a unique C_OBJECT. Then in the RM instance that ID would be used as a mandatory field, so it doesn’t depend on implementation decisions (current LOCATABLE.uid is optional). [/quote] In summary, for v1.4 the **only** solution to this problem is using the name to distinguish C_OBJECTs (as @damoca described on his sept 30 message), which relies on the modeler(s) to do that correctly, since no modeling tools check that, and that could generate bugs in systems that rely on this pattern without checking it, which IMO is dangerous design if not amended on v1.4. I will actually create a validation rule on all my systems just to check this: if there are two sibling nodes in a template that have the same archetype ID and the same name (or unconstrained), then the template will not be accepted by the system. That is the only way I can provide a reliable product to my users. --- ## Post #21 by @thomas.beale [quote="pablo, post:20, topic:3013"] So I suppose in a LOCATABLE instance that complies with that archetype/template will have the archetype_node_ids set to the modified archetype IDs, is that correct? [/quote] Yes, that's it. [quote="pablo, post:20, topic:3013"] If so, that also implies in AQL we should use the modified archetype IDs not the original ones. So any tool that allows to edit queries should be aware of the modified archetype IDs. Doesn’t that generate issues for querying when you want/need to query by the original archetype ID? [/quote] Well it could in the same way that querying for any specialised id isn't the same as querying for the parent. The querying engine always has to have access to the lineage, i.e. the inheritance structure. That's why this is discussed in the Archetype Identification specification. An overlay is just a little archetype, just inside the template rather than outside - you'll see it has a specialise section just like any other specialised archetype. Again - ADL2 converts the whole functionality of templates to just 'more of the same'. This is why I was suggesting that the best workaround is to use specialised archetypes to get different ids - this mimics what ADL2 does. --- ## Post #22 by @ian.mcnicoll [quote="pablo, post:20, topic:3013"] I understood the AOM2/ADL2 specs **require** that the archetype ID is modified when there are indistinguishable siblings in the archetype/template [/quote] I'm quite uneasy about that requirement if it applies in the data instance, as well as the template. In the vast majority of cases, sibling objects will be created at run-time e.g multiple allergies. In other cases where we 'clone' e.g an ENTRY object, the real semantic variance is likely to be carried further down in the ENTRY e.g a Risk Identified archetype where the name of the risk is carried as a mandatory element, normally coded. If we have a number of risks e.g . Housebound", "Unable to recognise safety risks", we will often clone the archetype and fix the risk name for each cloned instance. THe template tools do force us (name/value) to distinguish each archetype root but that is often helpful for developers in understanding the correct paths to follow. Obviously it is better if name/value override is coded (for translations) but overriding the root archetypeID in the template feels pretty heavy-duty! Maybe ok if this exists in the tooling space but also in instance data? --- ## Post #23 by @thomas.beale [quote="ian.mcnicoll, post:22, topic:3013"] Obviously it is better if name/value override is coded (for translations) but overriding the root archetypeID in the template feels pretty heavy-duty! Maybe ok if this exists in the tooling space but also in instance data? [/quote] It should be supported in the tools in a nice way to be usable, that's for sure. But it's not really 'heavy' - different archetype or overlay ids (= archetype id) just distinguish different modelling semantics for the relevant sibling nodes. If all this were done invisibly in tools, no-one would even think about it. --- ## Post #24 by @pablo [quote="thomas.beale, post:21, topic:3013"] The querying engine always has to have access to the lineage, i.e. the inheritance structure. [/quote] Are you referring to the **archetype** inheritance structure? But the modification of the archetype ID is not really a specialization, because is the same archetype without any internal modification, just the archetype ID. Kind of an `aliasing` feature more than `specialization` isn't it? --- ## Post #25 by @pablo [quote="ian.mcnicoll, post:22, topic:3013"] In the vast majority of cases, sibling objects will be created at run-time e.g multiple allergies. [/quote] The issue here is different, the problem is: "given a RM object instance, how to get the corresponding C_OBJECT from the AOM for each node, if C_OBJECT siblings are indistinguishable". So you can have as many RM objects as you want added at runtime, if those sibling objects in the RM instance are constrained by a distinguishable C_OBJECT in the corresponding AOM (e.g. can be found by archetype ID + path), then there is no issue. The problem is having siblings in AOM (not in RM) that for the same archetype ID and path can match more than one C_OBJECT. So in the case of the OPT I shared, there are sibling SECTIONs declared in the AOM which have the same archetype ID and path, and the only way of distinguish between those two is by the constraint added to the name, which should be present in any RM object that complies with the OPT. But, you could have (maybe not in the OPT I shared but in general) indeed many instances of SECTION added at runtime, for the same archetype ID + path + name. What Thomas said, and I'm still processing since I work only with AOM/ADL/TOM 1.4 is in AOM/ADL 2 there is no need of the name constraint since if there are two sibling C_OBJECTs (AOM) with the same archetype ID + path, then one will be transformed to archetype ID-1 + path and the other one will be transformed to archetype ID-2 + path, so there is no collision. Still, your use case of adding multiple nodes in a RM object complying with archetype ID-1 and archetype ID-2 is supported without any issues. The use case for the original issue is receiving a RM object e.g. via the REST API, like a COMPOSITION, FOLDER, PARTY or EHR_STATUS, and trying to validate that object against the corresponding OPT, so for each node in the RM object, the corresponding C_OBJECT from the template should be found in an unambiguous way, and with archetype ID + path (taken form the RM object's nodes) alone is not possible, so the name should come into play as a workaround. As said above, a simple solution would be to have a unique ID for each C_OBJECT in the AOM, and reference that ID from the RM objects, but that is not possible right now, in 1.4 and in AOM2, as Thomas mentioned, that is kind of encoded in the modified archetype ID, which doesn't seem a very clean solution IMHO, I would opt for having a dedicated field for that instead of coding it inside the arch ID. As a consequence of requiring the name to distinguish between C_OBJECT nodes in the AOM 1.4 structure is that when uploading an OPT to a system it SHOULD check sibling objects are distinguishable by using the name, since that pattern is not enforced by modeling tools so we can end up with an OPT with indistinguishable nodes if the modeler didn't constraint the name on those C_OBJECTs that have the same archetype ID and path. And engineers shouldn't trust modelers :) --- ## Post #26 by @yampeku By the way, there is currently a bug in the Archetype Designer that removes the specialization id from these sibling nodes in the OPT export and thus prevents their use as node discriminators --- ## Post #27 by @thomas.beale [quote="pablo, post:24, topic:3013"] But the modification of the archetype ID is not really a specialization, because is the same archetype without any internal modification, just the archetype ID. Kind of an `aliasing` feature more than `specialization` isn’t it? [/quote] An overlay is technically a specialisation - it has changes in the constraints, otherwise there is no overlay. [quote="yampeku, post:26, topic:3013, full:true"] By the way, there is currently a bug in the Archetype Designer that removes the specialization id from these sibling nodes in the OPT export and thus prevents their use as node discriminators [/quote] Please [report that](https://discourse.openehr.org/c/tool-support/archetype-designer/30)! --- ## Post #28 by @yampeku will do ASAP :) --- ## Post #29 by @pablo [quote="thomas.beale, post:27, topic:3013"] An overlay is technically a specialisation - it has changes in the constraints, otherwise there is no overlay. [/quote] I'm not sure what an `overlay` is in this context. Though I can think of a test case that doesn't have any changes to the constraints and still have the issue that I mentioned on my first message: can't match one single C_OBJECT by archeype ID + path. > COMPOSITION > - SECTION (SECTION.ad-hoc) > -- name = "X" > - SECTION (SECTION.ad-hoc) > -- name = "Y" For both sections, the items are not constrained, just the names, then there is a need of identifying each individually. So in ADL2, if I understood correctly, the editor tool should mark the first one as SECTION.ad-hoc-1 and the second as SECTION.ad-hoc-2. That is the border case for a whole family of test cases that show the issue at hand, and there is clearly no extra set of constraints added to neither occurrences of SECTION.ad-hoc. --- ## Post #30 by @sebastian.garde Just wanted to point you to the following Jira issue which describes a similar issue and has already created some discussion as well: https://openehr.atlassian.net/browse/SPECPR-279 --- ## Post #31 by @thomas.beale [quote="pablo, post:29, topic:3013"] For both sections, the items are not constrained, just the names, then there is a need of identifying each individually [/quote] But name is constrained (at least that's what I assume you meant with that short-hand!). ADL doesn't differentiate between different attributes being constrained. Any constraint is a constraint. [quote="pablo, post:29, topic:3013"] So in ADL2, if I understood correctly, the editor tool should mark the first one as SECTION.ad-hoc-1 and the second as SECTION.ad-hoc-2 [/quote] Something like that. Maybe it could do `SECTION.ad-hoc-ovl1` and `SECTION.ad-hoc-ovl2` to make it easier to spot overlays. [quote="pablo, post:29, topic:3013"] That is the border case for a whole family of test cases that show the issue at hand, and there is clearly no extra set of constraints added to neither occurrences of SECTION.ad-hoc. [/quote] See previous comment above! [quote="sebastian.garde, post:30, topic:3013"] Just wanted to point you to the following Jira issue which describes a similar issue and has already created some discussion as well [/quote] Thanks Sebastian - we got close to the same point before, and indeed, Heath's suggestion in that thread is a nice solution I think. --- ## Post #32 by @pablo [quote="thomas.beale, post:31, topic:3013"] [quote="pablo, post:29, topic:3013"] For both sections, the items are not constrained, just the names, then there is a need of identifying each individually [/quote] But name is constrained (at least that’s what I assume you meant with that short-hand!). ADL doesn’t differentiate between different attributes being constrained. Any constraint is a constraint. [/quote] True. So a name constraint in AOM2 is considered a specialization of the base archetype? [quote="thomas.beale, post:31, topic:3013"] [quote="pablo, post:29, topic:3013"] So in ADL2, if I understood correctly, the editor tool should mark the first one as SECTION.ad-hoc-1 and the second as SECTION.ad-hoc-2 [/quote] Something like that. Maybe it could do `SECTION.ad-hoc-ovl1` and `SECTION.ad-hoc-ovl2` to make it easier to spot overlays. [/quote] Yes, I'm not focusing on syntax but meaning. Any code or number is basically the same. That is why I mentioned that having a specific field to represent the code/number that differentiates nodes could be a clearer solution than coding in the archetype ID. Something like archetype_id = X, template_node_id = 1 (then 2, 3, 4 for the rest of the C_OBJECTs with the same archetype_id and path). That way we can use the original archetype IDs in queries instead of the aliases. Though I'm not familiar with the concept of an `overlay`, for me is just like assigning an alias to the archetype ID to keep them unique in cases of collisions. --- ## Post #33 by @thomas.beale [quote="pablo, post:32, topic:3013"] So a name constraint in AOM2 is considered a specialization of the base archetype? [/quote] From a formal computing point of view, any specialised property is a constraint, and creates a specialised archetype or overlay (which is just an inline specialised archetype). [quote="pablo, post:32, topic:3013"] Though I’m not familiar with the concept of an `overlay`, for me is just like assigning an alias to the archetype ID to keep them unique in cases of collisions. [/quote] [Here's an example of a full template](https://github.com/openEHR/adl-archetypes/blob/master/Example/openEHR/single_file_template/templates/openEHR-EHR-COMPOSITION.t_clinical_info_ds_sf.v1.0.0.adls) with overlays in Github - keep scrolling down ;) --- ## Post #34 by @ian.mcnicoll Thanks Thomas, It would be really helpful to have an example of a composition instance to understand the implications for querying/ backward compatibility. Could @pieterbos maybe give us an example (does not need to match that template)? --- ## Post #35 by @pablo [quote="thomas.beale, post:33, topic:3013"] [quote="pablo, post:32, topic:3013"] Though I’m not familiar with the concept of an `overlay`, for me is just like assigning an alias to the archetype ID to keep them unique in cases of collisions. [/quote] [Here’s an example of a full template ](https://github.com/openEHR/adl-archetypes/blob/master/Example/openEHR/single_file_template/templates/openEHR-EHR-COMPOSITION.t_clinical_info_ds_sf.v1.0.0.adls) with overlays in Github - keep scrolling down :wink: [/quote] Gotcha, so `overlay` is actually a construct in AOM2, not really used in the computing way. > In a general *computing* sense, overlaying means "the process of transferring a block of program code or other data into main memory... [quote="ian.mcnicoll, post:34, topic:3013"] It would be really helpful to have an example of a composition instance to understand the implications for querying/ backward compatibility. Could @pieterbos maybe give us an example (does not need to match that template)? [/quote] An example would be helpful! I was wondering how a system receiving a COMPOSITION commit (or any LOCATABLE) handles it when it's constrained by an OPT 1.4 or an OPT 2. I mean, how the system can differentiate them for validating, processing, querying? --- ## Post #36 by @thomas.beale [quote="pablo, post:35, topic:3013"] Gotcha, so `overlay` is actually a construct in AOM2, not really used in the computing way [/quote] ah - you were thinking some kind of memory overlays like in the old PC / DB languages - no, it's not that ;) BTW, Archetype Designer and Archie know how to read these ADL2 templates (for probably a couple of years at least). --- ## Post #37 by @pablo [quote="thomas.beale, post:36, topic:3013"] ah - you were thinking some kind of memory overlays like in the old PC / DB languages - no, it’s not that :wink: [/quote] I was trying to link the term to something that I know, but in this case seems to be an arbitrary name to a special case of archetype specialization. I'm still not familiar with the AOM2 spec :slight_smile: --- **Canonical:** https://discourse.openehr.org/t/aom-how-do-you-differentiate-between-sibling-c-object-if-both-are-archetype-root-and-have-the-same-archetype-id/3013 **Original content:** https://discourse.openehr.org/t/aom-how-do-you-differentiate-between-sibling-c-object-if-both-are-archetype-root-and-have-the-same-archetype-id/3013