Changes between Version 11 and Version 12 of Archtectural Overview Paths


Ignore:
Timestamp:
Aug 16, 2008, 5:16:57 PM (16 years ago)
Author:
KOBAYASHI, Shinji
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • Archtectural Overview Paths

    v11 v12  
     1[wiki:"Archtectural Overview index" TOC] [wiki:"Archtectural Overview Archetypes" PREV] [wiki:"Archtectural Overview Terminology" NEXT] [[TOC]] この文書は[http://svn.openehr.org/specification/TAGS/Release-1.0.1/publishing/html/architecture/overview/Output/front.html Archtectural Overview]の[http://www.openehr.org/svn/specification/TAGS/Release-1.0.1/publishing/html/architecture/overview/Output/paths_and_locators.html Paths and Locators]の翻訳である。正確性については保証しないので，適宜原文を参照すること
     2
     3= 11 パスとロケーター =
     411 Paths and Locators
     5
     6== 11.1 概要 == #overview
     711.1 Overview
     8
     9openEHRのアーキテクチャにはパスのメカニズムが含まれており、これにより最上位構造内のいかなるノードも、"セマンティックな"(すなわちアーキタイプ・ベースの)XPath互換パスを用いて、構造の最上位から特定していくことができる。このようなパスが利用可能であることは、健康情報に対する検索の可能性を根底から変えるものであり、openEHRの主要な特徴的な機構のひとつとなっている。
     10
     11The openEHR architecture includes a path mechanism that enables any node within a top level structure to be specified from the top of the structure using a "semantic" (i.e. archetype-based) X-path compatible path. The availability of such paths radically changes the available querying possibilities with health information, and is one of the major distinguishing features of openEHR.
     12
     13技術的には、パスとOBJECT_VERSION_IDのようなバージョン識別子の組合わせによって、LOCATABLE_REFを用いて表現可能な"グローバルに認識可能なノードのリファレンス"といったものが形成される。それは"グローバルに認識可能なノードのロケーター"として知られるDV_EHR_URIとして、可搬性のあるURI形式でも表現可能である。どちらの表現方式でも、あらゆるopenEHRデータ・ノードは、どこからでも参照可能となる。この章では、パスと参照のためのURI形式についての構文とセマンティクスを記述する。下記において、"アーキタイプ・パス"という用語はアーキタイプから抽出されたパスを意味し、"データ・パス"とはデータ中の要素を特定するパスを意味するものとする。両者に形式上の差異はなく、このターミノロジーはそれらがどこで用いられるかを指し示すためだけに使用される。
     14
     15Technically, the combination of a path and a Version identifier such as OBJECT_VERSION_ID forms a "globally qualified node reference" which can be expressed using LOCATABLE_REF. It can also be expressed in portable URI form as a DV_EHR_URI, known as a "globally qualified node locator". Either representation enables any openEHR data node to be referred to from anywhere. This section describes the syntax and semantics of paths, and of the URI form of reference. In the following, the term "archetype path" means a path extracted from an archetype, while "data path" means one that identifies an item in data. They are no different formally, and this terminology is only used to indicate where they are used.
     16
     17== 11.2 パス == #path
     1811.2 Paths
     19
     20=== 11.2.1 基本文法 === #syntax
     2111.2.1 Basic Syntax
     22
     23openEHRにおけるパスは、XPath[[FootNote(W3C Xpath 1.0 specification, 1999参照（http://www.w3.org/TR/xpath にて利用可能))]]互換の文法で定義され、これはアーキタイプ定義言語(Archetype Definition Language, ADL)に記載されたパス文法のスーパーセットとなっている。この文法はXPath表現に容易にマッピングできるよう設計されており、openEHRベースのXMLとともに使用できる。
     24
     25Paths in openEHR are defined in an Xpath1-compatible syntax which is a superset of the path syntax described in the Archetype Definition Language (ADL). The syntax is designed to be easily mappable to Xpath expressions, for use with openEHR-based XML.
     26
     27ロケーター表現におけるデータ・パス文法は、属性名(attribute_ name[[FootNote(すべてのopenEHRのドキュメントにおいて、"属性(attribute)"という用語はオブジェクト指向における"オブジェクトのプロパティ"の意味で用いられている。XMLにおけるタグ中に現れる名前の値を意味しない。ここで記述された構文は、XMLインスタンスへの字義通りのマッピングを必ずしも考慮に入れたものではなく、むしろオブジェクト指向のデータ構造への論理的なマッピングが考慮されている。)]])の各構成要素をセグメントとするパスの一般表記を並べ、スラッシュ(`/') 文字で分割する。すなわち、
     28
     29attribute_name / attribute_name / ... / attribute_name
     30
     31The data path syntax used in locator expressions follows the general pattern of a path consisting of segments each consisting of an attribute name2, and separated by the slash (`/') character, i.e.:
     32
     33attribute_name / attribute_name / ... / attribute_name
     34
     35パスは、ツリー中の何らかの先頭ポイントから開始され、パス中に与えられる属性名をたどり、パス中の最後の属性名の値をもつオブジェクトを選択する。先頭ポイントはパスの最初の部分で示され、2つの方法で特定されうる。  ·        相対パスは属性名で始まり、先頭ポイントはツリー中のカレント・ポイントである。(直前の操作もしくはナレッジによって与えられる）  ·        絶対パスは`/'で始まり、先頭ポイントは構造の最上位である。
     36
     37Paths select the object which is the value of the final attribute name in the path, when going from some starting point in the tree and following attribute names given in the path. The starting point is indicated by the initial part of the path, and can be specified in two ways:  ·        relative path: path starts with an attribute name, and the starting point is the current point in the tree (given by some previous operation or knowledge);  ·        absolute path: path starts with a `/'; the starting point is the top of the structure.
     38
     39さらに、XPathからの"//" 表記が、パス・パターンを定義するために用いられる。  ·        パス・パターンパスは`//' 表現から開始され、またはこれを含み、データ中の任意の数のパス・セグメントに相当するパターンとして取り扱われる。このパターンは、`//' に先立つパス・セクションがパスの部分にマッチし、`//'以降に現れるセクションが後半のセクションにマッチするならば、構造中のいかなる部分においても実際のパスにマッチさせることができる。
     40
     41In addition, the "//" notation from Xpath can be used to define a path pattern:  ·        path pattern: path starts with or contains a the symbol `//' and is taken to be a pattern which can match any number of path segments in the data; the pattern is matched if an actual path can be found anywhere in the structure for which part of the path matches the path section before the `//' symbol, and a later section matches the section appearing after the `//'.
     42
     43=== 11.2.2 述語表現 === #predicate
     4411.2.2 Predicate Expressions
     45
     46==== 概要 ====
     47Overview
     48
     49属性名のみで記述されるパスには、2つの制約事項がある。1番目は、リストや集合等のコンテナを持たない構造中のオブジェクトのロケーションだけしか表現できないことである。だが、openEHRのたいていのデータを含め、あらゆる現実のデータはリストや集合やハッシュ構造を持つのが普通である。コンテナ属性によって兄弟オブジェクトの中から特定のものを参照可能とするために、追加の構文が必要となる。この場合、セグメントの関係する属性の後ろに角括弧(`[ ]')で囲んだ述語表現の形式を用いる。すなわち、
     50
     51attribute_name [述語表現]
     52
     53Paths specified solely with attribute names are limited in two ways. Firstly, they can only locate objects in structures in which there are no containers such as lists or sets. However, in any realistic data, including most openEHR data, list, set and hash structures are common. Additional syntax is needed to match a particular object from among the siblings referred to by a container attribute. This takes the form of a predicate expression enclosed in brackets (`[]') after the relevant attribute in a segment, i.e.:
     54
     55attribute_name [predicate expression]
     56
     57パスの一般形式は、それゆえ以下のようになる。
     58
     59attribute_name / attribute_name [述語表現] / ...
     60
     61The general form of a path then resembles the following:
     62
     63attribute_name / attribute_name [predicate expression] / ...
     64
     65ここでは、述語表現は、リファレンス・モデルにおいてコンテナ型(すなわち1より大きな基数を持つ）であるものとして定義される属性に対してオプションとして使用される。あるコンテナ属性に対して述語表現を使用しない場合は、全コンテナが選択される。述語表現は単一の値を取る属性に対してもしばしば使用されうること、及び、技術的には使用可能(例えば、汎用のパス処理ソフトウェアがこの差異を無視する場合）であっても、必須ではないことに注意せよ。
     66
     67Here, predicate expressions are used optionally on those attributes defined in the reference model to be of a container type (i.e. having a cardinality of > 1). If a predicate expression is not used on a container attribute, the whole container is selected. Note that predicate expressions are often possible even on single-valued attributes, and technically can be used (e.g. if generic path-processing software can't tell the difference) but are not required.
     68
     69基本パスの2番目の制約事項は、特定の値を取る子ノードを持つオブジェクトといった、外部条件に基づくオブジェクトのロケーションを表現できないことである。これに対処するため、述語表現によって当該オブジェクトに関する外部条件に基づくオブジェクトの選択が可能であり、これにはパス、演算子、値及び括弧を含む論理値表現を含めることができる。opneEHRで用いられる述語表現の構文は、述語のためのXPathの構文のサブセットであり、いくつかの省略形が含まれる。
     70
     71The second limitation of basic paths is that they cannot locate objects based on other conditions, such as the object having a child node with a particular value. To address this, predicate expressions can be used to select an object on the basis of other conditions relative to the object, by including boolean expressions including paths, operators, values and parentheses. The syntax of predicate expressions used in openEHR is a subset of the Xpath syntax for predicates with a small number of short-cuts.
     72
     73==== アーキタイプと述語 ====
     74Archetype path Predicate
     75
     76最も重要な述語は、CLUSTER内のある種のELEMENTのようなコンテナからの戻り値に制約をかけるために、archetype_node_id 値(LOCATABLEから継承したもの)を用いる。省略形式では、たとえば[at0003]といったアーキタイプ・コードを述語として含めることが許される。この省略形は、ランタイム・データに対してアーキタイプ・パスを用いることに相当する。典型的なアーキタイプ派生パスは、以下のようなものである。(Observationのインスタンスに適用される）
     77
     78/data/events[at0003]/data/items[at0025]/value/magnitude
     79
     80The most important predicate uses the archetype_node_id value (inherited from LOCATABLE) to limit the items returned from a container, such as to certain ELEMENTs within a CLUSTER. The shortcut form allows the archetype code to be included on its own as the predicate, e.g. [at0003]. This shortcut corresponds to using an archetype path against the runtime data. A typical archetype-derived path is the following (applied to an Observation instance):
     81
     82/data/events[at0003]/data/items[at0025]/value/magnitude
     83
     84このパスは、全アプガー評価の内容を構造として持つObservationから、出生後1分のアプガー指数の値を参照するものである。このパスでは、述語[atNNNN] は、XPath標準による[@archetype_node_id = `atNNNN'] の省略形になっている。アーキタイプ・パスは、アーキタイプにおいては常に一意なものであるが、ランタイム・データにおいては、コンテナ内での同一のアーキタイプ・ノードの反復使用によって1つ以上の要素に対応できることに注意せよ。
     85
     86This path refers to the magnitude of a 1-minute Apgar total in an Observation containing a full Apgar result structure. In this path, the [atNNNN] predicates are a shortcut for [@archetype_node_id = `atNNNN'] in standard Xpath. Note that while an archetype path is always unique in an archetype, it can correspond to more than one item in runtime data, due to the repeated use of the same archetype node within a container.
     87
     88==== 名前に基づく述語 ====
     89Name-based Predicate
     90
     91一意性を保証されたデータ・パスを生成するために、述語には、archetype_node_id 値と同様にname値(これもLOCATABLEから継承されたもの)を含めることができる。この表現のための標準XPath形式を、以下に例示する。
     92
     93/data/events[at0001 and name/value=`standing']
     94
     95In order to create a guaranteed unique data path, predicates can also include the name value (also inherited from LOCATABLE) as well as the archetype_node_id value. The standard Xpath form of this expression is exemplified by the following:
     96
     97/data/events[at0001 and name/value=`standing']
     98
     99アーキタイプ・ノードの識別子とname値との組合わせはアーキタイプ・データベースにおいてごく一般的であるため、name/value表現についても省略形が利用可能である。それは下記のように、単にコンマの後に値を含めればよい。
     100
     101/data/events[at0001, `standing']
     102
     103Since the combination of an archetype node identifier and a name value is very common in archetyped databases, a shortcut is also available for the name/value expression, which is to simply include the value after a comma as follows:
     104
     105/data/events[at0001, `standing']
     106
     107==== その他の述語 ====
     108Other Predicates
     109
     110以上の他にも、ELEMENT.name or EVENT.time といったその他の属性の値に基づく述語が使用できる。archetype_node_id とこれらの値の組合わせは検索に際してよく用いられる。例えば以下のようなパス断片のように(OBSERVATIONインスタンスへの適用例)
     111
     112/data/events[at0007 AND time >= "24-06-2005 09:30:00"]
     113
     114Other predicates can be used, based on the value of other attributes such as ELEMENT.name or EVENT.time. Combinations of the archetype_node_id and other such values are commonly used in querying, such as the following path fragment (applied to an OBSERVATION instance):
     115
     116/data/events[at0007 AND time >= "24-06-2005 09:30:00"]
     117
     118このパスは、would choose Events in Observation.data whose archetype_node_id が"サマリー・イベント" (あるアーキタイプにおいてat0007) であり、かつ与えられた時刻と同時またはそれ以降に発生したObservation.data 中のEventを選択する。下記の例では、"その他の細菌性腸管感染症"(ICD10コードA04)という診断(at0002.1)を含むEvaluationが選択されるであろう。
     119
     120/data/items[at0002.1
     121
     122  AND         value/defining_code/terminology_id/value = "ICD10AM"
     123
     124  AND value/defining_code/code_string = "A04"]
     125
     126 This path would choose Events in Observation.data whose archetype_node_id meaning is "summary event" (at0007 in some archetype) and which occurred at or after the given time. The following example would choose an Evaluation containing a diagnosis (at0002.1) of "other bacterial intestinal infections" (ICD10 code A04):
     127
     128/data/items[at0002.1
     129
     130  AND         value/defining_code/terminology_id/value = "ICD10AM"
     131
     132  AND value/defining_code/code_string = "A04"]
     133
     134=== 11.2.3 最上位構造におけるパス === #top_level
     13511.2.3 Paths within Top-level Structures
     136
     137最上位構造内のパスは、リファレンス・モデルの関係部分における属性や関数名と厳格に結びついている。述語表現は、これらの構造中のパスにおけるさまざまなポイント、とりわけアーキタイプが「チェーンしている」ポイントにおいて、多数の兄弟関係にあたるものを区別するために必要である。チェーン・ポイントとは、図30に図示されるように、あるアーキタイプが他のアーキタイプを引き継ぐ場所である。COMPOSITION内部におけるチェーン・ポイントは、COMPOSITIONとひとつのSECTION構造との間、そしておそらくは（異なるSECTIONアーキタイプによって強制されて)ひとつのSECTION構造と他のサブSECTION構造との間、さらにはCOMPOSITIONかSECTION構造のいずれかとENTRYとの間に発生する。Item_list等の下位レベルの構造でアーキタイプが用いられる場合には、チェーンはENTRY内部でも生じ得る。大抵のチェーン・ポイントは、List<T>のようなコンテナ型に相応している。たとえば、COMPOSITION.content はList<CONTENT_ITEM>として定義され、実データにおいてCOMPOSITIONのコンテンツがSECTION構造のリストであり得るということを意味する。このような兄弟構造を区別するために、述語表現がarchetype_idに基づいて使用されるのである。データ中のあるアーキタイプのルート・ポイント(たとえばSECTION構造の最上位)において、archetype_idはその構造を生成するために用いられたアーキタイプの識別子を保持するが、それはアーキタイプ構造内のあらゆる内部ポイントがアーキタイプのnode_idの値を保持するarchetype_node_id属性を持っていることと同様である。SECTIONとENTRY間のチェーン・ポイントも同様に作用する。単一のSECTION下で多数のENTRYが発生し得ることから、archetype_id述語はこれらを区別するためにも用いられる。archetype_node_idのためにarchetype_id述語表現による同様の簡略表記が用いられる。すなわち、[@archetype_id = "xxxxx"]と書く代わりに、[xxxx]と記述できる。
     138
     139Paths within top-level structures strictly adhere to attribute and function names in the relevant parts of the reference model. Predicate expressions are needed to distinguish multiple siblings in various points in paths into these structures, but particularly at archetype "chaining" points. A chaining point is where one archetype takes over from another as illustrated in FIGURE 30. Chaining points in Compositions occur between the Composition and a Section structure, potentially between a Section structure and other sub-Section structures (constrained by a different Section archetype), and between either Compositions or Section structures, and Entries. Chaining might also occur inside an Entry, if archetyping is used on lower level structures such as Item_lists etc. Most chaining points correspond to container types such as List<T> etc., e.g. COMPOSITION.content is defined to be a List<CONTENT_ITEM>, meaning that in real data, the content of a Composition could be a List of Section structures. To distinguish between such sibling structures, predicate expressions are used, based on the archetype_id. At the root point of an archetype in data (e.g. top of a Section structure), the archetype_id carries the identifier of the archetype used to create that structure, in the same manner as any interior point in an archetyped structure has an archetype_node_id attribute carrying archetype node_id values. The chaining point between Sections and Entries works in the same manner, and since multiple Entries can occur under a single Section, archetype_id predicates are also used to distinguish them. The same shorthand is used for archetype_id predicate expressions as for archetype_node_ids, i.e. instead of using [@archetype_id = "xxxxx"], [xxxx] can be used instead.
     140
     141以下のパスは、COMPOSITION内で項目を参照する例である。
     142
     143The following paths are examples of referring to items within a Composition:
     144
     145/content[openEHR-EHR-SECTION.vital_signs.v1 and name/value='Vital signs']/
     146
     147  items[openEHR-EHR-OBSERVATION.heart_rate-pulse.v1 and name/value='Pulse']/
     148
     149  data/events[at0003 and name/value='Any event']/data/items[at1005]
     150
     151 /content[openEHR-EHR-SECTION.vital_signs.v1 and name/value='Vital signs']/
     152
     153  items[openEHR-EHR-OBSERVATION.blood_pressure.v1 and
     154
     155  name/value='Blood pressure']/data/events[at0006 and name/value='any event']/
     156
     157  data/items[at0004]
     158
     159 /content[openEHR-EHR-SECTION.vital_signs.v1, 'Vital signs']/
     160
     161  items[openEHR-EHR-OBSERVATION.blood_pressure.v1, 'Blood pressure']/
     162
     163  data/events[at0006, 'any event']/data/items[at0005]
     164
     165他の最上位タイプ内のパスも、同様の一般的なアプローチでたどることができる。すなわち、必要な属性を階層構造に沿ってたどることで生成される。    Paths within the other top level types follow the same general approach, i.e. are created by following the required attributes down the hierarchy.
     166
     167=== 11.2.4 データ・パスと一意性 === #uniqueness
     16811.2.4 Data Paths and Uniqueness
     169
     170ひとつのアーキタイプ・ノードがデータ中の多数のインスタンスに対応し得るものであるという事実があるために、アーキタイプ・パスは、データ中で一意に識別される項目であるという保証はない。だが、実データ中で一意の項目であるようなパスを構築することは、しばしば必要となる。このことはパス述語においてarchetype_node_ide以外の属性を用いることによって可能となる。以下のOBSERVATIONアーキタイプを例として考察してみよう。   Archetype paths are not guaranteed to uniquely identify items in data, due to the fact that one archetype node may correspond to multiple instances in the data. However it is often necessary to be able to construct a unique path to an item in real data. This can be done by using attributes other than archetype_node_id in path predicates. Consider as an example the following OBSERVATION archetype:
     171
     172OBSERVATION[at0000] matches {                                                           -- blood pressure measurement
     173
     174  data matches {
     175
     176  HISTORY matches {
     177
     178  events {1..*} matches {
     179
     180  EVENT[at0006] {0..1}  matches {                                                                -- any event
     181
     182  name matches {DV_TEXT                         matches {...}}
     183
     184  data matches {
     185
     186  ITEM_LIST[at0003] matches {                                                -- systemic arterial BP
     187
     188  count matches {2..*}
     189
     190  items matches {
     191
     192  ELEMENT[at0004] matches {                        -- systolic BP
     193
     194  name matches {DV_TEXT                         matches {...}}
     195
     196  value matches {magnitude matches {...}}
     197
     198  }
     199
     200  ELEMENT[at0005] matches {                        -- diastolic BP
     201
     202  name matches {DV_TEXT                         matches {...}}
     203
     204  value matches {magnitude matches {...}}
     205
     206  }
     207
     208  }
     209
     210  }
     211
     212  }
     213
     214  }
     215
     216  }
     217
     218  }
     219
     220このアーキタイプから抽出された以下のパスは、収縮期血圧値を参照するものである。
     221
     222The following path extracted from the archetype refers to the systolic blood pressure magnitude:
     223
     224/data/events[at0006]/data/items[at0004]/value/magnitude
     225
     226アーキタイプの各ノードの[atnnnn]というコードが、データ中の各ノードで見られるarchetype_node_idとなる。
     227
     228The codes [atnnnn] at each node of the archetype become the archetype_node_ids found in each node in the data.
     229
     230さてここで、このアーキタイプを用いて2つの血圧の履歴が記録されているOBSERVATIONインスタンス(ここではdADL形式で表現される)について考察しよう。
     231
     232Now consider an OBSERVATION instance (expressed here in dADL format), in which a history of two blood pressures has been recorded using this archetype:
     233
     234<        -- OBSERVATION - blood pressure measurement
     235
     236  archetype_node_id = <[openEHR-EHR-OBSERVATION.blood_pressure.v1]>
     237
     238  name = <value = <"BP measurement">>
     239
     240  data = <                                                                        -- HISTORY
     241
     242  archetype_node_id = <[at0001]>
     243
     244  origin = <2005-12-03T09:22:00>
     245
     246  events = <                                                                        -- List <EVENT>
     247
     248  ![1]         = <                                                                -- EVENT
     249
     250  archetype_node_id = <[at0006]>
     251
     252  name = <value = <"sitting">>
     253
     254  time = <2005-12-03T09:22:00>
     255
     256  data = <                                                                        -- ITEM_LIST
     257
     258  archetype_node_id = <[at0003]>
     259
     260  items = <                                                                -- List<ELEMENT>
     261
     262  ![1]         = <
     263
     264  name = <value = <"systolic">>
     265
     266  archetype_node_id = <[at0004]>
     267
     268  value = <magnitude = <120.0> ...>
     269
     270
     271  ![2]         = <....
     272
     273  name = <value = <"diastolic">>
     274
     275  archetype_node_id = <[at0005]>
     276
     277  value = <magnitude = <80.0> ...>
     278
     279
     280
     281
     282
     283  ![2]         = <                                                                -- EVENT
     284
     285  archetype_node_id = <[at0006]>
     286
     287  name = <value = <"standing">>
     288
     289  time = <2005-12-03T09:27:00>
     290
     291  data = <                                                                        -- ITEM_LIST
     292
     293  archetype_node_id = <[at0003]>
     294
     295  items = <                                                                -- List<ELEMENT>
     296
     297  [1]         = <
     298
     299  name = <value = <"systolic">>
     300
     301  archetype_node_id = <[at0004]>
     302
     303  value = <magnitude = <105.0> ...>
     304
     305
     306  ![2]         = <
     307
     308  name = <value = <"diastolic">>
     309
     310  archetype_node_id = <[at0005]>
     311
     312  value = <magnitude = <70.0> ...>
     313
     314
     315
     316
     317
     318
     319
     320[注記: 上記の例において、名前の値はすべてDV_TEXTであるものとして示しているが、実際のopenEHRではDV_CODE_TEXTインスタンスであることが多い。どちらもアーキタイプによって許容される。これは例示のサイズを縮小するためであり、下記に示すパスとなんら異なるものではない。]   [Note: in the above example, name values are shown as if they were all DV_TEXTs, whereas in reality in openEHR they more likely to be DV_CODED_TEXT instances; either is allowed by the archetype. This has been done to reduce the size of the example, and makes no difference to the paths shown below].
     321
     322上述のアーキタイプ・パスは、記録に含まれる両収縮期血圧のいずれにも適合する。多くの検索場面において、これこそが正に求められるものである。だが、収縮期血圧の各ノードに一意に適合させるためには、パスはarchetype_node_idのみならず他の属性にも基づいて生成されなければならない。上記のケースでは、name属性が一意性を提供する。各イベント(座位及び立位での計測)ごとの収縮期及び拡張期血圧に関する一意性が保証されたパスは、下記の表現によって可能となる。（XPathと全く同一である)[[FootNote(attr[1]という表記は、Xpathでのattr[position() = 1]の簡略形である。)]]
     323
     324The archetype path mentioned above matches both systolic pressures in the recording. In many querying situations, this may be exactly what is desired. However, to uniquely match each of the systolic pressure nodes, paths need to be created that are based not only on the archetype_node_id but also on another attribute. In the case above, the name attribute provides uniqueness. Guaranteed unique paths to the systolic and diastolic pressures of each event (sitting and standing measurements) are available using the following expressions (identical in Xpath)3:
     325
     326/data/events![1]/data/items![1]/value/magnitude   /data/events![1]/data/items![2]/value/magnitude   /data/events![2]/data/items![1]/value/magnitude   /data/events![2]/data/items![2]/value/magnitude
     327
     328アーキタイプ・パスに基づいて、さらに表現力のある一意のパスも可能である。たとえば、
     329
     330More expressive unique paths based on archetype paths are also possible, as follows:
     331
     332/data/events[at0006, `sitting']/data/items[at0004]/value/magnitude   /data/events[at0006, `sitting']/data/items[at0005]/value/magnitude   /data/events[at0006, `standing']/data/items[at0004]/value/magnitude   /data/events[at0006, `standing']/data/items[at0005]/value/magnitude   これらのパス
     333
     334
     335はそれぞれXPathと等しい以下の形式を持っている。
     336
     337Each of these paths has an Xpath equivalent of the following form:
     338
     339/data/events[@archetype_node_id=`at0006' and name/value=`standing']
     340
     341  /data/items[@archetype_node_id=`at0004']
     342
     343  /value/magnitude
     344
     345一般規則として、ランタイム・データにおけるひとつまたは複数の他の属性値によって、openEHRデータにおけるいかなるノードでも一意に識別させることができるであろう。一意のパスをより容易に構築するためには、name属性(LOCATABLEクラスから継承したもの) の値が、兄弟ノードのname値に対して一意であることが要請される。このことは以下の2点に帰着する。
     346
     347 * 一意性が保証されたパスは、(上記のパスの例で示したように)archetype_node_idとname値との組合わせを用いることによって、openEHRデータ中のいかなるデータに対しても常に構築することが可能である。
     348 * name値は、ひとつまたは複数の属性値のコピーとしてシステマティックに定義することも可能であろう。たとえば、あるEVENTオブジェクトにおいて、nameはtime属性を文字列としてコピーしたものとすることが明らかに可能である。
     349
     350 As a general rule, one or more other attribute values in the runtime data will uniquely identify any node in openEHR data. To make construction of unique paths easier, the value of the name attribute (inherited from the LOCATABLE class), is required to be unique with respect to the name values of sibling nodes. This has two consequences as follows:
     351
     352 * a guaranteed unique path can always be constructed to any data item in openEHR data using a combination of archetype_node_id and name values (as shown in the example paths above);
     353 * the name value may be systematically defined to be a copy of one or more other attribute values. For example, in an EVENT object, name could clearly be a string copy of the time attribute.
     354
     355== 11.3 EHR URI == #uri
     35611.3 EHR URIs
     357
     358あらゆるリソースに使用可能なURIとして、直接参照と検索の2つの大きなカテゴリーがある。最初の種類は、通常参照されるべき項目を含むシステムによって生成され、定義された参照情報として他のシステムに渡される。一方、2つ目のものは、要求側のシステムからURI形式によって行われるクエリである。
     359
     360There are two broad categories of URIs that can be used with any resource: direct references, and queries. The first kind are usually generated by the system containing the referred-to item, and passed to other systems as definitive references, while the second are queries from the requesting system in the form of a URI.
     361
     362=== 11.3.1 EHR参照URI === #reference
     36311.3.1 EHR Reference URIs
     364
     365EHR内のノードへのURI(uniform resource identifier)形式での参照を生成するためには、最上位構造内のパス、EHR内での最上位構造への参照、そしてEHRへの参照という、3つの要素が必要となる。これらは、以下の構文に従って、"ehr"スキーマ空間内でURI形式に組合わされる。
     366
     367To create a reference to a node in an EHR in the form of a URI (uniform resource identifier), three elements are needed: the path within a top-level structure, a reference to a top-level structure within an EHR, and a reference to an EHR. These can be combined to form a URI in an "ehr" scheme-space, obeying the following syntax:
     368
     369!ehr://ehr_locator/top_level_structure_locator/path_inside_top_level_structure
     370
     371このようにして、あらゆるopenEHR EHRのあらゆるオブジェクトは、URIを通じてアドレス可能となる。ehr空間内では、特定のサーバーやホスト等に対するURLスタイルでの参照は、長期間にわたる信頼性が得られないために、用いられない。その代わり、EHR及び／または患者に対する論理的な識別子が用いられ、参照しようとしているリソースのライフタイムにわたってURIが正しく存続することを担保している。openEHRのデータ型であるDV_EHR_URIは、この形式のURIを格納するために設計され、URIがLINK内及びopenEHR EHR内の他の場所で用いられるべく構築されることを実現している。
     372
     373In this way, any object in any openEHR EHR is addressable via a URI. Within ehr-space, URL-style references to particular servers, hosts etc are not used, due to not being reliable in the long term. Instead, logical identifiers for EHRs and/or subjects are used, ensuring that URIs remain correct for the lifetime of the resources to which they refer. The openEHR data type DV_EHR_URI is designed to carry URIs of this form, enabling URIs to be constructed for use within LINKs and elsewhere in the openEHR EHR.
     374
     375!ehr:// というURIは、ehr空間内での名前解決のメカニズムが使用できることを意味している。これは、http-、ftp-及びその他のウェル・ノウンURIスキーマに対してそのようなサービスを提供するDNSと同様である。このようなサービスが確立されるまでは、!ehr:// URIの取り扱いには、より伝統的な!http://スタイルの参照と同じように、アドホックな手段が使用されていたと思われる。以下のサブセクションでは、両方の種類のURIがどのように構築されるかを記述する。
     376
     377An !ehr:// URI implies the availability of a name resolution mechanism in ehr-space, similar to the DNS, which provides such services for http-, ftp- and other well-known URI schemes. Until such services are established, ad hoc means of dealing with !ehr:// URIs are likely to be used, as well as more traditional http:// style references. The subsections below describe how URIs of both kinds can be constructed.
     378
     379==== EHRロケーション ====
     380EHR Location
     381
     382ehr空間では、EHRに対する直接のロケーターは、患者の識別子やクエリとは明確に区別されるEHR識別子である。通常は要求される対象は'ローカル・システム'内のコピーであり、大多数の場合は、それが実在する唯一のものであると思われる。このケースでは、要求されるEHRは、以下の形式のURIで与えられるような、修飾子のない識別子によって単純に識別できる。
     383
     384In ehr-space, a direct locator for an EHR is an EHR identifier as distinct from a subject or patient identifier or query. Normally the copy in the `local system' is the one required, and a majority of the time, may be the only one in existence. In this case, the required EHR can be identified simply by an unqualified identifier, giving a URI of the form:
     385
     386!ehr://1234567/
     387
     388だが、患者のEHRは多数のEHRシステム間でコピーされ同期されるために、与えられたEHR識別子がひとつ以上のロケーションに存在する場合がある。 部分コピーが許容されているため、このようなEHRのそれぞれが他と完全に一致するコピーであるという保証はない。それゆえに、EHRのコピーが存在する環境で、どのEHRのインスタンスが要求されているかを正確に識別することを要する場合には、以下の形式のURIで与えられるような体系的な識別子も必要となる。
     389
     390However, due to copying / synchronising of the EHR for one subject among multiple EHR systems, a given EHR identifier may exist at more than one location. It is not guaranteed that each such EHR is a completely identical copy of the others, since partial copying is allowed. Therefore, in an environment where EHR copies exist, and there is a need to identify exactly which EHR instance is required, an system identifier is also required, giving a URI of the form:
     391
     392!ehr://1234567@rmh.nhs.net/
     393
     394==== 最上位構造のロケーター ====
     395 Top-level Structure Locator
     396
     397openEHR EHRにおける最上位構造を識別するためには、論理的に2つの方法がある。1番目のものは、要求された最上位オブジェクトの識別子とバージョン・時刻(すなわち'system'または'commit time')の組合わせによるものである。前者は、関係するVERSIONED_OBJECTのuidを用いる方法や、アーキタイプ識別子または名前による方法を含む、いくつかの方法で行うことができる。これによればURIは以下のようになる。
     398
     399There are two logical ways to identify a top-level structure in an openEHR EHR. The first is via the combination of the identifier of the required top-level object and the version time (i.e. `system' or `commit' time). The former can be done in a number of ways, including via the use of the uid of the relevant VERSIONED_OBJECT, or via archetype identifiers, or names. This would lead to URIs like the following:
     400
     401!ehr://1234567/87284370-2D4B-4e3d-A3F3-F303D2F4F34B@latest_trunk_version -- a VO Guid   !ehr://1234567/87284370-2D4B-4e3d-A3F3-F303D2F4F34B@2005-08-02T04:30:00 -- using time
     402
     403最上位構造を識別する2番目の方法は、正確なバージョン識別子を用いる方法である。すなわち、version_object_uid::version_tree_id::creating_system_idという形式をとるopenEHR標準のバージョン識別子である。この場合は、URIは以下のようになる。
     404
     405The second way to identify a top-level structure is by using an exact Version identifier, i.e. the standard openEHR Version identifier, which takes the form version_object_uid::version_tree_id::creating_system_id. This leads to URIs like the following:
     406
     407!ehr://1234567/87284370-2D4B-4e3d-A3F3-F303D2F4F34B::rmh.nhs.net:2
     408
     409!ehr://1234567/87284370-2D4B-4e3d-A3F3-F303D2F4F34B::F7C5C7B7-75DB-4b39-9A1E-C0BA9BFDBDEC:2
     410
     4111番目のURIは、バージョン識別子が87284370-2D4B-4e3d-A3F3-F303D2F4F34B::rmh.nhs.net:2である、すなわち、net.nhs.rmhとして識別されるEHRにおいて生成され、GUIDで識別されるバージョン付きオブジェクトの2番目の主要バージョンである最上位項目を識別する。2番目も同様であるが、別のGUIDが生成システムを識別するために用いられている。バージョン識別子によるシステムへの言及は、要求されたEHRがそのシステムであることを意味するものではなく、単に探索された最上位オブジェクトがそのシステムで生成されたことを意味することに注意されたい。
     412
     413The first URI identifies a top-level item whose version identifier is 87284370-2D4B-4e3d-A3F3-F303D2F4F34B::rmh.nhs.net:2, i.e. the second trunk version of the Versioned Object indentified by the Guid, created at an EHR system identified by net.nhs.rmh. The second is the same, but another Guid is used to identify the creating system as well. Note that the mention of a system in the version identifier does not imply that the requested EHR is at that system, only that the top-level object being sought was created at that system.
     414
     415もしバージョン識別子への言及がなければ、常に'latest_trunk_version'であるものと想定される。以下の通り。
     416
     417If no Version identifier is mentioned, `latest_trunk_version' is always assumed, as per the following:
     418
     419!ehr://1234567/87284370-2D4B-4e3d-A3F3-F303D2F4F34B
     420
     421==== 項目のURI ====
     422Item URIs
     423
     424先に記述したパス表現への追加を用いて、URIはopenEHR EHRの最小粒度の項目への参照を構築することができる。たとえば以下のように。
     425
     426With the addition of path expressions as described earlier, URIs can be constructed that refer to the finest grained items in the openEHR EHR, such as the following:
     427
     428ehr://1234567/87284370-2D4B-4e3d-A3F3-F303D2F4F34B@latest_trunk_version/
     429
     430  content[openEHR-EHR-SECTION.vital_signs.v1]/
     431
     432  items[openEHR-EHR-OBSERVATION.heart_rate-pulse.v1]/data/
     433
     434  events[at0006, 'any event']/data/items[at0004]
     435
     436==== 相対URI ====
     437Relative URIs
     438
     439URIは、カレントのEHRに対して相対的に構築することもでき、このケースではEHR idに言及することはない。以下に例を示す。
     440
     441URIs can also be constructed relative to the current EHR, in which case they do not mention the EHR id, as in the following example:   ehr:///87284370-2D4B-4e3d-A3F3-F303D2F4F34B@latest_version/
     442
     443  content[openEHR-EHR-SECTION.vital_signs.v1]/
     444
     445  items[openEHR-EHR-OBSERVATION.blood_pressure.v1]/
     446
     447  data/events[at0006, 'any event']/data/items[at0004]
     448
     449[[FootNote]] 1See W3C Xpath 1.0 specification, 1999. Available at http://www.w3.org/TR/xpath. 2In all openEHR documentation, the term "attribute" is used in the object-oriented sense of "property of an object", not in the XML sense of named values appearing within a tag. The syntax described here should not be considered to necessarily have a literal mapping to XML instance, but rather to have a logical mapping to object-oriented data structures. 3the notation attr[1] is a Xpath shorthand for attr[position() = 1]
     450
    1451[wiki:"Archtectural Overview index" TOC] [wiki:"Archtectural Overview Archetypes" PREV] [wiki:"Archtectural Overview Terminology" NEXT]
    2 [[TOC]]
    3 この文書は[http://svn.openehr.org/specification/TAGS/Release-1.0.1/publishing/html/architecture/overview/Output/front.html Archtectural Overview]の[http://www.openehr.org/svn/specification/TAGS/Release-1.0.1/publishing/html/architecture/overview/Output/archetyping.html 11 Paths and Locators]の翻訳である。正確性については保証しないので，適宜原文を参照すること
    4 
    5 = 11 パスとロケーター =
    6 
    7 11 Paths and Locators
    8 
    9 == 11.1 概要 == #overview
    10 
    11 11.1 Overview
    12 
    13 openEHRのアーキテクチャにはパスのメカニズムが含まれており、これにより最上位構造内のいかなるノードも、"セマンティックな"(すなわちアーキタイプ・ベースの)XPath互換パスを用いて、構造の最上位から特定していくことができる。このようなパスが利用可能であることは、健康情報に対する検索の可能性を根底から変えるものであり、openEHRの主要な特徴的な機構のひとつとなっている。
    14 
    15 The openEHR architecture includes a path mechanism that enables any node within a top level structure to be specified from the top of the structure using a "semantic" (i.e. archetype-based) X-path compatible path. The availability of such paths radically changes the available querying possibilities with health information, and is one of the major distinguishing features of openEHR.
    16 
    17 技術的には、パスとOBJECT_VERSION_IDのようなバージョン識別子の組合わせによって、LOCATABLE_REFを用いて表現可能な"グローバルに認識可能なノードのリファレンス"といったものが形成される。それは"グローバルに認識可能なノードのロケーター"として知られるDV_EHR_URIとして、可搬性のあるURI形式でも表現可能である。どちらの表現方式でも、あらゆるopenEHRデータ・ノードは、どこからでも参照可能となる。この章では、パスと参照のためのURI形式についての構文とセマンティクスを記述する。下記において、"アーキタイプ・パス"という用語はアーキタイプから抽出されたパスを意味し、"データ・パス"とはデータ中の要素を特定するパスを意味するものとする。両者に形式上の差異はなく、このターミノロジーはそれらがどこで用いられるかを指し示すためだけに使用される。
    18 
    19 Technically, the combination of a path and a Version identifier such as OBJECT_VERSION_ID forms a "globally qualified node reference" which can be expressed using LOCATABLE_REF. It can also be expressed in portable URI form as a DV_EHR_URI, known as a "globally qualified node locator". Either representation enables any openEHR data node to be referred to from anywhere. This section describes the syntax and semantics of paths, and of the URI form of reference. In the following, the term "archetype path" means a path extracted from an archetype, while "data path" means one that identifies an item in data. They are no different formally, and this terminology is only used to indicate where they are used.
    20 
    21 == 11.2 パス == #path
    22 
    23 11.2 Paths
    24 
    25 === 11.2.1 基本文法 === #syntax
    26 
    27 11.2.1 Basic Syntax
    28 
    29 openEHRにおけるパスは、XPath[[FootNote(W3C Xpath 1.0 specification, 1999参照（http://www.w3.org/TR/xpath にて利用可能))]]互換の文法で定義され、これはアーキタイプ定義言語(Archetype Definition Language, ADL)に記載されたパス文法のスーパーセットとなっている。この文法はXPath表現に容易にマッピングできるよう設計されており、openEHRベースのXMLとともに使用できる。
    30 
    31 Paths in openEHR are defined in an Xpath1-compatible syntax which is a superset of the path syntax described in the Archetype Definition Language (ADL). The syntax is designed to be easily mappable to Xpath expressions, for use with openEHR-based XML.
    32 
    33 ロケーター表現におけるデータ・パス文法は、属性名(attribute_ name[[FootNote(すべてのopenEHRのドキュメントにおいて、"属性(attribute)"という用語はオブジェクト指向における"オブジェクトのプロパティ"の意味で用いられている。XMLにおけるタグ中に現れる名前の値を意味しない。ここで記述された構文は、XMLインスタンスへの字義通りのマッピングを必ずしも考慮に入れたものではなく、むしろオブジェクト指向のデータ構造への論理的なマッピングが考慮されている。)]])の各構成要素をセグメントとするパスの一般表記を並べ、スラッシュ(`/') 文字で分割する。すなわち、
    34 
    35 attribute_name / attribute_name / ... / attribute_name
    36 
    37 The data path syntax used in locator expressions follows the general pattern of a path consisting of segments each consisting of an attribute name2, and separated by the slash (`/') character, i.e.:
    38 
    39 attribute_name / attribute_name / ... / attribute_name
    40 
    41 パスは、ツリー中の何らかの先頭ポイントから開始され、パス中に与えられる属性名をたどり、パス中の最後の属性名の値をもつオブジェクトを選択する。先頭ポイントはパスの最初の部分で示され、2つの方法で特定されうる。
    42 ·       相対パスは属性名で始まり、先頭ポイントはツリー中のカレント・ポイントである。(直前の操作もしくはナレッジによって与えられる）
    43 ·       絶対パスは`/'で始まり、先頭ポイントは構造の最上位である。
    44 
    45 Paths select the object which is the value of the final attribute name in the path, when going from some starting point in the tree and following attribute names given in the path. The starting point is indicated by the initial part of the path, and can be specified in two ways:
    46 ·       relative path: path starts with an attribute name, and the starting point is the current point in the tree (given by some previous operation or knowledge);
    47 ·       absolute path: path starts with a `/'; the starting point is the top of the structure.
    48 
    49 さらに、XPathからの"//" 表記が、パス・パターンを定義するために用いられる。
    50 ·       パス・パターンパスは`//' 表現から開始され、またはこれを含み、データ中の任意の数のパス・セグメントに相当するパターンとして取り扱われる。このパターンは、`//' に先立つパス・セクションがパスの部分にマッチし、`//'以降に現れるセクションが後半のセクションにマッチするならば、構造中のいかなる部分においても実際のパスにマッチさせることができる。
    51 
    52 In addition, the "//" notation from Xpath can be used to define a path pattern:
    53 ·       path pattern: path starts with or contains a the symbol `//' and is taken to be a pattern which can match any number of path segments in the data; the pattern is matched if an actual path can be found anywhere in the structure for which part of the path matches the path section before the `//' symbol, and a later section matches the section appearing after the `//'.
    54 
    55 === 11.2.2 述語表現 === #predicate
    56 
    57 11.2.2 Predicate Expressions
    58 
    59 ==== 概要 ====
    60 
    61 Overview
    62 
    63 属性名のみで記述されるパスには、2つの制約事項がある。1番目は、リストや集合等のコンテナを持たない構造中のオブジェクトのロケーションだけしか表現できないことである。だが、openEHRのたいていのデータを含め、あらゆる現実のデータはリストや集合やハッシュ構造を持つのが普通である。コンテナ属性によって兄弟オブジェクトの中から特定のものを参照可能とするために、追加の構文が必要となる。この場合、セグメントの関係する属性の後ろに角括弧(`[ ]')で囲んだ述語表現の形式を用いる。すなわち、
    64 
    65 attribute_name [述語表現]
    66 
    67 Paths specified solely with attribute names are limited in two ways. Firstly, they can only locate objects in structures in which there are no containers such as lists or sets. However, in any realistic data, including most openEHR data, list, set and hash structures are common. Additional syntax is needed to match a particular object from among the siblings referred to by a container attribute. This takes the form of a predicate expression enclosed in brackets (`[]') after the relevant attribute in a segment, i.e.:
    68 
    69 attribute_name [predicate expression]
    70 
    71 パスの一般形式は、それゆえ以下のようになる。
    72 
    73 attribute_name / attribute_name [述語表現] / ...
    74 
    75 The general form of a path then resembles the following:
    76 
    77 attribute_name / attribute_name [predicate expression] / ...
    78 
    79 ここでは、述語表現は、リファレンス・モデルにおいてコンテナ型(すなわち1より大きな基数を持つ）であるものとして定義される属性に対してオプションとして使用される。あるコンテナ属性に対して述語表現を使用しない場合は、全コンテナが選択される。述語表現は単一の値を取る属性に対してもしばしば使用されうること、及び、技術的には使用可能(例えば、汎用のパス処理ソフトウェアがこの差異を無視する場合）であっても、必須ではないことに注意せよ。
    80 
    81 Here, predicate expressions are used optionally on those attributes defined in the reference model to be of a container type (i.e. having a cardinality of > 1). If a predicate expression is not used on a container attribute, the whole container is selected. Note that predicate expressions are often possible even on single-valued attributes, and technically can be used (e.g. if generic path-processing software can't tell the difference) but are not required.
    82 
    83 基本パスの2番目の制約事項は、特定の値を取る子ノードを持つオブジェクトといった、外部条件に基づくオブジェクトのロケーションを表現できないことである。これに対処するため、述語表現によって当該オブジェクトに関する外部条件に基づくオブジェクトの選択が可能であり、これにはパス、演算子、値及び括弧を含む論理値表現を含めることができる。opneEHRで用いられる述語表現の構文は、述語のためのXPathの構文のサブセットであり、いくつかの省略形が含まれる。
    84 
    85 The second limitation of basic paths is that they cannot locate objects based on other conditions, such as the object having a child node with a particular value. To address this, predicate expressions can be used to select an object on the basis of other conditions relative to the object, by including boolean expressions including paths, operators, values and parentheses. The syntax of predicate expressions used in openEHR is a subset of the Xpath syntax for predicates with a small number of short-cuts.
    86 
    87 ==== アーキタイプと述語 ====
    88 
    89 Archetype path Predicate
    90 
    91 最も重要な述語は、CLUSTER内のある種のELEMENTのようなコンテナからの戻り値に制約をかけるために、archetype_node_id 値(LOCATABLEから継承したもの)を用いる。省略形式では、たとえば[at0003]といったアーキタイプ・コードを述語として含めることが許される。この省略形は、ランタイム・データに対してアーキタイプ・パスを用いることに相当する。典型的なアーキタイプ派生パスは、以下のようなものである。(Observationのインスタンスに適用される）
    92 
    93 /data/events[at0003]/data/items[at0025]/value/magnitude
    94 
    95 The most important predicate uses the archetype_node_id value (inherited from LOCATABLE) to limit the items returned from a container, such as to certain ELEMENTs within a CLUSTER. The shortcut form allows the archetype code to be included on its own as the predicate, e.g. [at0003]. This shortcut corresponds to using an archetype path against the runtime data. A typical archetype-derived path is the following (applied to an Observation instance):
    96 
    97 /data/events[at0003]/data/items[at0025]/value/magnitude
    98 
    99 このパスは、全アプガー評価の内容を構造として持つObservationから、出生後1分のアプガー指数の値を参照するものである。このパスでは、述語[atNNNN] は、XPath標準による[@archetype_node_id = `atNNNN'] の省略形になっている。アーキタイプ・パスは、アーキタイプにおいては常に一意なものであるが、ランタイム・データにおいては、コンテナ内での同一のアーキタイプ・ノードの反復使用によって1つ以上の要素に対応できることに注意せよ。
    100 
    101 This path refers to the magnitude of a 1-minute Apgar total in an Observation containing a full Apgar result structure. In this path, the [atNNNN] predicates are a shortcut for [@archetype_node_id = `atNNNN'] in standard Xpath. Note that while an archetype path is always unique in an archetype, it can correspond to more than one item in runtime data, due to the repeated use of the same archetype node within a container.
    102 
    103 ==== 名前に基づく述語 ====
    104 
    105 Name-based Predicate
    106 
    107 一意性を保証されたデータ・パスを生成するために、述語には、archetype_node_id 値と同様にname値(これもLOCATABLEから継承されたもの)を含めることができる。この表現のための標準XPath形式を、以下に例示する。
    108 
    109 /data/events[at0001 and name/value=`standing']
    110 
    111 In order to create a guaranteed unique data path, predicates can also include the name value (also inherited from LOCATABLE) as well as the archetype_node_id value. The standard Xpath form of this expression is exemplified by the following:
    112 
    113 /data/events[at0001 and name/value=`standing']
    114 
    115 アーキタイプ・ノードの識別子とname値との組合わせはアーキタイプ・データベースにおいてごく一般的であるため、name/value表現についても省略形が利用可能である。それは下記のように、単にコンマの後に値を含めればよい。
    116 
    117 /data/events[at0001, `standing']
    118 
    119 Since the combination of an archetype node identifier and a name value is very common in archetyped databases, a shortcut is also available for the name/value expression, which is to simply include the value after a comma as follows:
    120 
    121 /data/events[at0001, `standing']
    122 
    123 ==== その他の述語 ====
    124 
    125 Other Predicates
    126 
    127 以上の他にも、ELEMENT.name or EVENT.time といったその他の属性の値に基づく述語が使用できる。archetype_node_id とこれらの値の組合わせは検索に際してよく用いられる。例えば以下のようなパス断片のように(OBSERVATIONインスタンスへの適用例)
    128 
    129 /data/events[at0007 AND time >= "24-06-2005 09:30:00"]
    130 
    131 Other predicates can be used, based on the value of other attributes such as ELEMENT.name or EVENT.time. Combinations of the archetype_node_id and other such values are commonly used in querying, such as the following path fragment (applied to an OBSERVATION instance):
    132 
    133 /data/events[at0007 AND time >= "24-06-2005 09:30:00"]
    134 
    135 このパスは、would choose Events in Observation.data whose archetype_node_id が"サマリー・イベント" (あるアーキタイプにおいてat0007) であり、かつ与えられた時刻と同時またはそれ以降に発生したObservation.data 中のEventを選択する。下記の例では、"その他の細菌性腸管感染症"(ICD10コードA04)という診断(at0002.1)を含むEvaluationが選択されるであろう。
    136 
    137 /data/items[at0002.1
    138  
    139         AND     value/defining_code/terminology_id/value = "ICD10AM"
    140  
    141         AND value/defining_code/code_string = "A04"]
    142  
    143 This path would choose Events in Observation.data whose archetype_node_id meaning is "summary event" (at0007 in some archetype) and which occurred at or after the given time. The following example would choose an Evaluation containing a diagnosis (at0002.1) of "other bacterial intestinal infections" (ICD10 code A04):
    144 
    145 /data/items[at0002.1
    146  
    147         AND     value/defining_code/terminology_id/value = "ICD10AM"
    148  
    149         AND value/defining_code/code_string = "A04"]
    150 
    151 === 11.2.3 最上位構造におけるパス === #top_level
    152 
    153 11.2.3 Paths within Top-level Structures
    154 
    155 最上位構造内のパスは、リファレンス・モデルの関係部分における属性や関数名と厳格に結びついている。述語表現は、これらの構造中のパスにおけるさまざまなポイント、とりわけアーキタイプが「チェーンしている」ポイントにおいて、多数の兄弟関係にあたるものを区別するために必要である。チェーン・ポイントとは、図30に図示されるように、あるアーキタイプが他のアーキタイプを引き継ぐ場所である。COMPOSITION内部におけるチェーン・ポイントは、COMPOSITIONとひとつのSECTION構造との間、そしておそらくは（異なるSECTIONアーキタイプによって強制されて)ひとつのSECTION構造と他のサブSECTION構造との間、さらにはCOMPOSITIONかSECTION構造のいずれかとENTRYとの間に発生する。Item_list等の下位レベルの構造でアーキタイプが用いられる場合には、チェーンはENTRY内部でも生じ得る。大抵のチェーン・ポイントは、List<T>のようなコンテナ型に相応している。たとえば、COMPOSITION.content はList<CONTENT_ITEM>として定義され、実データにおいてCOMPOSITIONのコンテンツがSECTION構造のリストであり得るということを意味する。このような兄弟構造を区別するために、述語表現がarchetype_idに基づいて使用されるのである。データ中のあるアーキタイプのルート・ポイント(たとえばSECTION構造の最上位)において、archetype_idはその構造を生成するために用いられたアーキタイプの識別子を保持するが、それはアーキタイプ構造内のあらゆる内部ポイントがアーキタイプのnode_idの値を保持するarchetype_node_id属性を持っていることと同様である。SECTIONとENTRY間のチェーン・ポイントも同様に作用する。単一のSECTION下で多数のENTRYが発生し得ることから、archetype_id述語はこれらを区別するためにも用いられる。archetype_node_idのためにarchetype_id述語表現による同様の簡略表記が用いられる。すなわち、[@archetype_id = "xxxxx"]と書く代わりに、[xxxx]と記述できる。
    156 
    157 Paths within top-level structures strictly adhere to attribute and function names in the relevant parts of the reference model. Predicate expressions are needed to distinguish multiple siblings in various points in paths into these structures, but particularly at archetype "chaining" points. A chaining point is where one archetype takes over from another as illustrated in FIGURE 30. Chaining points in Compositions occur between the Composition and a Section structure, potentially between a Section structure and other sub-Section structures (constrained by a different Section archetype), and between either Compositions or Section structures, and Entries. Chaining might also occur inside an Entry, if archetyping is used on lower level structures such as Item_lists etc. Most chaining points correspond to container types such as List<T> etc., e.g. COMPOSITION.content is defined to be a List<CONTENT_ITEM>, meaning that in real data, the content of a Composition could be a List of Section structures. To distinguish between such sibling structures, predicate expressions are used, based on the archetype_id. At the root point of an archetype in data (e.g. top of a Section structure), the archetype_id carries the identifier of the archetype used to create that structure, in the same manner as any interior point in an archetyped structure has an archetype_node_id attribute carrying archetype node_id values. The chaining point between Sections and Entries works in the same manner, and since multiple Entries can occur under a single Section, archetype_id predicates are also used to distinguish them. The same shorthand is used for archetype_id predicate expressions as for archetype_node_ids, i.e. instead of using [@archetype_id = "xxxxx"], [xxxx] can be used instead.
    158 
    159 以下のパスは、COMPOSITION内で項目を参照する例である。
    160 
    161 The following paths are examples of referring to items within a Composition:
    162 
    163 /content[openEHR-EHR-SECTION.vital_signs.v1 and name/value='Vital signs']/
    164  
    165         items[openEHR-EHR-OBSERVATION.heart_rate-pulse.v1 and name/value='Pulse']/
    166  
    167         data/events[at0003 and name/value='Any event']/data/items[at1005]
    168  
    169 /content[openEHR-EHR-SECTION.vital_signs.v1 and name/value='Vital signs']/
    170  
    171         items[openEHR-EHR-OBSERVATION.blood_pressure.v1 and
    172  
    173         name/value='Blood pressure']/data/events[at0006 and name/value='any event']/
    174  
    175         data/items[at0004]
    176  
    177 /content[openEHR-EHR-SECTION.vital_signs.v1, 'Vital signs']/
    178  
    179         items[openEHR-EHR-OBSERVATION.blood_pressure.v1, 'Blood pressure']/
    180  
    181         data/events[at0006, 'any event']/data/items[at0005]
    182 
    183 他の最上位タイプ内のパスも、同様の一般的なアプローチでたどることができる。すなわち、必要な属性を階層構造に沿ってたどることで生成される。
    184  
    185 Paths within the other top level types follow the same general approach, i.e. are created by following the required attributes down the hierarchy.
    186 
    187 === 11.2.4 データ・パスと一意性 === #uniqueness
    188 
    189 11.2.4 Data Paths and Uniqueness
    190 
    191 ひとつのアーキタイプ・ノードがデータ中の多数のインスタンスに対応し得るものであるという事実があるために、アーキタイプ・パスは、データ中で一意に識別される項目であるという保証はない。だが、実データ中で一意の項目であるようなパスを構築することは、しばしば必要となる。このことはパス述語においてarchetype_node_ide以外の属性を用いることによって可能となる。以下のOBSERVATIONアーキタイプを例として考察してみよう。
    192  
    193 Archetype paths are not guaranteed to uniquely identify items in data, due to the fact that one archetype node may correspond to multiple instances in the data. However it is often necessary to be able to construct a unique path to an item in real data. This can be done by using attributes other than archetype_node_id in path predicates. Consider as an example the following OBSERVATION archetype:
    194 
    195 OBSERVATION[at0000] matches {                                                           -- blood pressure measurement
    196  
    197         data matches {                 
    198  
    199                 HISTORY matches {                                       
    200  
    201                         events {1..*} matches {         
    202  
    203                                 EVENT[at0006] {0..1}  matches {                                                         -- any event
    204  
    205                                         name matches {DV_TEXT                    matches {...}}
    206  
    207                                         data matches { 
    208  
    209                                                 ITEM_LIST[at0003] matches {                                             -- systemic arterial BP
    210  
    211                                                         count matches {2..*}
    212  
    213                                                         items matches {                         
    214  
    215                                                                 ELEMENT[at0004] matches {                       -- systolic BP
    216  
    217                                                                         name matches {DV_TEXT                    matches {...}}
    218  
    219                                                                         value matches {magnitude matches {...}}
    220  
    221                                                                 }
    222  
    223                                                                 ELEMENT[at0005] matches {                       -- diastolic BP
    224  
    225                                                                         name matches {DV_TEXT                    matches {...}}
    226  
    227                                                                         value matches {magnitude matches {...}}
    228  
    229                                                                 }
    230  
    231                                                         }
    232  
    233                                                 }
    234  
    235                                         }
    236  
    237                                 }
    238  
    239                         }
    240  
    241                 }
    242  
    243 
    244 
    245 このアーキタイプから抽出された以下のパスは、収縮期血圧値を参照するものである。
    246 
    247 The following path extracted from the archetype refers to the systolic blood pressure magnitude:
    248 
    249 /data/events[at0006]/data/items[at0004]/value/magnitude
    250 
    251 アーキタイプの各ノードの[atnnnn]というコードが、データ中の各ノードで見られるarchetype_node_idとなる。
    252 
    253 The codes [atnnnn] at each node of the archetype become the archetype_node_ids found in each node in the data.
    254 
    255 さてここで、このアーキタイプを用いて2つの血圧の履歴が記録されているOBSERVATIONインスタンス(ここではdADL形式で表現される)について考察しよう。
    256 
    257 Now consider an OBSERVATION instance (expressed here in dADL format), in which a history of two blood pressures has been recorded using this archetype:
    258 
    259 <       -- OBSERVATION - blood pressure measurement
    260  
    261         archetype_node_id = <[openEHR-EHR-OBSERVATION.blood_pressure.v1]>
    262  
    263         name = <value = <"BP measurement">>
    264  
    265         data = <                                                                        -- HISTORY     
    266  
    267                 archetype_node_id = <[at0001]>
    268  
    269                 origin = <2005-12-03T09:22:00>
    270  
    271                 events = <                                                                      -- List <EVENT>
    272  
    273                         [1]      = <                                                            -- EVENT
    274  
    275                                 archetype_node_id = <[at0006]>
    276  
    277                                 name = <value = <"sitting">>
    278  
    279                                 time = <2005-12-03T09:22:00>
    280  
    281                                 data = <                                                                        -- ITEM_LIST   
    282  
    283                                         archetype_node_id = <[at0003]>
    284  
    285                                         items = <                                                               -- List<ELEMENT>       
    286  
    287                                                 [1]      = <
    288  
    289                                                         name = <value = <"systolic">>
    290  
    291                                                         archetype_node_id = <[at0004]>
    292  
    293                                                         value = <magnitude = <120.0> ...>
    294  
    295                                                 >
    296  
    297                                                 [2]      = <....
    298  
    299                                                         name = <value = <"diastolic">>
    300  
    301                                                         archetype_node_id = <[at0005]>
    302  
    303                                                         value = <magnitude = <80.0> ...>
    304  
    305                                                 >
    306  
    307                                         >
    308  
    309                                 >
    310  
    311                         >
    312  
    313                         [2]      = <                                                            -- EVENT
    314  
    315                                 archetype_node_id = <[at0006]>
    316  
    317                                 name = <value = <"standing">>
    318  
    319                                 time = <2005-12-03T09:27:00>
    320  
    321                                 data = <                                                                        -- ITEM_LIST   
    322  
    323                                         archetype_node_id = <[at0003]>
    324  
    325                                         items = <                                                               -- List<ELEMENT>       
    326  
    327                                                 [1]      = <
    328  
    329                                                         name = <value = <"systolic">>
    330  
    331                                                         archetype_node_id = <[at0004]>
    332  
    333                                                         value = <magnitude = <105.0> ...>
    334  
    335                                                 >
    336  
    337                                                 [2]      = <
    338  
    339                                                         name = <value = <"diastolic">>
    340  
    341                                                         archetype_node_id = <[at0005]>
    342  
    343                                                         value = <magnitude = <70.0> ...>
    344  
    345                                                 >
    346  
    347                                         >
    348  
    349                                 >
    350  
    351                         >
    352  
    353                 >
    354  
    355 >
    356 
    357 [注記: 上記の例において、名前の値はすべてDV_TEXTであるものとして示しているが、実際のopenEHRではDV_CODE_TEXTインスタンスであることが多い。どちらもアーキタイプによって許容される。これは例示のサイズを縮小するためであり、下記に示すパスとなんら異なるものではない。]
    358  
    359 [Note: in the above example, name values are shown as if they were all DV_TEXTs, whereas in reality in openEHR they more likely to be DV_CODED_TEXT instances; either is allowed by the archetype. This has been done to reduce the size of the example, and makes no difference to the paths shown below].
    360 
    361 上述のアーキタイプ・パスは、記録に含まれる両収縮期血圧のいずれにも適合する。多くの検索場面において、これこそが正に求められるものである。だが、収縮期血圧の各ノードに一意に適合させるためには、パスはarchetype_node_idのみならず他の属性にも基づいて生成されなければならない。上記のケースでは、name属性が一意性を提供する。各イベント(座位及び立位での計測)ごとの収縮期及び拡張期血圧に関する一意性が保証されたパスは、下記の表現によって可能となる。（XPathと全く同一である)[[FootNote(attr[1]という表記は、Xpathでのattr[position() = 1]の簡略形である。)]]
    362 
    363 The archetype path mentioned above matches both systolic pressures in the recording. In many querying situations, this may be exactly what is desired. However, to uniquely match each of the systolic pressure nodes, paths need to be created that are based not only on the archetype_node_id but also on another attribute. In the case above, the name attribute provides uniqueness. Guaranteed unique paths to the systolic and diastolic pressures of each event (sitting and standing measurements) are available using the following expressions (identical in Xpath)3:
    364 
    365 /data/events[1]/data/items[1]/value/magnitude
    366  
    367 /data/events[1]/data/items[2]/value/magnitude
    368  
    369 /data/events[2]/data/items[1]/value/magnitude
    370  
    371 /data/events[2]/data/items[2]/value/magnitude
    372 
    373 アーキタイプ・パスに基づいて、さらに表現力のある一意のパスも可能である。たとえば、
    374  
    375 More expressive unique paths based on archetype paths are also possible, as follows:
    376 
    377 /data/events[at0006, `sitting']/data/items[at0004]/value/magnitude
    378  
    379 /data/events[at0006, `sitting']/data/items[at0005]/value/magnitude
    380  
    381 /data/events[at0006, `standing']/data/items[at0004]/value/magnitude
    382  
    383 /data/events[at0006, `standing']/data/items[at0005]/value/magnitude
    384  
    385 これらのパスはそれぞれXPathと等しい以下の形式を持っている。
    386 
    387 Each of these paths has an Xpath equivalent of the following form:
    388 
    389 /data/events[@archetype_node_id=`at0006' and name/value=`standing']
    390  
    391         /data/items[@archetype_node_id=`at0004']
    392  
    393         /value/magnitude
    394 
    395 一般規則として、ランタイム・データにおけるひとつまたは複数の他の属性値によって、openEHRデータにおけるいかなるノードでも一意に識別させることができるであろう。一意のパスをより容易に構築するためには、name属性(LOCATABLEクラスから継承したもの) の値が、兄弟ノードのname値に対して一意であることが要請される。このことは以下の2点に帰着する。
    396   * 一意性が保証されたパスは、(上記のパスの例で示したように)archetype_node_idとname値との組合わせを用いることによって、openEHRデータ中のいかなるデータに対しても常に構築することが可能である。
    397   * name値は、ひとつまたは複数の属性値のコピーとしてシステマティックに定義することも可能であろう。たとえば、あるEVENTオブジェクトにおいて、nameはtime属性を文字列としてコピーしたものとすることが明らかに可能である。
    398  
    399 As a general rule, one or more other attribute values in the runtime data will uniquely identify any node in openEHR data. To make construction of unique paths easier, the value of the name attribute (inherited from the LOCATABLE class), is required to be unique with respect to the name values of sibling nodes. This has two consequences as follows:
    400   * a guaranteed unique path can always be constructed to any data item in openEHR data using a combination of archetype_node_id and name values (as shown in the example paths above);
    401   * the name value may be systematically defined to be a copy of one or more other attribute values. For example, in an EVENT object, name could clearly be a string copy of the time attribute.
    402 
    403 == 11.3 EHR URI == #uri
    404 
    405 11.3 EHR URIs
    406 
    407 あらゆるリソースに使用可能なURIとして、直接参照と検索の2つの大きなカテゴリーがある。最初の種類は、通常参照されるべき項目を含むシステムによって生成され、定義された参照情報として他のシステムに渡される。一方、2つ目のものは、要求側のシステムからURI形式によって行われるクエリである。
    408 
    409 There are two broad categories of URIs that can be used with any resource: direct references, and queries. The first kind are usually generated by the system containing the referred-to item, and passed to other systems as definitive references, while the second are queries from the requesting system in the form of a URI.
    410 
    411 === 11.3.1 EHR参照URI === #reference
    412 
    413 11.3.1 EHR Reference URIs
    414 
    415 EHR内のノードへのURI(uniform resource identifier)形式での参照を生成するためには、最上位構造内のパス、EHR内での最上位構造への参照、そしてEHRへの参照という、3つの要素が必要となる。これらは、以下の構文に従って、"ehr"スキーマ空間内でURI形式に組合わされる。
    416 
    417 To create a reference to a node in an EHR in the form of a URI (uniform resource identifier), three elements are needed: the path within a top-level structure, a reference to a top-level structure within an EHR, and a reference to an EHR. These can be combined to form a URI in an "ehr" scheme-space, obeying the following syntax:
    418 
    419 ehr://ehr_locator/top_level_structure_locator/path_inside_top_level_structure
    420 
    421 このようにして、あらゆるopenEHR EHRのあらゆるオブジェクトは、URIを通じてアドレス可能となる。ehr空間内では、特定のサーバーやホスト等に対するURLスタイルでの参照は、長期間にわたる信頼性が得られないために、用いられない。その代わり、EHR及び／または患者に対する論理的な識別子が用いられ、参照しようとしているリソースのライフタイムにわたってURIが正しく存続することを担保している。openEHRのデータ型であるDV_EHR_URIは、この形式のURIを格納するために設計され、URIがLINK内及びopenEHR EHR内の他の場所で用いられるべく構築されることを実現している。
    422  
    423 In this way, any object in any openEHR EHR is addressable via a URI. Within ehr-space, URL-style references to particular servers, hosts etc are not used, due to not being reliable in the long term. Instead, logical identifiers for EHRs and/or subjects are used, ensuring that URIs remain correct for the lifetime of the resources to which they refer. The openEHR data type DV_EHR_URI is designed to carry URIs of this form, enabling URIs to be constructed for use within LINKs and elsewhere in the openEHR EHR.
    424 
    425 ehr:// というURIは、ehr空間内での名前解決のメカニズムが使用できることを意味している。これは、http-、ftp-及びその他のウェル・ノウンURIスキーマに対してそのようなサービスを提供するDNSと同様である。このようなサービスが確立されるまでは、ehr:// URIの取り扱いには、より伝統的なhttp://スタイルの参照と同じように、アドホックな手段が使用されていたと思われる。以下のサブセクションでは、両方の種類のURIがどのように構築されるかを記述する。
    426 
    427 An ehr:// URI implies the availability of a name resolution mechanism in ehr-space, similar to the DNS, which provides such services for http-, ftp- and other well-known URI schemes. Until such services are established, ad hoc means of dealing with ehr:// URIs are likely to be used, as well as more traditional http:// style references. The subsections below describe how URIs of both kinds can be constructed.
    428 
    429 ==== EHRロケーション ====
    430 
    431 EHR Location
    432 
    433 ehr空間では、EHRに対する直接のロケーターは、患者の識別子やクエリとは明確に区別されるEHR識別子である。通常は要求される対象は'ローカル・システム'内のコピーであり、大多数の場合は、それが実在する唯一のものであると思われる。このケースでは、要求されるEHRは、以下の形式のURIで与えられるような、修飾子のない識別子によって単純に識別できる。
    434 
    435 In ehr-space, a direct locator for an EHR is an EHR identifier as distinct from a subject or patient identifier or query. Normally the copy in the `local system' is the one required, and a majority of the time, may be the only one in existence. In this case, the required EHR can be identified simply by an unqualified identifier, giving a URI of the form:
    436 
    437 ehr://1234567/
    438  
    439 だが、患者のEHRは多数のEHRシステム間でコピーされ同期されるために、与えられたEHR識別子がひとつ以上のロケーションに存在する場合がある。 部分コピーが許容されているため、このようなEHRのそれぞれが他と完全に一致するコピーであるという保証はない。それゆえに、EHRのコピーが存在する環境で、どのEHRのインスタンスが要求されているかを正確に識別することを要する場合には、以下の形式のURIで与えられるような体系的な識別子も必要となる。
    440 
    441 However, due to copying / synchronising of the EHR for one subject among multiple EHR systems, a given EHR identifier may exist at more than one location. It is not guaranteed that each such EHR is a completely identical copy of the others, since partial copying is allowed. Therefore, in an environment where EHR copies exist, and there is a need to identify exactly which EHR instance is required, an system identifier is also required, giving a URI of the form:
    442 
    443 ehr://1234567@rmh.nhs.net/
    444 
    445 ==== 最上位構造のロケーター ====
    446  
    447 Top-level Structure Locator
    448 
    449 openEHR EHRにおける最上位構造を識別するためには、論理的に2つの方法がある。1番目のものは、要求された最上位オブジェクトの識別子とバージョン・時刻(すなわち'system'または'commit time')の組合わせによるものである。前者は、関係するVERSIONED_OBJECTのuidを用いる方法や、アーキタイプ識別子または名前による方法を含む、いくつかの方法で行うことができる。これによればURIは以下のようになる。
    450 
    451 There are two logical ways to identify a top-level structure in an openEHR EHR. The first is via the combination of the identifier of the required top-level object and the version time (i.e. `system' or `commit' time). The former can be done in a number of ways, including via the use of the uid of the relevant VERSIONED_OBJECT, or via archetype identifiers, or names. This would lead to URIs like the following:
    452 
    453 ehr://1234567/87284370-2D4B-4e3d-A3F3-F303D2F4F34B@latest_trunk_version -- a VO Guid
    454  
    455 ehr://1234567/87284370-2D4B-4e3d-A3F3-F303D2F4F34B@2005-08-02T04:30:00 -- using time
    456  
    457 最上位構造を識別する2番目の方法は、正確なバージョン識別子を用いる方法である。すなわち、version_object_uid::version_tree_id::creating_system_idという形式をとるopenEHR標準のバージョン識別子である。この場合は、URIは以下のようになる。
    458 
    459 The second way to identify a top-level structure is by using an exact Version identifier, i.e. the standard openEHR Version identifier, which takes the form version_object_uid::version_tree_id::creating_system_id. This leads to URIs like the following:
    460 
    461 ehr://1234567/87284370-2D4B-4e3d-A3F3-F303D2F4F34B::rmh.nhs.net:2
    462  
    463 
    464  
    465 ehr://1234567/87284370-2D4B-4e3d-A3F3-F303D2F4F34B::F7C5C7B7-75DB-
    466  
    467         4b39-9A1E-C0BA9BFDBDEC:2
    468 
    469 1番目のURIは、バージョン識別子が87284370-2D4B-4e3d-A3F3-F303D2F4F34B::rmh.nhs.net:2である、すなわち、net.nhs.rmhとして識別されるEHRにおいて生成され、GUIDで識別されるバージョン付きオブジェクトの2番目の主要バージョンである最上位項目を識別する。2番目も同様であるが、別のGUIDが生成システムを識別するために用いられている。バージョン識別子によるシステムへの言及は、要求されたEHRがそのシステムであることを意味するものではなく、単に探索された最上位オブジェクトがそのシステムで生成されたことを意味することに注意されたい。
    470  
    471 The first URI identifies a top-level item whose version identifier is 87284370-2D4B-4e3d-A3F3-F303D2F4F34B::rmh.nhs.net:2, i.e. the second trunk version of the Versioned Object indentified by the Guid, created at an EHR system identified by net.nhs.rmh. The second is the same, but another Guid is used to identify the creating system as well. Note that the mention of a system in the version identifier does not imply that the requested EHR is at that system, only that the top-level object being sought was created at that system.
    472 
    473 もしバージョン識別子への言及がなければ、常に'latest_trunk_version'であるものと想定される。以下の通り。
    474 
    475 If no Version identifier is mentioned, `latest_trunk_version' is always assumed, as per the following:
    476 
    477 ehr://1234567/87284370-2D4B-4e3d-A3F3-F303D2F4F34B
    478  
    479 ==== 項目のURI ====
    480 
    481 Item URIs
    482 
    483 先に記述したパス表現への追加を用いて、URIはopenEHR EHRの最小粒度の項目への参照を構築することができる。たとえば以下のように。
    484 
    485 With the addition of path expressions as described earlier, URIs can be constructed that refer to the finest grained items in the openEHR EHR, such as the following:
    486 
    487 ehr://1234567/87284370-2D4B-4e3d-A3F3-F303D2F4F34B@latest_trunk_version/
    488  
    489         content[openEHR-EHR-SECTION.vital_signs.v1]/
    490  
    491         items[openEHR-EHR-OBSERVATION.heart_rate-pulse.v1]/data/
    492  
    493         events[at0006, 'any event']/data/items[at0004]
    494  
    495 ==== 相対URI ====
    496 
    497 Relative URIs
    498 
    499 URIは、カレントのEHRに対して相対的に構築することもでき、このケースではEHR idに言及することはない。以下に例を示す。
    500 
    501 URIs can also be constructed relative to the current EHR, in which case they do not mention the EHR id, as in the following example:
    502  
    503 ehr:///87284370-2D4B-4e3d-A3F3-F303D2F4F34B@latest_version/
    504  
    505         content[openEHR-EHR-SECTION.vital_signs.v1]/
    506  
    507         items[openEHR-EHR-OBSERVATION.blood_pressure.v1]/
    508  
    509         data/events[at0006, 'any event']/data/items[at0004]
    510 
    511 [[FootNote]]
    512 1See W3C Xpath 1.0 specification, 1999. Available at http://www.w3.org/TR/xpath.
    513 2In all openEHR documentation, the term "attribute" is used in the object-oriented sense of "property of an object", not in the XML sense of named values appearing within a tag. The syntax described here should not be considered to necessarily have a literal mapping to XML instance, but rather to have a logical mapping to object-oriented data structures.
    514 3the notation attr[1] is a Xpath shorthand for attr[position() = 1]
    515 
    516 [wiki:"Archtectural Overview index" TOC] [wiki:"Archtectural Overview Archetypes" PREV] [wiki:"Archtectural Overview Terminology" NEXT]