Changes between Version 3 and Version 4 of Archtectural Overview Archetypes

Timestamp:

Oct 1, 2007, 8:00:22 PM (17 years ago)

Author:

Tatsukawa, Akimichi

Comment:

--

Archtectural Overview Archetypes

@@ -67 +67 @@
 Archetypes are extensible formal constraint definitions of object structures. In common with object model classes, they can be specialised, as well as composed (i.e. aggregated). Specialised archetypes are created when an archetype is already available for the content that needs to be modelled, but it lacks detail or is too general. For example, the archetype openEHR-EHR-OBSERVATION.laboratory.v1 contains generic concepts of `specimen', `diagnostic service', a single result of any type, and a two-level result battery for grouped results. This archetype could be (and has been) used to represent nearly any kind of laboratory result data. However, specialisations such as openEHR-EHR-OBSERVATION.laboratory-glucose.v1 are extremely useful, and can be easily defined based on the predecessor; in this case, the single result node is redefined to be `blood glucose'. The formal rule for specialisation is that:
 
-    * a specialised archetype can only further narrow existing constraints in the parent (but it may add its own). 
+    * a specialised archetype can only further narrow existing constraints in the parent (but it may add its own).
+ 
+この効果として、特化したアーキタイプによって生成されたデータは親アーキタイプを基盤としたクエリーに常にマッチする。換言すれば、臨床検査という観察項目 `laboratory' Observations に対するクエリーは血糖値という観察項目`glucose' Observations の情報を正しく取得することになる。この仕組みはオントロジーにおける包含関係という基本的な原理に合致する。この包含関係の原理は、BとAが意味論的にIS-A関係に立つときにはBという型のインスタンスは同時にAという型のインスタンスでもあることを意味する。特化したアーキタイプは、親アーキタイプの識別子と下位要素の識別子を`-'でつなげた識別子によって表現される。
 
 This has the effect that the data created with any specialised archetype will always be matched by queries based on the parent archetype - in other words, a query for `laboratory' Observations will correctly retrieve `glucose' Observations as well. This accords with the basic ontological principle of subsumption, which says that instances of a type B are also instances of type A, where type B is related to type A by the semantic relationship `IS-A'. Specialised archetypes are indicated by the use of an identifier derived from the parent archetype, with a new sub-element of the semantic part of the identifier, separated by a `-' character.
 
 The second relationship possible between archetypes is composition, allowing large data structures to be flexibly constrained via the hierarchical re-use of smaller archetypes. Composition is defined in terms of `slots' within an archetype. A slot is a point in an archetype structure where, instead of specifying an object type inline, a special allow_archetype constraint is used to specify other archetypes constraining that same type, that may be used at that point. For example, the archetype openEHR-EHR-SECTION.vital_signs.v1 defines a heading structure for headings to do with vital signs. It also defines as its items attribute value (i.e. what comes under the heading) a number of possible Observations; however, rather than defining these inline, it specifies an archetype slot in the form of constraints on Observation archetypes that are allowed at that point. The simplest kind of constraint is in terms of regular expressions on archetype identifiers. More complex constraints can be stated in terms of paths in other archetypes (for example exists(/some/path[at0005])). A slot thus defines a `chaining point' in terms of possible archetypes allowed or excluded at that point; limiting this to a single archetype is of course possible. Templates are used to choose which particular archetypes allowed at a slot will actually be used in a given circumstance.
+
 10.3 Relationship of Archetypes and Templates to Data