Following conversations with Ian McNicoll and others working on the archetype meta-data question, I have posted a possible revised model containing the following changes to the current one:
copyright has been moved to the non-translated top-level description
license has been added to the description
custodian_namespace has been added to the description
custodian_organisation has been added to the description
We will need to decide on the ‘revision/validation date’ concept and add that in.
Do really is_template & is_overlay need to be mandatory? 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?
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.
Looking good. I think we do need to think of adding 'version_id to
each Translation to help developers know which original language
version/revision has been used to create the translation. This was
something that Bert mentioned.
I hadn't even thought of that but very good point. But that is something like 'version_translated' or 'translation_version' i.e. not the version of the artefact as it is now, but the version at which this particular translation was done. So an archetype with 10 translations could in fact have 10 different minor translation_version values, all different from the current version of the artefact...
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. 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). 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 . There is overlap but it seems unavoidable to me. - thomas
