Update on meta-data for openEHR and 13606

Diego Boscá yampeku at gmail.com
Mon Jan 27 09:31:44 EST 2014


Yes, the reason I said to move it to resource_description was because
lifecycle_state was already there. I agree that version_status must exist.


2014-01-27 Thomas Beale <thomas.beale at oceaninformatics.com>

>  On 27/01/2014 13:37, Diego Boscá wrote:
>
>   Just a couple of comments:
>
>  Do really is_template & is_overlay need to be mandatory?
>
>
> well they are only mandatory due to being Booleans, and in standard
> programming languages, Boolean (or bool or whatever) is a builtin type that
> is always there. In XML and other serialisations, it's true that anything
> can be optional (normally absence = False for Boolean). I should probably
> change this to reflect that.
>
>
>   I would say that they can be optional if you are dealing with
> archetypes (assuming that all archetypes are just archetypes by default).
>  What does exactly 'is_overlay' refers to?
>
>
> an overlay is a cut-down archetype that is used as a template-specific
> slot-filler to provide the overrides on a standard slot filler. E.g. say
> you want to put 'symptom' CLUSTER archetype in a CLUSTER slot for template
> T, but just for that template you also want to remove 3 of the 5 data
> points of the symptom structure. So you create a specialised (1.5)
> archetype that does that just for that template. It's the same as any other
> specialised archetype, except it has almost nothing in the description
> section, because it gets all that from the template. So an overlay can't be
> used standalone, but obviously, tools could convert one to a real
> archetype.
>
> In 1.5, a template is essentially a specialised archetype with a bunch of
> other filler archetypes, templates and / or overlays (maybe all overlays).
>
>
>
>  Also, I think that you could argue that version_status is more suitable
> to be placed into the resource_description instead of where it is now.
>
>
> version_status, or something equivalent is needed with the version_id
> attributes, so that the full version id can be constructed, e.g. 1.0.4-rc28
> - the version_status is what tells you that it's an 'rc' (release
> candidate), full release (1.0.4), uncontrolled additions (1.0.4+u88) and so
> on. It's related to the lifecycle_state, which has more values like
> 'initial', 'obsolete', and so on, according to this state diagram<http://www.openehr.org/wiki/download/attachments/5996562/artefact_lifecycle_versioning.png?version=1&modificationDate=1366562248000&api=v2>.
> There is overlap but it seems unavoidable to me.
>
> - thomas
>
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140127/9b427844/attachment.html>


More information about the openEHR-technical mailing list