The Archetype Package
Overview
The top-level model of archetypes and templates (all variant forms) is illustrated in the Figure below. The model defines a standard structural representation of an archetype. Archetypes authored as independent entities are instances of the class AUTHORED_ARCHETYPE which is a descendant of AUTHORED_RESOURCE and ARCHETYPE. The first of the two parent classes provides a standardised model of descriptive meta-data, language information, and annotations for any resource, and is documented in the openEHR Resource Model. The resource classes are shown included in the diagram below. The second parent class defines the core structure of any kind of archetype, including definition, terminology, optional rules part, along with a 'semantic identifier' (ARCHETYPE.archetype_id).
am.aom2.archetype PackageThe AUTHORED_ARCHETYPE class adds identifying attributes, flags and descriptive meta-data, and is the ancestor type for two further specialisations - TEMPLATE and OPERATIONAL_TEMPLATE . The TEMPLATE class defines the notion of a 'templated' archetype, i.e. an archetype containing fillers/references (ADL’s use_archetype statements), typically designed to represent a data set. To enable this, it may contain 'overlays', private archetypes that specialise one or more of the referenced / filler archetypes it uses. Overlays are instances of the TEMPLATE_OVERLAY class, have no meta-data of their own, but are otherwise computationally just like any other archetype.
The OPERATIONAL_TEMPLATE class represents the fully flattened form of a template, i.e. with all fillers and references substituted and overlays processed, to form what is in practical terms, a single custom-made 'operational' artefact, ready for transformation to downstream artefacts. Because an operational template includes one or more other archetype structures inline, it also includes their terminologies, enabling it to be treated as a self-standing artefact.
Archetype Identification
Human-Readable Identifier (HRID)
All archetype variants based on ARCHETYPE have a human-readable, structured identifier defined by the ARCHETYPE_HRID class. This identifier places the artefact in a multi-dimensional space based on a namespace, its reference model class and its informational concept. This class defines an atomised representation of the identifier, enabling variant forms to be used as needed. Its various parts can be understood from the following diagram, which also shows the computed semantic_id and physical_id forms.
For specialised archetypes, the parent_archetype_id is also required. This is a string reference to an archetype, and is normally the 'interface' form of the id, i.e. down to the major version only. In some circumstances, it is useful to include the minor and patch version numbers as well.
An important aspect of identification relates to the rules governing when the HRID namespace changes or is retained, with respect to when 'moves' or 'forks' occur. Its value is always the same as one of the original_namespace and custodian_namespace properties inherited from AUTHORED_RESOURCE.description (or both, in the case where they are the same). A full explanation of the identification system and rules is given in the openEHR Archetype Identification specification.
Machine Identifiers
Two machine identifiers are defined for archetypes. The ARCHETYPE.uid attribute defines a machine identifier equivalent to the human readable ARCHETYPE.archetype_id.semantic_id , i.e. ARCHETYPE_HRID up to its major version, and changes whenever the latter does. It is defined as optional but to be practically useful would need to be mandatory for all archetypes within a custodian organisation where this identifier was in use. It could in principle be synthesised at any time for a custodian that decided to implement it.
The ARCHETYPE.build_uid attribute is also optional, and if used, is intended to provide a unique identifier that corresponds to any change in version of the artefact. At a minimum, this means generating a new UUID for each change to:
-
ARCHETYPE.archetype_id.release_version; -
ARCHETYPE.archetype_id.build_count; -
ARCHETYPE.description.lifecycle_state.
For every change made to an archetype inside a controlled repository (for example, addition or update of meta-data fields), this field should be updated with a new UUID value, generated in the normal way.
Top-level Meta-data
The following items correspond to syntax elements that may appear in parentheses in the first line of an ADL archetype.
ADL Version
The ARCHETYPE.adl_version attribute in ADL 1.4 was used to indicate the ADL release used in the archetype source file from which the AOM structure was created (the version number comes from the amendment record of the ADL2 specification. In the current and future AOM and ADL specifications, the meaning of this attribute is generalised to mean 'the version of the archetype formalism' in which the current archetype is expressed. For reasons of convenience, the version number is still taken from the ADL specification, but now refers to all archetype-related specifications together, since they are always updated in a synchronised fashion.
Reference Model Release
The ARCHETYPE.rm_release attribute designates the release of the reference model on which the archetype is based, in the archetype’s current version. This means rm_release can change with new versions of the archetype, where re-versioning includes upgrading the archetype to a later RM release. However, such upgrading still has to obey the basic rule of archetype compatibility: later minor, patch versions and builds cannot create data that is not valid with respect to the prior version.
This should be in the same semver.org 3-part form as the ARCHETYPE_HRID.release_version property, e.g. "1.0.2". This property does not indicate conformance to any particular reference model version(s) other than the named one, since most archetypes can easily conform to more than one. More minimal archetypes are likely to technically conform to more old and future releases than more complex archetypes.
Generated Flag
The ARCHETYPE.is_generated flag is used to indicate that an archetype has been machine-generated from another artefact, e.g. an older ADL version (say 1.4), or a non-archetype artefact. If true, it indicates to tools that the current archetype can potentially be overwritten, and that some other artefact is considered the primary source. If manual authoring occurs, this attribute should be set to False.
Governance Meta-data
Various meta-data elements are inherited from the AUTHORED_RESOURCE class, and provide the natural language description of the archetype, authoring and translation details, use, misuse, keywords and so on. There are three distinct parts of the meta-data: governance, authorship, and descriptive details.
Governance Meta-data Items
Governance meta-data is visible primarily in the RESOURCE_DESCRIPTION class, inherited via AUTHORED_RESOURCE, and consists of items relating to management and intellectual property status of the artefact. A typical form of these is shown in the screenshot in Governance Meta-data.
Package
The optional resource_package_uri property enables the recording of a reference to a package of archetypes or other resources, to which this archetype is considered to below. Its value may be in the form of "text <URL>".
Lifecycle_state
The description.lifecycle_state is an important property of an archetype, which is used to record its state in a defined lifecycle. The lifecycle state machine and versioning rules are explained fully in the openEHR Archetype Identification specification. Here we simply note that the value of the property is a coded term corresponding to one of the macro-state names on the diagram, i.e. 'unmanaged', 'in_development', and so on.
Original_namespace and Original_publisher
These two optional properties indicate the original publishing organisation, and its namespace, i.e. the original publishing environment where the artefact was first imported or created. The original_namespace property is normally the same value as archetype_id.namespace,unless the artefact has been forked into its current custodian, in which case archetype_id.namespace will be the same as custodian_namespace.
Custodian_namespace and Custodian_organisation
These two optional properties state a formal namespace, and a human-readable organisation identifier corresponding to the current custodian, i.e. maintainer and publisher of the artefact, if there is one.
Intellectual Property Items
There are three properties in the class that RESOURCE_DESCRIPTION relate to intellectual property (IP). Licence is a String field for recording of the licence (US: 'license') under which the artefact can be used. The recommended format is as follows:
licence name <reliable URL to licence statement>
The copyright property records the copyright applying to the artefact, and is normally in the standard form '(c) name' or '(c) year name'. The special character © may also be used (UTF-8 0xC2A9).
Authorship Meta-data
Authorship meta-data consists of items such as author name, contributors, and translator information, and is visualised in the figure below.
Original Author
The RESOURCE_DESCRIPTION.original_author property defines a simple list of name/value pairs via which the original author can be documented. Typical key values include "name", "organi[zs]ation", "email" and `"date"`".
Contributors
The RESOURCE_DESCRIPTION.other_contributors property is a simple list of strings, one for each contributor. The recommended format of the string is one of:
first names last name, organisation first names last name, organisation <contributor email address> first names last name, organisation <organisation email address>
Languages and Translation
The AUTHORED_RESOURCE.original_language and TRANSLATION_DETAILS class enable the original language of authoring and information relating to subsequent translations to be expressed. TRANSLATION_DETAILS.author allows each translator to be represented in the same way as the original_author , i.e. a list of name/values.
Version_last_translated
The version_last_translated property is used to record a copy of the archetype_id.physical_id for each language, when the translation was carried out. This enables maintainers to know when new translations are needed for some or all languages. This String property records the full version identifier (i.e. ARCHETYPE.archetype_id.version_id) at the time of last translation, enabling tools to determine if and when translations may be out of date.
Descriptive Meta-data
Various descriptive meta-data may be provided for an archetype in multiple translations in the RESOURCE_DESCRIPTION_ITEM class, using one instance for each translation language, as shown in the figure below.
Purpose
The purpose item is a String property for recording the intended design concept of the artefact.
Use and Misuse
The use and misuse properties enable specific uses and misuses to be documented. The latter normally relate to common errors of use, or apparently reasonable but wrong assumptions about use.
Keywords
The keywords property is a list of Strings designed to record search keywords for the artefact.
Resources
The original_resource_uri property is used to record one or more references to resources in each particular language.
TBD: This property does not appear to have ever been used, and it may not be useful, since 'resources' are not typically available for each language.
Structural Definition
Common Structural Parts
The archetype definition is the main definitional part of an archetype and is an instance of a C_COMPLEX_OBJECT . This means that the root of the constraint structure of an archetype always takes the form of a constraint on a non-primitive object type.
The terminology section of an archetype is represented by its own classes, and is what allows archetypes to be natural language- and terminology-neutral. It is described in detail in [_terminology_package].
An archetype may include one or more rules. Rules are statements expressed in a subset of predicate logic, which can be used to state constraints on multiple parts of an object. They are not needed to constrain single attributes or objects (since this can be done with an appropriate C_ATTRIBUTE or C_OBJECT ), but are necessary for constraints referring to more than one attribute, such as a constraint that 'systolic pressure should be >= diastolic pressure' in a blood pressure measurement archetype. They can also be used to declare variables, including external data query results, and make other constraints dependent on a variable value, e.g. the gender of the record subject.
Lastly, the annotations section, inherited from the AUTHORED_RESOURCE class, can be included as required. This section is of particular relevance to archetypes and templates, and is used to document individual nodes within an archetype or template, and/or nodes in reference model data, that may not be constrained in the archetype, but whose specific use in the archetyped data needs to be documented. In the former case, the annotations are keyed by an archetype path, while in the latter case, by a reference model path.
Structural Variants
The model in am.aom2.archetype Package defines the structures of a number of variants of the 'archetype' idea. All concrete instances are instances of one of the concrete descendants of ARCHETYPE. Source Archetype Structure illustrates the typical object structure of a source archetype - the form of archetype created by an authoring tool - represented by a DIFFERENTIAL_ARCHETYPE instance. Mandatory parts are shown in bold.
Source archetypes can be specialised, in which case their definition structure is a partial overlay on the flat parent, or 'top-level', in which case the definition structure is complete. C_ARCHETYPE_ROOT instances may only occur representing direct references to other archetypes - 'external references'.
A flat archetype is generated from one or more source archetypes via the flattening process described in the next chapter of this specification, (also in the ADL specification). This generates a FLAT_ARCHETYPE from a DIFFERENTIAL_ARCHETYPE instance. The main two changes that occur in this operation are a) specialised archetype overlays are applied to the flat parent structure, resulting in a full archetype structure, and b) internal references (use_nodes) are replaced by their expanded form, i.e. a copy of the subtrees to which they point.
This form is used to represent the full 'operational' structure of a specialised archetype, and has two uses. The first is to generate backwards compatible ADL 1.4 legacy archetypes (always in flat form); the second is during the template flattening process, when the flat forms of all referenced archetypes and templates are ultimately combined into a single operational template.
Source Template Structure illustrates the structure of a source template, i.e instances of TEMPLATE. A source template is an archetype containing C_ARCHETYPE_ROOT objects representing slot fillers - each referring to an external archetype or template, or potentially an overlay archetype.
Another archetype variant, also shown in Source Template Structure is the template overlay, i.e. an instance of TEMPLATE_OVERLAY. These are purely local components of templates, and include only the definition and terminology. The definition structure is always a specialised overlay on something else, and may not contain any slot fillers or external references, i.e. no C_ARCHETYPE_ROOT objects. No identifier, adl_version, languages or description are required, as they are considered to be propagated from the owning root template. Accordingly, template overlays act like a simplified specialised archetype. Template overlays can be thought of as being similar to 'anonymous' or 'inner' classes in some object-oriented programming languages.
Operational Template Structure illustrates the resulting operational template, or compiled form of a template. This is created by building the composition of referenced archetypes and/or templates and/or template overlays, in their flattened form, to generate a single 'giant' archetype. The root node of this archetype, along with every archetype/template root node within, is represented using a C_ARCHETYPE_ROOT object. An operational template also has a component_terminologies property containing the ontologies from every constituent archetype, template and overlay.
More details of template development, representation and semantics are described in the next section.
Class Descriptions
ARCHETYPE Class
-
Definition
-
Effective
-
BMM
-
UML
Class |
ARCHETYPE (abstract) |
|
|---|---|---|
Description |
The |
|
Attributes |
Signature |
Meaning |
0..1 |
parent_archetype_id: |
Archetype reference of the specialisation parent of this archetype, if applicable. May take the form of an archetype interface identifier, i.e. the identifier up to the major version only, or may be a full archetype identifier. |
1..1 |
archetype_id: |
Identifier of this archetype. |
1..1 |
is_differential: |
Flag indicating whether this archetype is differential or flat in its contents. Top-level source archetypes have this flag set to True. |
1..1 |
definition: |
Root node of the definition of this archetype. |
1..1 |
terminology: |
The terminology of the archetype. |
0..1 |
rules: |
Rules relating to this archetype. Statements are expressed in first order predicate logic, and usually refer to at least two attributes. |
0..1 |
rm_overlay: |
|
Functions |
Signature |
Meaning |
1..1 |
concept_code (): |
The concept code of the root object of the archetype, also standing for the concept of the archetype as a whole. |
1..1 |
Set of language-independent paths extracted from archetype. Paths obey Xpath-like syntax and are formed from alternations of |
|
1..1 |
Set of language-dependent paths extracted from archetype. Paths obey the same syntax as physical_paths, but with node_ids replaced by their meanings from the terminology. |
|
1..1 |
specialisation_depth (): |
Specialisation depth of this archetype; larger than 0 if this archetype has a parent. Derived from terminology.specialisation_depth. |
1..1 |
is_specialised (): |
True if this archetype is a specialisation of another. |
Invariants |
Invariant_concept_valid: |
|
Invariant_specialisation_validity: |
||
| ARCHETYPE (abstract) | |
|---|---|
The |
|
Attributes |
|
parent_archetype_id: |
Archetype reference of the specialisation parent of this archetype, if applicable. May take the form of an archetype interface identifier, i.e. the identifier up to the major version only, or may be a full archetype identifier. |
archetype_id: |
Identifier of this archetype. |
is_differential: |
Flag indicating whether this archetype is differential or flat in its contents. Top-level source archetypes have this flag set to True. |
definition: |
Root node of the definition of this archetype. |
terminology: |
The terminology of the archetype. |
rules: |
Rules relating to this archetype. Statements are expressed in first order predicate logic, and usually refer to at least two attributes. |
rm_overlay: |
|
Functions |
|
concept_code (): |
The concept code of the root object of the archetype, also standing for the concept of the archetype as a whole. |
Set of language-independent paths extracted from archetype. Paths obey Xpath-like syntax and are formed from alternations of |
|
Set of language-dependent paths extracted from archetype. Paths obey the same syntax as physical_paths, but with node_ids replaced by their meanings from the terminology. |
|
specialisation_depth (): |
Specialisation depth of this archetype; larger than 0 if this archetype has a parent. Derived from terminology.specialisation_depth. |
is_specialised (): |
True if this archetype is a specialisation of another. |
Invariants |
|
Invariant_concept_valid: |
|
Invariant_specialisation_validity: |
|
{
"name": "ARCHETYPE",
"documentation": "The `ARCHETYPE` class defines the core formal model of the root object of any archetype or template. It includes only basic identification information, and otherwise provides the structural connections from the Archetype to its constituent parts, i.e. definition (a `C_COMPLEX_OBJECT`), terminology (`ARCHEYTPE_TERMINOLOGY`) and so on. \nIt is the parent class of all concrete types of archetype.",
"is_abstract": true,
"properties": {
"parent_archetype_id": {
"_type": "P_BMM_SINGLE_PROPERTY",
"name": "parent_archetype_id",
"documentation": "Archetype reference of the specialisation parent of this archetype, if applicable. May take the form of an archetype interface identifier, i.e. the identifier up to the major version only, or may be a full archetype identifier.",
"type": "String"
},
"archetype_id": {
"_type": "P_BMM_SINGLE_PROPERTY",
"name": "archetype_id",
"documentation": "Identifier of this archetype.",
"is_mandatory": true,
"type": "ARCHETYPE_HRID"
},
"is_differential": {
"_type": "P_BMM_SINGLE_PROPERTY",
"name": "is_differential",
"documentation": "Flag indicating whether this archetype is differential or flat in its contents. Top-level source archetypes have this flag set to True.",
"is_mandatory": true,
"type": "Boolean"
},
"definition": {
"_type": "P_BMM_SINGLE_PROPERTY",
"name": "definition",
"documentation": "Root node of the definition of this archetype.",
"is_mandatory": true,
"type": "C_COMPLEX_OBJECT"
},
"terminology": {
"_type": "P_BMM_SINGLE_PROPERTY",
"name": "terminology",
"documentation": "The terminology of the archetype.",
"is_mandatory": true,
"type": "ARCHETYPE_TERMINOLOGY"
},
"rules": {
"_type": "P_BMM_CONTAINER_PROPERTY",
"name": "rules",
"documentation": "Rules relating to this archetype. Statements are expressed in first order predicate logic, and usually refer to at least two attributes.",
"type_def": {
"container_type": "List",
"type": "STATEMENT_SET"
},
"cardinality": {
"lower": 0,
"upper_unbounded": true
}
},
"rm_overlay": {
"_type": "P_BMM_SINGLE_PROPERTY",
"name": "rm_overlay",
"type": "RM_OVERLAY"
}
},
"functions": {
"concept_code": {
"name": "concept_code",
"documentation": "The concept code of the root object of the archetype, also standing for the concept of the archetype as a whole.",
"post_conditions": {
"post-condition": "Result.is_equal (definition.node_id)"
},
"result": {
"_type": "P_BMM_SIMPLE_TYPE",
"type": "String"
}
},
"physical_paths": {
"name": "physical_paths",
"documentation": "Set of language-independent paths extracted from archetype. Paths obey Xpath-like syntax and are formed from alternations of `C_OBJECT._node_id_` and `C_ATTRIBUTE._rm_attribute_name_` values. ",
"result": {
"_type": "P_BMM_CONTAINER_TYPE",
"container_type": "List",
"type": "String"
}
},
"logical_paths": {
"name": "logical_paths",
"documentation": "Set of language-dependent paths extracted from archetype. Paths obey the same syntax as physical_paths, but with node_ids replaced by their meanings from the terminology. ",
"parameters": {
"lang": {
"_type": "P_BMM_SINGLE_FUNCTION_PARAMETER",
"name": "lang",
"type": "String"
}
},
"result": {
"_type": "P_BMM_CONTAINER_TYPE",
"container_type": "List",
"type": "String"
}
},
"specialisation_depth": {
"name": "specialisation_depth",
"documentation": "Specialisation depth of this archetype; larger than 0 if this archetype has a parent. Derived from terminology.specialisation_depth.",
"post_conditions": {
"post-condition": "Result = terminology.specialisation_depth"
},
"result": {
"_type": "P_BMM_SIMPLE_TYPE",
"type": "Integer"
}
},
"is_specialised": {
"name": "is_specialised",
"documentation": "True if this archetype is a specialisation of another. ",
"post_conditions": {
"post-condition": "Result implies parent_archetype_hrid /= Void"
},
"result": {
"_type": "P_BMM_SIMPLE_TYPE",
"type": "Boolean"
}
}
},
"invariants": {
"Invariant_concept_valid": "terminology.has_term_code (concept_code)",
"Invariant_specialisation_validity": "is_specialised implies specialisation_depth > 0"
}
}AUTHORED_ARCHETYPE Class
-
Definition
-
Effective
-
BMM
-
UML
Class |
AUTHORED_ARCHETYPE |
|
|---|---|---|
Description |
Root object of a standalone, authored archetype, including all meta-data, description, other identifiers and lifecycle. |
|
Inherit |
||
Attributes |
Signature |
Meaning |
0..1 |
adl_version: |
ADL version if archetype was read in from an ADL sharable archetype. |
1..1 |
build_uid: |
Unique identifier of this archetype artefact instance. A new identifier is assigned every time the content is changed by a tool. Used by tools to distinguish different revisions and/or interim snapshots of the same artefact. |
1..1 |
rm_release: |
Semver.org compatible release of the most recent reference model release on which the archetype in its current version is based. This does not imply conformance only to this release, since an archetype may be valid with respect to multiple releases of a reference model. |
1..1 |
is_generated: |
If True, indicates that this artefact was machine-generated from some other source, in which case, tools would expect to overwrite this artefact on a new generation. Editing tools should set this value to False when a user starts to manually edit an archetype. |
1..1 |
||
Invariants |
Invariant_adl_version_validity: |
|
Invariant_rm_release: |
||
Description_validity: |
||
| AUTHORED_ARCHETYPE | |
|---|---|
Root object of a standalone, authored archetype, including all meta-data, description, other identifiers and lifecycle. |
|
Inherits: ARCHETYPE, AUTHORED_RESOURCE |
|
Attributes |
|
Archetype reference of the specialisation parent of this archetype, if applicable. May take the form of an archetype interface identifier, i.e. the identifier up to the major version only, or may be a full archetype identifier. |
|
ARCHETYPE.archetype_id: |
Identifier of this archetype. |
Flag indicating whether this archetype is differential or flat in its contents. Top-level source archetypes have this flag set to True. |
|
ARCHETYPE.definition: |
Root node of the definition of this archetype. |
ARCHETYPE.terminology: |
The terminology of the archetype. |
ARCHETYPE.rules: |
Rules relating to this archetype. Statements are expressed in first order predicate logic, and usually refer to at least two attributes. |
ARCHETYPE.rm_overlay: |
|
AUTHORED_RESOURCE.uid: |
Unique identifier of the family of archetypes having the same interface identifier (same major version). |
AUTHORED_RESOURCE.original_language: |
Language in which this resource was initially authored. Although there is no language primacy of resources overall, the language of original authoring is required to ensure natural language translations can preserve quality. Language is relevant in both the description and ontology sections. |
AUTHORED_RESOURCE.description: |
Description and lifecycle information of the resource. |
AUTHORED_RESOURCE.is_controlled: |
True if this resource is under any kind of change control (even file copying), in which case revision history is created. |
AUTHORED_RESOURCE.annotations: |
Annotations on individual items within the resource, keyed by path. The inner table takes the form of a Hash table of String values keyed by String tags. |
AUTHORED_RESOURCE.translations: |
List of details for each natural translation made of this resource, keyed by language code. For each translation listed here, there must be corresponding sections in all language-dependent parts of the resource. The |
adl_version: |
ADL version if archetype was read in from an ADL sharable archetype. |
build_uid: |
Unique identifier of this archetype artefact instance. A new identifier is assigned every time the content is changed by a tool. Used by tools to distinguish different revisions and/or interim snapshots of the same artefact. |
rm_release: |
Semver.org compatible release of the most recent reference model release on which the archetype in its current version is based. This does not imply conformance only to this release, since an archetype may be valid with respect to multiple releases of a reference model. |
is_generated: |
If True, indicates that this artefact was machine-generated from some other source, in which case, tools would expect to overwrite this artefact on a new generation. Editing tools should set this value to False when a user starts to manually edit an archetype. |
Functions |
|
ARCHETYPE.concept_code (): |
The concept code of the root object of the archetype, also standing for the concept of the archetype as a whole. |
Set of language-independent paths extracted from archetype. Paths obey Xpath-like syntax and are formed from alternations of |
|
ARCHETYPE.logical_paths ( |
Set of language-dependent paths extracted from archetype. Paths obey the same syntax as physical_paths, but with node_ids replaced by their meanings from the terminology. |
ARCHETYPE.specialisation_depth (): |
Specialisation depth of this archetype; larger than 0 if this archetype has a parent. Derived from terminology.specialisation_depth. |
ARCHETYPE.is_specialised (): |
True if this archetype is a specialisation of another. |
AUTHORED_RESOURCE.current_revision (): |
Most recent revision in revision_history if is_controlled else (uncontrolled) . |
AUTHORED_RESOURCE.languages_available (): |
Total list of languages available in this resource, derived from original_language and translations. |
Invariants |
|
ARCHETYPE.Invariant_concept_valid: |
|
ARCHETYPE.Invariant_specialisation_validity: |
|
AUTHORED_RESOURCE.Original_language_valid: |
|
AUTHORED_RESOURCE.Current_revision_valid: |
|
AUTHORED_RESOURCE.Translations_valid: |
|
AUTHORED_RESOURCE.Description_valid: |
|
AUTHORED_RESOURCE.Languages_available_valid: |
|
AUTHORED_RESOURCE.Revision_history_valid: |
|
Invariant_adl_version_validity: |
|
Invariant_rm_release: |
|
Description_validity: |
|
{
"name": "AUTHORED_ARCHETYPE",
"documentation": "Root object of a standalone, authored archetype, including all meta-data, description, other identifiers and lifecycle.",
"ancestors": [
"ARCHETYPE",
"AUTHORED_RESOURCE"
],
"properties": {
"adl_version": {
"_type": "P_BMM_SINGLE_PROPERTY",
"name": "adl_version",
"documentation": "ADL version if archetype was read in from an ADL sharable archetype.",
"type": "String"
},
"build_uid": {
"_type": "P_BMM_SINGLE_PROPERTY",
"name": "build_uid",
"documentation": "Unique identifier of this archetype artefact instance. A new identifier is assigned every time the content is changed by a tool. Used by tools to distinguish different revisions and/or interim snapshots of the same artefact.",
"is_mandatory": true,
"type": "UUID"
},
"rm_release": {
"_type": "P_BMM_SINGLE_PROPERTY",
"name": "rm_release",
"documentation": "Semver.org compatible release of the most recent reference model release on which the archetype in its current version is based. This does not imply conformance only to this release, since an archetype may be valid with respect to multiple releases of a reference model.",
"is_mandatory": true,
"type": "String"
},
"is_generated": {
"_type": "P_BMM_SINGLE_PROPERTY",
"name": "is_generated",
"documentation": "If True, indicates that this artefact was machine-generated from some other source, in which case, tools would expect to overwrite this artefact on a new generation. Editing tools should set this value to False when a user starts to manually edit an archetype.",
"is_mandatory": true,
"type": "Boolean"
},
"other_meta_data": {
"_type": "P_BMM_GENERIC_PROPERTY",
"name": "other_meta_data",
"is_mandatory": true,
"type_def": {
"root_type": "Hash",
"generic_parameters": [
"String",
"String"
]
}
}
},
"invariants": {
"Invariant_adl_version_validity": "valid_version_id (adl_version)",
"Invariant_rm_release": "valid_version_id (rm_release)",
"Description_validity": "description /= Void"
}
}ARCHETYPE_HRID Class
-
Definition
-
Effective
-
BMM
-
UML
Class |
ARCHETYPE_HRID |
|
|---|---|---|
Description |
Human-readable structured identifier (HRID) for an archetype or template. |
|
Attributes |
Signature |
Meaning |
0..1 |
namespace: |
Reverse domain name namespace identifier. |
1..1 |
rm_publisher: |
Name of the Reference Model publisher. |
1..1 |
rm_package: |
Name of the package in whose reachability graph the |
1..1 |
rm_class: |
Name of the root class of this archetype. |
1..1 |
concept_id: |
The short concept name of the archetype as used in the multi-axial |
1..1 |
release_version: |
The full numeric version of this archetype consisting of 3 parts, e.g. |
1..1 |
version_status: |
The status of the version, i.e.:
|
1..1 |
build_count: |
The build count since last increment of any version part. |
Functions |
Signature |
Meaning |
1..1 |
semantic_id (): |
The 'interface' form of the HRID, i.e. down to the major version. |
1..1 |
physical_id (): |
The 'physical' form of the HRID, i.e. with complete version information specified by |
1..1 |
version_id (): |
Full version identifier string, based on |
1..1 |
major_version (): |
Major version of this archetype, extracted from |
1..1 |
minor_version (): |
Minor version of this archetype, extracted from |
1..1 |
patch_version (): |
Patch version of this archetype, extracted from |
Invariants |
Inv_rm_publisher_validity: |
|
Inv_rm_package_validity: |
||
Inv_class_name_validity: |
||
Inv_concept_id_validity: |
||
Inv_release_version_validity: |
||
| ARCHETYPE_HRID | |
|---|---|
Human-readable structured identifier (HRID) for an archetype or template. |
|
Attributes |
|
namespace: |
Reverse domain name namespace identifier. |
rm_publisher: |
Name of the Reference Model publisher. |
rm_package: |
Name of the package in whose reachability graph the |
rm_class: |
Name of the root class of this archetype. |
concept_id: |
The short concept name of the archetype as used in the multi-axial |
release_version: |
The full numeric version of this archetype consisting of 3 parts, e.g. |
version_status: |
The status of the version, i.e.:
|
build_count: |
The build count since last increment of any version part. |
Functions |
|
semantic_id (): |
The 'interface' form of the HRID, i.e. down to the major version. |
physical_id (): |
The 'physical' form of the HRID, i.e. with complete version information specified by |
version_id (): |
Full version identifier string, based on |
major_version (): |
Major version of this archetype, extracted from |
minor_version (): |
Minor version of this archetype, extracted from |
patch_version (): |
Patch version of this archetype, extracted from |
Invariants |
|
Inv_rm_publisher_validity: |
|
Inv_rm_package_validity: |
|
Inv_class_name_validity: |
|
Inv_concept_id_validity: |
|
Inv_release_version_validity: |
|
{
"name": "ARCHETYPE_HRID",
"documentation": "Human-readable structured identifier (HRID) for an archetype or template.",
"properties": {
"namespace": {
"_type": "P_BMM_SINGLE_PROPERTY",
"name": "namespace",
"documentation": "Reverse domain name namespace identifier.",
"type": "String"
},
"rm_publisher": {
"_type": "P_BMM_SINGLE_PROPERTY",
"name": "rm_publisher",
"documentation": "Name of the Reference Model publisher.",
"is_mandatory": true,
"type": "String"
},
"rm_package": {
"_type": "P_BMM_SINGLE_PROPERTY",
"name": "rm_package",
"documentation": "Name of the package in whose reachability graph the `_rm_class_` class is found (there can be more than one possibility in many reference models).",
"is_mandatory": true,
"type": "String"
},
"rm_class": {
"_type": "P_BMM_SINGLE_PROPERTY",
"name": "rm_class",
"documentation": "Name of the root class of this archetype.",
"is_mandatory": true,
"type": "String"
},
"concept_id": {
"_type": "P_BMM_SINGLE_PROPERTY",
"name": "concept_id",
"documentation": "The short concept name of the archetype as used in the multi-axial `_archetype_hrid_`.",
"is_mandatory": true,
"type": "String"
},
"release_version": {
"_type": "P_BMM_SINGLE_PROPERTY",
"name": "release_version",
"documentation": "The full numeric version of this archetype consisting of 3 parts, e.g. `\"1.8.2\"`. The `_archetype_hrid_` feature includes only the major version.",
"is_mandatory": true,
"type": "String"
},
"version_status": {
"_type": "P_BMM_SINGLE_PROPERTY",
"name": "version_status",
"documentation": "The status of the version, i.e.:\n\n* released: (empty string)\n* release_candidate: `\"rc\"`\n* alpha: `\"alpha\"`\n* beta: `\"beta\"`",
"is_mandatory": true,
"type": "VERSION_STATUS"
},
"build_count": {
"_type": "P_BMM_SINGLE_PROPERTY",
"name": "build_count",
"documentation": "The build count since last increment of any version part.",
"is_mandatory": true,
"type": "String"
}
},
"functions": {
"semantic_id": {
"name": "semantic_id",
"documentation": "The 'interface' form of the HRID, i.e. down to the major version.",
"result": {
"_type": "P_BMM_SIMPLE_TYPE",
"type": "String"
}
},
"physical_id": {
"name": "physical_id",
"documentation": "The 'physical' form of the HRID, i.e. with complete version information specified by `_version_id()_`.",
"result": {
"_type": "P_BMM_SIMPLE_TYPE",
"type": "String"
}
},
"version_id": {
"name": "version_id",
"documentation": "Full version identifier string, based on `_release_version_`, `_version_status_`, and `_build_count_` e.g. `\"1.8.2-rc.4\"`.",
"result": {
"_type": "P_BMM_SIMPLE_TYPE",
"type": "String"
}
},
"major_version": {
"name": "major_version",
"documentation": "Major version of this archetype, extracted from `_release_version_`.",
"result": {
"_type": "P_BMM_SIMPLE_TYPE",
"type": "String"
}
},
"minor_version": {
"name": "minor_version",
"documentation": "Minor version of this archetype, extracted from `_release_version_`.",
"result": {
"_type": "P_BMM_SIMPLE_TYPE",
"type": "String"
}
},
"patch_version": {
"name": "patch_version",
"documentation": "Patch version of this archetype, extracted from `_release_version_`. Equivalent to patch version in patch version in `semver.org` sytem.",
"result": {
"_type": "P_BMM_SIMPLE_TYPE",
"type": "String"
}
}
},
"invariants": {
"Inv_rm_publisher_validity": "not rm_publisher.is_empty",
"Inv_rm_package_validity": "not rm_package.is_empty",
"Inv_class_name_validity": "not rm_class.is_empty",
"Inv_concept_id_validity": "not concept_id.is_empty",
"Inv_release_version_validity": "valid_version (release_version)"
}
}TEMPLATE Class
-
Definition
-
Effective
-
BMM
-
UML
Class |
TEMPLATE |
|
|---|---|---|
Description |
Class representing source template, i.e. a kind of archetype that may include template overlays, and may be restricted by tools to only defining mandations, prohibitions, and restrictions on elements already defined in the flat parent. |
|
Inherit |
||
Attributes |
Signature |
Meaning |
0..1 |
overlays: |
Overlay archetypes, i.e. partial archetypes that include full definition and terminology, but logically derive all their meta-data from the owning template. |
Invariants |
Inv_is_specialised: |
|
| TEMPLATE | |
|---|---|
Class representing source template, i.e. a kind of archetype that may include template overlays, and may be restricted by tools to only defining mandations, prohibitions, and restrictions on elements already defined in the flat parent. |
|
Inherits: ARCHETYPE, AUTHORED_RESOURCE, AUTHORED_ARCHETYPE |
|
Attributes |
|
Archetype reference of the specialisation parent of this archetype, if applicable. May take the form of an archetype interface identifier, i.e. the identifier up to the major version only, or may be a full archetype identifier. |
|
ARCHETYPE.archetype_id: |
Identifier of this archetype. |
Flag indicating whether this archetype is differential or flat in its contents. Top-level source archetypes have this flag set to True. |
|
ARCHETYPE.definition: |
Root node of the definition of this archetype. |
ARCHETYPE.terminology: |
The terminology of the archetype. |
ARCHETYPE.rules: |
Rules relating to this archetype. Statements are expressed in first order predicate logic, and usually refer to at least two attributes. |
ARCHETYPE.rm_overlay: |
|
AUTHORED_RESOURCE.uid: |
Unique identifier of the family of archetypes having the same interface identifier (same major version). |
AUTHORED_RESOURCE.original_language: |
Language in which this resource was initially authored. Although there is no language primacy of resources overall, the language of original authoring is required to ensure natural language translations can preserve quality. Language is relevant in both the description and ontology sections. |
AUTHORED_RESOURCE.description: |
Description and lifecycle information of the resource. |
AUTHORED_RESOURCE.is_controlled: |
True if this resource is under any kind of change control (even file copying), in which case revision history is created. |
AUTHORED_RESOURCE.annotations: |
Annotations on individual items within the resource, keyed by path. The inner table takes the form of a Hash table of String values keyed by String tags. |
AUTHORED_RESOURCE.translations: |
List of details for each natural translation made of this resource, keyed by language code. For each translation listed here, there must be corresponding sections in all language-dependent parts of the resource. The |
AUTHORED_ARCHETYPE.adl_version: |
ADL version if archetype was read in from an ADL sharable archetype. |
AUTHORED_ARCHETYPE.build_uid: |
Unique identifier of this archetype artefact instance. A new identifier is assigned every time the content is changed by a tool. Used by tools to distinguish different revisions and/or interim snapshots of the same artefact. |
AUTHORED_ARCHETYPE.rm_release: |
Semver.org compatible release of the most recent reference model release on which the archetype in its current version is based. This does not imply conformance only to this release, since an archetype may be valid with respect to multiple releases of a reference model. |
AUTHORED_ARCHETYPE.is_generated: |
If True, indicates that this artefact was machine-generated from some other source, in which case, tools would expect to overwrite this artefact on a new generation. Editing tools should set this value to False when a user starts to manually edit an archetype. |
AUTHORED_ARCHETYPE.other_meta_data: |
|
overlays: |
Overlay archetypes, i.e. partial archetypes that include full definition and terminology, but logically derive all their meta-data from the owning template. |
Functions |
|
ARCHETYPE.concept_code (): |
The concept code of the root object of the archetype, also standing for the concept of the archetype as a whole. |
Set of language-independent paths extracted from archetype. Paths obey Xpath-like syntax and are formed from alternations of |
|
ARCHETYPE.logical_paths ( |
Set of language-dependent paths extracted from archetype. Paths obey the same syntax as physical_paths, but with node_ids replaced by their meanings from the terminology. |
ARCHETYPE.specialisation_depth (): |
Specialisation depth of this archetype; larger than 0 if this archetype has a parent. Derived from terminology.specialisation_depth. |
ARCHETYPE.is_specialised (): |
True if this archetype is a specialisation of another. |
AUTHORED_RESOURCE.current_revision (): |
Most recent revision in revision_history if is_controlled else (uncontrolled) . |
AUTHORED_RESOURCE.languages_available (): |
Total list of languages available in this resource, derived from original_language and translations. |
Invariants |
|
ARCHETYPE.Invariant_concept_valid: |
|
ARCHETYPE.Invariant_specialisation_validity: |
|
AUTHORED_RESOURCE.Original_language_valid: |
|
AUTHORED_RESOURCE.Current_revision_valid: |
|
AUTHORED_RESOURCE.Translations_valid: |
|
AUTHORED_RESOURCE.Description_valid: |
|
AUTHORED_RESOURCE.Languages_available_valid: |
|
AUTHORED_RESOURCE.Revision_history_valid: |
|
AUTHORED_ARCHETYPE.Invariant_adl_version_validity: |
|
AUTHORED_ARCHETYPE.Invariant_rm_release: |
|
AUTHORED_ARCHETYPE.Description_validity: |
|
Inv_is_specialised: |
|
{
"name": "TEMPLATE",
"documentation": "Class representing source template, i.e. a kind of archetype that may include template overlays, and may be restricted by tools to only defining mandations, prohibitions, and restrictions on elements already defined in the flat parent.",
"ancestors": [
"AUTHORED_ARCHETYPE"
],
"properties": {
"overlays": {
"_type": "P_BMM_CONTAINER_PROPERTY",
"name": "overlays",
"documentation": "Overlay archetypes, i.e. partial archetypes that include full definition and terminology, but logically derive all their meta-data from the owning template.",
"type_def": {
"container_type": "List",
"type": "TEMPLATE_OVERLAY"
},
"cardinality": {
"lower": 0,
"upper_unbounded": true
}
}
},
"invariants": {
"Inv_is_specialised": "is_specialised"
}
}TEMPLATE_OVERLAY Class
-
Definition
-
Effective
-
BMM
-
UML
Class |
TEMPLATE_OVERLAY |
|
|---|---|---|
Description |
A concrete form of the bare |
|
Inherit |
||
Invariants |
Inv_is_specialised: |
|
| TEMPLATE_OVERLAY | |
|---|---|
A concrete form of the bare |
|
Inherits: ARCHETYPE |
|
Attributes |
|
Archetype reference of the specialisation parent of this archetype, if applicable. May take the form of an archetype interface identifier, i.e. the identifier up to the major version only, or may be a full archetype identifier. |
|
ARCHETYPE.archetype_id: |
Identifier of this archetype. |
Flag indicating whether this archetype is differential or flat in its contents. Top-level source archetypes have this flag set to True. |
|
ARCHETYPE.definition: |
Root node of the definition of this archetype. |
ARCHETYPE.terminology: |
The terminology of the archetype. |
ARCHETYPE.rules: |
Rules relating to this archetype. Statements are expressed in first order predicate logic, and usually refer to at least two attributes. |
ARCHETYPE.rm_overlay: |
|
Functions |
|
ARCHETYPE.concept_code (): |
The concept code of the root object of the archetype, also standing for the concept of the archetype as a whole. |
Set of language-independent paths extracted from archetype. Paths obey Xpath-like syntax and are formed from alternations of |
|
ARCHETYPE.logical_paths ( |
Set of language-dependent paths extracted from archetype. Paths obey the same syntax as physical_paths, but with node_ids replaced by their meanings from the terminology. |
ARCHETYPE.specialisation_depth (): |
Specialisation depth of this archetype; larger than 0 if this archetype has a parent. Derived from terminology.specialisation_depth. |
ARCHETYPE.is_specialised (): |
True if this archetype is a specialisation of another. |
Invariants |
|
ARCHETYPE.Invariant_concept_valid: |
|
ARCHETYPE.Invariant_specialisation_validity: |
|
Inv_is_specialised: |
|
{
"name": "TEMPLATE_OVERLAY",
"documentation": "A concrete form of the bare `ARCHETYPE` class, used to represent overlays in a source template. Overlays have no meta-data of their own, and are instead documented by their owning template.",
"ancestors": [
"ARCHETYPE"
],
"invariants": {
"Inv_is_specialised": "is_specialised"
}
}OPERATIONAL_TEMPLATE Class
-
Definition
-
Effective
-
BMM
-
UML
Class |
OPERATIONAL_TEMPLATE |
|
|---|---|---|
Description |
Root object of an operational template. An operational template is derived from a An operational template is used for generating and validating RM-canonical instance data, and also as a source artefact for generating other downstream technical artefacts, including XML schemas, APIs and UI form definitions. |
|
Inherit |
||
Attributes |
Signature |
Meaning |
0..1 |
component_terminologies: |
Compendium of flattened terminologies of archetypes referenced from this template, keyed by archetype identifier. This will almost always be present in a template. |
0..1 |
terminology_extracts: |
Compendium of flattened terminology extracts (i.e. from external terminologies) from archetypes referenced from this template, keyed by archetype identifier. |
Functions |
Signature |
Meaning |
1..1 |
component_terminology ( |
|
Invariants |
Specialisation_validity: |
|
| OPERATIONAL_TEMPLATE | |
|---|---|
Root object of an operational template. An operational template is derived from a An operational template is used for generating and validating RM-canonical instance data, and also as a source artefact for generating other downstream technical artefacts, including XML schemas, APIs and UI form definitions. |
|
Inherits: ARCHETYPE, AUTHORED_RESOURCE, AUTHORED_ARCHETYPE |
|
Attributes |
|
Archetype reference of the specialisation parent of this archetype, if applicable. May take the form of an archetype interface identifier, i.e. the identifier up to the major version only, or may be a full archetype identifier. |
|
ARCHETYPE.archetype_id: |
Identifier of this archetype. |
Flag indicating whether this archetype is differential or flat in its contents. Top-level source archetypes have this flag set to True. |
|
ARCHETYPE.definition: |
Root node of the definition of this archetype. |
ARCHETYPE.terminology: |
The terminology of the archetype. |
ARCHETYPE.rules: |
Rules relating to this archetype. Statements are expressed in first order predicate logic, and usually refer to at least two attributes. |
ARCHETYPE.rm_overlay: |
|
AUTHORED_RESOURCE.uid: |
Unique identifier of the family of archetypes having the same interface identifier (same major version). |
AUTHORED_RESOURCE.original_language: |
Language in which this resource was initially authored. Although there is no language primacy of resources overall, the language of original authoring is required to ensure natural language translations can preserve quality. Language is relevant in both the description and ontology sections. |
AUTHORED_RESOURCE.description: |
Description and lifecycle information of the resource. |
AUTHORED_RESOURCE.is_controlled: |
True if this resource is under any kind of change control (even file copying), in which case revision history is created. |
AUTHORED_RESOURCE.annotations: |
Annotations on individual items within the resource, keyed by path. The inner table takes the form of a Hash table of String values keyed by String tags. |
AUTHORED_RESOURCE.translations: |
List of details for each natural translation made of this resource, keyed by language code. For each translation listed here, there must be corresponding sections in all language-dependent parts of the resource. The |
AUTHORED_ARCHETYPE.adl_version: |
ADL version if archetype was read in from an ADL sharable archetype. |
AUTHORED_ARCHETYPE.build_uid: |
Unique identifier of this archetype artefact instance. A new identifier is assigned every time the content is changed by a tool. Used by tools to distinguish different revisions and/or interim snapshots of the same artefact. |
AUTHORED_ARCHETYPE.rm_release: |
Semver.org compatible release of the most recent reference model release on which the archetype in its current version is based. This does not imply conformance only to this release, since an archetype may be valid with respect to multiple releases of a reference model. |
AUTHORED_ARCHETYPE.is_generated: |
If True, indicates that this artefact was machine-generated from some other source, in which case, tools would expect to overwrite this artefact on a new generation. Editing tools should set this value to False when a user starts to manually edit an archetype. |
AUTHORED_ARCHETYPE.other_meta_data: |
|
component_terminologies: |
Compendium of flattened terminologies of archetypes referenced from this template, keyed by archetype identifier. This will almost always be present in a template. |
terminology_extracts: |
Compendium of flattened terminology extracts (i.e. from external terminologies) from archetypes referenced from this template, keyed by archetype identifier. |
Functions |
|
ARCHETYPE.concept_code (): |
The concept code of the root object of the archetype, also standing for the concept of the archetype as a whole. |
Set of language-independent paths extracted from archetype. Paths obey Xpath-like syntax and are formed from alternations of |
|
ARCHETYPE.logical_paths ( |
Set of language-dependent paths extracted from archetype. Paths obey the same syntax as physical_paths, but with node_ids replaced by their meanings from the terminology. |
ARCHETYPE.specialisation_depth (): |
Specialisation depth of this archetype; larger than 0 if this archetype has a parent. Derived from terminology.specialisation_depth. |
ARCHETYPE.is_specialised (): |
True if this archetype is a specialisation of another. |
AUTHORED_RESOURCE.current_revision (): |
Most recent revision in revision_history if is_controlled else (uncontrolled) . |
AUTHORED_RESOURCE.languages_available (): |
Total list of languages available in this resource, derived from original_language and translations. |
component_terminology ( |
|
Invariants |
|
ARCHETYPE.Invariant_concept_valid: |
|
ARCHETYPE.Invariant_specialisation_validity: |
|
AUTHORED_RESOURCE.Original_language_valid: |
|
AUTHORED_RESOURCE.Current_revision_valid: |
|
AUTHORED_RESOURCE.Translations_valid: |
|
AUTHORED_RESOURCE.Description_valid: |
|
AUTHORED_RESOURCE.Languages_available_valid: |
|
AUTHORED_RESOURCE.Revision_history_valid: |
|
AUTHORED_ARCHETYPE.Invariant_adl_version_validity: |
|
AUTHORED_ARCHETYPE.Invariant_rm_release: |
|
AUTHORED_ARCHETYPE.Description_validity: |
|
Specialisation_validity: |
|
{
"name": "OPERATIONAL_TEMPLATE",
"documentation": "Root object of an operational template. An operational template is derived from a `TEMPLATE` definition and the `ARCHETYPEs` and/or `TEMPLATE_OVERLAYs` mentioned by that template by a process of flattening, and potentially removal of unneeded languages and terminologies.\n\nAn operational template is used for generating and validating RM-canonical instance data, and also as a source artefact for generating other downstream technical artefacts, including XML schemas, APIs and UI form definitions.",
"ancestors": [
"AUTHORED_ARCHETYPE"
],
"properties": {
"component_terminologies": {
"_type": "P_BMM_GENERIC_PROPERTY",
"name": "component_terminologies",
"documentation": "Compendium of flattened terminologies of archetypes referenced from this template, keyed by archetype identifier. This will almost always be present in a template.",
"type_def": {
"root_type": "Hash",
"generic_parameters": [
"String",
"ARCHETYPE_TERMINOLOGY"
]
}
},
"terminology_extracts": {
"_type": "P_BMM_GENERIC_PROPERTY",
"name": "terminology_extracts",
"documentation": "Compendium of flattened terminology extracts (i.e. from external terminologies) from archetypes referenced from this template, keyed by archetype identifier.",
"type_def": {
"root_type": "Hash",
"generic_parameters": [
"String",
"ARCHETYPE_TERMINOLOGY"
]
}
}
},
"functions": {
"component_terminology": {
"name": "component_terminology",
"parameters": {
"an_id": {
"_type": "P_BMM_SINGLE_FUNCTION_PARAMETER",
"name": "an_id",
"type": "String"
}
},
"post_conditions": {
"Inv_is_specialised": "is_specialised"
},
"result": {
"_type": "P_BMM_SIMPLE_TYPE",
"type": "ARCHETYPE_TERMINOLOGY"
}
}
},
"invariants": {
"Specialisation_validity": "is_specialised"
}
}Validity Rules
The following validity rules apply to all varieties of ARCHETYPE object:
VARAV: ADL version validity. The adl_version top-level meta-data item must exist and consist of a valid 3-part version identifier.
VARRV: RM release validity. The rm_release top-level meta-data item must exist and consist of a valid 3-part version identifier.
VARCN: archetype concept validity. For at-coded definitions: the node_id of the root object of the archetype must be of the form at0000{.1}*, where the number of .1 components equals the specialisation depth, and must be defined in the terminology.
For id-coded definitions: the node_id of the root object of the archetype must be of the form id1{.1}*, where the number of .1 components equals the specalisation depth, and must be defined in the terminology.
VATDF: value code validity. Each value code (at-code) used in a term constraint in the archetype definition must be defined in the term_definitions part of the terminology of the flattened form of the current archetype.
VACDF: constraint code validity. Each value set code (ac-code) used in a term constraint in the archetype definition must be defined in the term_definitions part of the terminology of the current archetype.
VATDA: value set assumed value code validity. Each value code (at-code) used as an assumed_value for a value set in a term constraint in the archetype definition must exist in the value set definition in the terminology for the identified value set.
VETDF: external term validity. Each external term used within the archetype definition must exist in the relevant terminology (subject to tool accessibility; codes for inaccessible terminologies should be flagged with a warning indicating that no verification was possible).
VOTM: terminology translations validity. Translations must exist for term_definitions and constraint_definitions sections for all languages defined in the description / translations sections.
VOKU: object key unique. Within any keyed list in an archetype, including the desription, terminology, and annotations sections, each item must have a unique key with respect to its siblings.
VARDT: archetype definition typename validity. The typename mentioned in the outer block of the archetype definition section must match the type mentioned in the first segment of the archetype id.
VRANP: annotation path valid. Each path mentioned in an annotation within the annotations section must either be a valid archetype path, or a 'reference model' path, i.e. a path that is valid for the root class of the archetype.
VRRLP: rule path valid. Each path mentioned in a rule in the rules section must be found within the archetype, or be an RM-valid extension of a path found within the archetype.
The following validity rules apply to instances of ARCHETYPE and subtypes other than TEMPLATE_OVERLAY:
VARID: archetype identifier validity. The archetype must have an identifier that conforms to the openEHR specification for archetype identifiers.
VDEOL: original language specified. An original_language section containing the meta-data of the original authoring language must exist.
VARD: description specified. A description section containing the main meta-data of the archetype must exist.
The following rules apply to specialised archetypes, for which ARCHETYPE.is_specialised returns True.
VASID: archetype specialisation parent identifier validity. The archetype identifier stated in the specialise clause must be the identifier of the immediate specialisation parent archetype.
VALC: archetype language conformance. The languages defined in a specialised archetype must be the same as or a subset of those defined in the flat parent.
VACSD: archetype concept specialisation depth. The specialisation depth of the archetypes must be one greater than the specialisation depth of the parent archetype.
VATCD: archetype code specialisation level validity. Each archetype term ('at' code) and constraint code ('ac' code) used in the archetype definition section must have a specialisation level no greater than the specialisation level of the archetype.
The following validity rules apply to instances of TEMPLATE:
VTPL: template and filler language consistency. All fillers of slots and external reference archetypes (i.e. 'use_archetype' inclusions) must contain the original_language of the root template in their languages, in order for template flattening to be successful.