Changes between Version 1 and Version 2 of Archtectural Overview Paths


Ignore:
Timestamp:
Oct 25, 2007, 6:38:06 PM (14 years ago)
Author:
haru
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Archtectural Overview Paths

    v1 v2  
    145145        AND value/defining_code/code_string = "A04"]
    146146
    147 11.2.3 トップレベル構造におけるパス
     14711.2.3 最上位構造におけるパス
    148148
    14914911.2.3 Paths within Top-level Structures
    150150
     151最上位構造内のパスは、リファレンス・モデルの関係部分における属性や関数名と厳格に結びついている。述語表現は、これらの構造中のパスにおけるさまざまなポイント、とりわけアーキタイプが「チェーンしている」ポイントにおいて、多数の兄弟関係にあたるものを区別するために必要である。チェーン・ポイントとは、図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]と記述できる。
     152
    151153Paths 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.
     154
     155以下のパスは、COMPOSITION内で項目を参照する例である。
     156
    152157The following paths are examples of referring to items within a Composition:
     158
    153159/content[openEHR-EHR-SECTION.vital_signs.v1 and name/value='Vital signs']/
    154160 
     
    170176 
    171177        data/events[at0006, 'any event']/data/items[at0005]
     178
     179他の最上位タイプ内のパスも、同様の一般的なアプローチでたどることができる。すなわち、必要な属性を階層構造に沿ってたどることで生成される。
    172180 
    173181Paths within the other top level types follow the same general approach, i.e. are created by following the required attributes down the hierarchy.
    174 11.2.4 Data Paths and Uniqueness
     182
     18311.2.4 データ・パスと一意性
     184
     18511.2.4 Data Paths and Uniqueness
     186
     187ひとつのアーキタイプ・ノードがデータ中の多数のインスタンスに対応し得るものであるという事実があるために、アーキタイプ・パスは、データ中で一意に識別される項目であるという保証はない。だが、実データ中で一意の項目であるようなパスを構築することは、しばしば必要となる。このことはパス述語においてarchetype_node_ide以外の属性を用いることによって可能となる。以下のOBSERVATIONアーキタイプを例として考察してみよう。
     188 
    175189Archetype 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:
     190
    176191OBSERVATION[at0000] matches {                                                           -- blood pressure measurement
    177192 
     
    223238 
    224239
     240
     241このアーキタイプから抽出された以下のパスは、収縮期血圧値を参照するものである。
    225242 
    226243The following path extracted from the archetype refers to the systolic blood pressure magnitude:
     244
    227245/data/events[at0006]/data/items[at0004]/value/magnitude
    228  
     246
     247アーキタイプの各ノードの[atnnnn]というコードが、データ中の各ノードで見られるarchetype_node_idとなる。
     248
    229249The codes [atnnnn] at each node of the archetype become the archetype_node_ids found in each node in the data.
     250
     251さてここで、このアーキタイプを用いて2つの血圧の履歴が記録されているOBSERVATIONインスタンス(ここではdADL形式で表現される)について考察しよう。
     252
    230253Now consider an OBSERVATION instance (expressed here in dADL format), in which a history of two blood pressures has been recorded using this archetype:
     254
    231255<       -- OBSERVATION - blood pressure measurement
    232256 
     
    326350 
    327351>
     352
     353[注記: 上記の例において、名前の値はすべてDV_TEXTであるものとして示しているが、実際のopenEHRではDV_CODE_TEXTインスタンスであることが多い。どちらもアーキタイプによって許容される。これは例示のサイズを縮小するためであり、下記に示すパスとなんら異なるものではない。]
    328354 
    329355[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].
     356
     357上述のアーキタイプ・パスは、記録に含まれる両収縮期血圧のいずれにも適合する。多くの検索場面において、これこそが正に求められるものである。だが、収縮期血圧の各ノードに一意に適合させるためには、パスはarchetype_node_idのみならず他の属性にも基づいて生成されなければならない。上記のケースでは、name属性が一意性を提供する。各イベント(座位及び立位での計測)ごとの収縮期及び拡張期血圧に関する一意性が保証されたパスは、下記の表現によって可能となる。(XPathと全く同一である)3
     358
    330359The 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:
     360
    331361/data/events[1]/data/items[1]/value/magnitude
    332362 
     
    336366 
    337367/data/events[2]/data/items[2]/value/magnitude
     368
     369アーキタイプ・パスに基づいて、さらに表現力のある一意のパスも可能である。たとえば、
    338370 
    339371More expressive unique paths based on archetype paths are also possible, as follows:
     372
    340373/data/events[at0006, `sitting']/data/items[at0004]/value/magnitude
    341374 
     
    346379/data/events[at0006, `standing']/data/items[at0005]/value/magnitude
    347380 
     381これらのパスはそれぞれXPathと等しい以下の形式を持っている。
     382
    348383Each of these paths has an Xpath equivalent of the following form:
     384
    349385/data/events[@archetype_node_id=`at0006' and name/value=`standing']
    350386 
     
    352388 
    353389        /value/magnitude
     390
     391一般規則として、ランタイム・データにおけるひとつまたは複数の他の属性値によって、openEHRデータにおけるいかなるノードでも一意に識別させることができるであろう。一意のパスをより容易に構築するためには、name属性(LOCATABLEクラスから継承したもの) の値が、兄弟ノードのname値に対して一意であることが要請される。このことは以下の2点に帰着する。
     392·       一意性が保証されたパスは、(上記のパスの例で示したように)archetype_node_idとname値との組合わせを用いることによって、openEHRデータ中のいかなるデータに対しても常に構築することが可能である。
     393·       name値は、ひとつまたは複数の属性値のコピーとしてシステマティックに定義することも可能であろう。たとえば、あるEVENTオブジェクトにおいて、nameはtime属性を文字列としてコピーしたものとすることが明らかに可能である。
    354394 
    355395As 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:
    356396·       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);
    357397·       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.
     398
     39911.3 EHR URI
     400
    35840111.3 EHR URIs
     402
     403あらゆるリソースに使用可能なURIとして、直接参照と検索の2つの大きなカテゴリーがある。最初の種類は、通常参照されるべき項目を含むシステムによって生成され、定義された参照情報として他のシステムに渡される。一方、2つ目のものは、要求側のシステムからURI形式によって行われるクエリである。
     404
    359405There 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.
     406
     40711.3.1 EHR参照URI
     408
    36040911.3.1 EHR Reference URIs
     410
     411EHR内のノードへのURI(uniform resource identifier)形式での参照を生成するためには、最上位構造内のパス、EHR内での最上位構造への参照、そしてEHRへの参照という、3つの要素が必要となる。これらは、以下の構文に従って、"ehr"スキーマ空間内でURI形式に組合わされる。
     412
    361413To 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:
     414
    362415ehr://ehr_locator/top_level_structure_locator/path_inside_top_level_structure
     416
     417このようにして、あらゆるopenEHR EHRのあらゆるオブジェクトは、URIを通じてアドレス可能となる。ehr空間内では、特定のサーバーやホスト等に対するURLスタイルでの参照は、長期間にわたる信頼性が得られないために、用いられない。その代わり、EHR及び/または患者に対する論理的な識別子が用いられ、参照しようとしているリソースのライフタイムにわたってURIが正しく存続することを担保している。openEHRのデータ型であるDV_EHR_URIは、この形式のURIを格納するために設計され、URIがLINK内及びopenEHR EHR内の他の場所で用いられるべく構築されることを実現している。
    363418 
    364419In 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.
     420
     421ehr:// というURIは、ehr空間内での名前解決のメカニズムが使用できることを意味している。これは、http-、ftp-及びその他のウェル・ノウンURIスキーマに対してそのようなサービスを提供するDNSと同様である。このようなサービスが確立されるまでは、ehr:// URIの取り扱いには、より伝統的なhttp://スタイルの参照と同じように、アドホックな手段が使用されていたと思われる。以下のサブセクションでは、両方の種類のURIがどのように構築されるかを記述する。
     422
    365423An 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.
     424
     425EHRロケーション
     426
    366427EHR Location
     428
     429ehr空間では、EHRに対する直接のロケーターは、患者の識別子やクエリとは明確に区別されるEHR識別子である。通常は要求される対象は'ローカル・システム'内のコピーであり、大多数の場合は、それが実在する唯一のものであると思われる。このケースでは、要求されるEHRは、以下の形式のURIで与えられるような、修飾子のない識別子によって単純に識別できる。
     430
    367431In 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:
     432
    368433ehr://1234567/
    369434 
     435だが、患者のEHRは多数のEHRシステム間でコピーされ同期されるために、与えられたEHR識別子がひとつ以上のロケーションに存在する場合がある。 部分コピーが許容されているため、このようなEHRのそれぞれが他と完全に一致するコピーであるという保証はない。それゆえに、EHRのコピーが存在する環境で、どのEHRのインスタンスが要求されているかを正確に識別することを要する場合には、以下の形式のURIで与えられるような体系的な識別子も必要となる。
     436
    370437However, 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:
     438
    371439ehr://1234567@rmh.nhs.net/
    372  
    373 Top-level Structure Locator
     440
     441最上位構造のロケーター
     442 
     443Top-level Structure Locator
     444
     445openEHR EHRにおける最上位構造を識別するためには、論理的に2つの方法がある。1番目のものは、要求された最上位オブジェクトの識別子とバージョン・時刻(すなわち'system'または'commit time')の組合わせによるものである。前者は、関係するVERSIONED_OBJECTのuidを用いる方法や、アーキタイプ識別子または名前による方法を含む、いくつかの方法で行うことができる。これによればURIは以下のようになる。
     446
    374447There 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:
     448
    375449ehr://1234567/87284370-2D4B-4e3d-A3F3-F303D2F4F34B@latest_trunk_version -- a VO Guid
    376450 
    377451ehr://1234567/87284370-2D4B-4e3d-A3F3-F303D2F4F34B@2005-08-02T04:30:00 -- using time
    378452 
     453最上位構造を識別する2番目の方法は、正確なバージョン識別子を用いる方法である。すなわち、version_object_uid::version_tree_id::creating_system_idという形式をとるopenEHR標準のバージョン識別子である。この場合は、URIは以下のようになる。
     454
    379455The 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:
     456
    380457ehr://1234567/87284370-2D4B-4e3d-A3F3-F303D2F4F34B::rmh.nhs.net:2
    381458 
     
    385462 
    386463        4b39-9A1E-C0BA9BFDBDEC:2
     464
     4651番目のURIは、バージョン識別子が87284370-2D4B-4e3d-A3F3-F303D2F4F34B::rmh.nhs.net:2である、すなわち、net.nhs.rmhとして識別されるEHRにおいて生成され、GUIDで識別されるバージョン付きオブジェクトの2番目の主要バージョンである最上位項目を識別する。2番目も同様であるが、別のGUIDが生成システムを識別するために用いられている。バージョン識別子によるシステムへの言及は、要求されたEHRがそのシステムであることを意味するものではなく、単に探索された最上位オブジェクトがそのシステムで生成されたことを意味することに注意されたい。
    387466 
    388467The 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.
     468
     469もしバージョン識別子への言及がなければ、常に'latest_trunk_version'であるものと想定される。以下の通り。
     470
    389471If no Version identifier is mentioned, `latest_trunk_version' is always assumed, as per the following:
     472
    390473ehr://1234567/87284370-2D4B-4e3d-A3F3-F303D2F4F34B
    391474 
     475項目のURI
     476
    392477Item URIs
     478
     479先に記述したパス表現への追加を用いて、URIはopenEHR EHRの最小粒度の項目への参照を構築することができる。たとえば以下のように。
     480
    393481With 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:
     482
    394483ehr://1234567/87284370-2D4B-4e3d-A3F3-F303D2F4F34B@latest_trunk_version/
    395484 
     
    400489        events[at0006, 'any event']/data/items[at0004]
    401490 
     491相対URI
     492
    402493Relative URIs
    403 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:
     494
     495URIは、カレントのEHRに対して相対的に構築することもでき、このケースではEHR idに言及することはない。以下に例を示す。
     496
     497URIs can also be constructed relative to the current EHR, in which case they do not mention the EHR id, as in the following example:
     498 
    404499ehr:///87284370-2D4B-4e3d-A3F3-F303D2F4F34B@latest_version/
    405500 
     
    410505        data/events[at0006, 'any event']/data/items[at0004]
    411506 
     5071W3C Xpath 1.0 specification, 1999参照(http://www.w3.org/TR/xpath にて利用可能)
     5082すべてのopenEHRのドキュメントにおいて、"属性(attribute)"という用語はオブジェクト指向における"オブジェクトのプロパティ"の意味で用いられている。XMLにおけるタグ中に現れる名前の値を意味しない。ここで記述された構文は、XMLインスタンスへの字義通りのマッピングを必ずしも考慮に入れたものではなく、むしろオブジェクト指向のデータ構造への論理的なマッピングが考慮されている。
     5093attr[1]という表記は、Xpathでのattr[position() = 1]の簡略形である。
     510
    4125111See W3C Xpath 1.0 specification, 1999. Available at http://www.w3.org/TR/xpath.
    4135122In 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.