I repost this discussion from the java implementation list, I think it could be interesting to get feedback from the general implementers community.
(attachments)
imo
1- Slots need to 'point at’ archetypes by Name of the Archetype and NOT the file name. Plus something else …
2- All Nodes in any archetype never derive any meaning from the text of the label attached the Node and thereby can be language independent. Archetypes written in different languages can be used at will. This is possible only when …
3- Node names derive their identity (meaning) from a code from a predefined code set.
4- In addition we must be able to ‘point at’ other archetypes using unique identifiers, or a construct using generated Hash-codes for each unique archetype.
Gerard Freriks
+31 620347088
gfrer@luna.nl
imo
1- Slots need to 'point at’ archetypes by Name of the Archetype and NOT the file name. Plus something else …
2- All Nodes in any archetype never derive any meaning from the text of the label attached the Node and thereby can be language independent. Archetypes written in different languages can be used at will. This is possible only when …
3- Node names derive their identity (meaning) from a code from a predefined code set.
4- In addition we must be able to ‘point at’ other archetypes using unique identifiers, or a construct using generated Hash-codes for each unique archetype.
Gerard Freriks
+31 620347088
gfrer@luna.nl
Hi Gerard,
1- Slots need to 'point at’ archetypes by Name of the Archetype and NOT the file name. Plus something else …
2- All Nodes in any archetype never derive any meaning from the text of the label attached the Node and thereby can be language independent. Archetypes written in different languages can be used at
will. This is possible only when …
3- Node names derive their identity (meaning) from a code from a predefined code set.
4- In addition we must be able to ‘point at’ other archetypes using unique identifiers, or a construct using generated Hash-codes for each unique archetype.
Agreed with all of these points and 1-4 are already in use (4 via Hash codes but we would prefer to move to namespaced/ properly versioned/revisioned archetypes) however these are not related to Diego’s question.
I am not sure that I really understand the issue. I would always expect all of the archetypes in a template to be translated into the ‘local language’ of the template. Whether en-gb = en is always tricky and you really need to get a clinician to eyeball the eventual dataset in the local language to make sure that there are no inadvertant confusions.
Am I missing something?
Ian
Gerard, this has always been the case. I hope no-one is implementing anything to do with filenames! well that’s sort of true, in the sense that the computing layer (tools, EHRs etc) rely on the codes, not the words. But where humans work with the models, or enter data into screens generated in their natural language from a template, then the ‘meaning’ is to do with the linguistic definitions, since it’s how humans know what data to enter in to what field. that’s an ideal - the practical reality is a long way off. So a better statement is: node names can be associated with terms from predefined code sets at any time, including a long time after the archetype was originally created. In ADL 1.5, there is a ‘direct reference’ aka ‘external reference’ which does this - unlike a slot, there are no regex patterns, just a full archetype id. The idea of using hash codes in slots (e.g. MD5s) has been mentioned in the past, but I don’t think it’s likely to be maintainable. In any case, the proposed referencing rules are described if anyone wants to comment on or improve them. - thomas