The problem
There are various long-running problem(s) with archetype node ids in ADL 1.4 and also the current ADL/AOM 1.5 specifications, which are:
...
The main aim here is to create an archetype node-id system that really works for everyone in the same way.
Solution - round 1
The proposal here is to fix the node id system properly. The cost of doing that is to take a new tack on backwards-compatibility of ADL/AOM 1.5 with ADL 1.4:
...
Below is the same archetype in the modified ADL workbench.
 |  |
|---|
Advantages
These changes should make implementation a lot easier, because now regular rules are used to define all codes at all levels, and also, every node really does have a code now.
One nice advantage of having id-codes and at-codes is that now we can distinguish codes for 'names' from codes for 'values'. We could potentially imagine going even further and arranging the archetype terminology so that at-code value sets are properly grouped.
Possible Problems
One potential problem with the above solution is that since a list of codes will typically be sorted lexically (e.g. in some visual list control), the numeric order is not preserved. I.e. now we get the following in a flat archetype codes list:
...
It's not yet clear if this matters anywhere.
Solution - round 2
In the next step we would rationalise all coded term constraints to URIs, following recent IHTSDO work, and particularly Harold Solbrig's analysis of both terms-as-URIs and of ADL/AOM 1.5 specifications. This has not yet been implemented, but would have the following effect:
- ac-codes would be converted to at-codes, and the 'constraint_definitions' part of the archetype terminology would disappear
- or possibly, keep the 'ac' code leader, to distinguish, but still merge 'constraint_definitions' into 'term_definitions'
- the CONSTRAINT_REF type would be removed entirely, and its semantics merged into C_TERMINOLOGY_CODE. This will simplify the specification, getting rid of an annoying C_OBJECT subtype, and making terminology constraints more regular.
Conversion of ADL 1.4 archetypes
I have implemented a converter for ADL 1.4 and also existing ADL 1.5 archetypes which does:
...
NOTE: I have build this capability into a new version of the ADL workbench, to avoid others having the write the same converter. For release soon..
Upgrading of existing ADL 1.5 Tools
All current implementations of ADL / AOM 1.5 rules would need to be upgraded if the community decides to go forward with this proposal (or one like it). However, the pain of that should hopefully be offset by the code simplifications that result, and more clarity for future implementers and users of relevant libraries.
Background
The following is an email sent to some archetype software implementers on 9 Dec 2013. The implementation work above is based on a modified version of option A4 below. Not everyone I wrote to agrees with this choice! I didn't like it that much either, but in implementation it turns out to be quite nice.
...