# Finalising archetype meta-data
**URL:** https://discourse.openehr.org/t/finalising-archetype-meta-data/15330
**Category:** Technical (archive)
**Created:** [20 November 2014 14:50 UTC](https://discourse.openehr.org/t/finalising-archetype-meta-data/15330 "2014-11-20T14:50:31Z")
**Posts on this page:** 3
**Page:** 1
### Author:  [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [20 November 2014 14:50 UTC](https://discourse.openehr.org/t/finalising-archetype-meta-data/15330/1 "2014-11-20T14:50:31Z")
There is a [test archetype here](https://github.com/openEHR/adl-archetypes/blob/master/ADL15-reference/features/meta_data/openehr-test_pkg-WHOLE.full_meta_data.v0.0.1.adls)that shows an example of proposed new meta-data items.
Things to notice:
- ‘rm\_release=1.0.2’ in the top line. Rm\_release is now a mandatory item in ADL 2 (but easy to synthesise in converters)
- ‘copyright’ is now at the outer level, before it was in the translatable part, i.e. with ‘keywords’ etc - now there is only one copyright statement for an archetype
- ‘licence’ is a new item
- there are items for ‘original\_xxx’ and ‘custodian\_xxx’ intended to document the original organisation that created something, and the current custodian of that thing.
- proposed new blocks for ‘ip\_acknowledgements’ and ‘conversion\_details’
A question I have is: are the items for original publisher / namespace and custodian organisation enough?
Currently they are as follows:
original\_namespace = \<“org.archetypes-r-us”\>
original\_publisher = \<“Archetypes R Us”\>
custodian\_namespace = \<“org.openehr”\>
custodian\_organisation = \<“openEHR Foundation”\>
However, if we thing we need any more items for these two, we are stuck with this model - the only place we could put new items would be in the main ‘other\_details’ block. Should we instead do the following:
original\_publisher = \<
organisation = \<“Archetypes R Us”\>
namespace = \<“org.archetypes-r-us”\>
other\_details = \<
[“key”] = \<“value”\>
[“key”] = \<“value”\>
…
>
custodian = \<
organisation = \<“openEHR Foundation”\>
namespace = \<“org.openehr”\>
other\_details = \<
[“key”] = \<“value”\>
[“key”] = \<“value”\>
…
>
This is only slightly more complex, but much more flexible. As we are finalising the ADL/AOM 2 specifications, this is one of the last issues, so now is a good time to decide if we need to change this.
It is worth noting that we have done the ip\_acknowledgements and conversion\_details (both imminently needed by CIMI) differently:
ip\_acknowledgements = \<
[“loinc”] = \<“This content from LOINC® is copyright © 1995 Regenstrief Institute, Inc. and the LOINC Committee, and available at no cost under the license at [http://loinc.org/terms-of-use](http://loinc.org/terms-of-use)”\>
[“snomedct”] = \<“xyz”\>
>
conversion\_details = \<
[“source\_model”] = \<“CEM xyz [http://location.in.clinicalelementmodels.com](http://location.in.clinicalelementmodels.com)”\>
[“tool”] = \<“cem2adl v6.3.0”\>
[“time”] = \<“2014-11-03T09:05:00”\>
>
This is because in the first case, the structure is logically a keyed list of values, where we never know the keys, and in the ‘conversion\_details’ case, because we are not currently sure of the keys (and maybe we’ll never have standard keys for that).
- thomas
---
### Author:  [@Heath\_Frankel3](https://discourse.openehr.org/u/Heath_Frankel3)
#### Post date: [20 November 2014 21:16 UTC](https://discourse.openehr.org/t/finalising-archetype-meta-data/15330/2 "2014-11-20T21:16:53Z")
Hi Thomas,
I am not sure why we can’t use other-details for all of these. It doesn’t seem critical for processing archetypes, it is only for reference.
Regards
Heath
---
### Author:  [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [20 November 2014 22:26 UTC](https://discourse.openehr.org/t/finalising-archetype-meta-data/15330/3 "2014-11-20T22:26:07Z")
We could use other\_details. However, the downside is that none of the tags are standardised when you do that, so you always run the risk of different tools / users creating variant structures they think will match but don't (even just not agreeing on international v US English for example). We'll always have to use other\_details for things we don't know yet anyway, but where we think we know the logical 'tags', it may make sense to add them to the model as such.
- thomas
> **(attachments)**
>
> 
> 