CPSVハンドブック

免責事項

このレポートは純粋な著者の見解であり、いかなる状況においても欧州委員会の公式的な見解として解釈されるものではない。

欧州委員会はこの内容の正確性について責任を持たず、使用に関してもいかなる責任を負わない。

このレポートでのいかなる引用も欧州委員会の承認、推奨、または支持を含意しない。

すべての図表の著作権について、著者は細心の注意を払って許可を取得した。

---------------------------------

このレポートはPwCによって慎重に編集されていますが、いかなる情報の正確性や完全性について保証及び表明するものではない。

PwCは情報の使用に際して発生するいかなる損害に関しても責任を負わない。

このレポートは、特定の専門家のアドバイスに代わるものではない。

適切な専門家のアドバイスを考慮せずに、ここの内容を使用することは推奨されない。

目次

1.1 文脈互換性の必要性について

1.2 ハンドブックがカバーする範囲

1.3 Core Vocabulariesによる文脈互換性における衝突の緩和

1.4 使用事例

1.5 レポートの読み方

2.1 概要

2.2 表現形式

2.3 ライセンスの条件

3.1 モデリング規則

3.2 モデルの特徴

3.3 概念モデルのカスタマイズ

3.4 関係のマッピング

3.5 適合要件

4.1 コンテキストと要件

4.2 情報モデリング

4.3 追加要件

4.4 語法の接続

4.5 構文の記録とマッピング

5. 参考文献

6.1 既存の語法への接続をもつデータモデルの設計の例

6.2 新しい語法のデータモデルの作成の例

1. 序章

1.1 文脈互換性の必要性について

1.2 ハンドブックがカバーする範囲

このハンドブックではCore Vocabulariesに基づいた汎用なデータモデルの設計やマッピングについて紹介します。

具体的な技術環境によらない一般的な記述をします。したがって：

完成した方法論について記述しない

あらゆるツールやライブラリー、方法論について推奨しない

1.3 Core Vocabulariesによる文脈互換性における衝突の緩和

EUの国々のサービスの容態は複雑だ。ゆえにデータのやりとりにおいて衝突がしばしば起こる。Core Vocabulariesは二つの方法でそのような衝突を減らすことができる：

設計：Core Vocabulariesをピースに積み上げたデータモデルはコンセプトや構成において、最低限の横断的な相互運用性が保証される。

マッピング：Core Vocabulariesにマッピングされたデータは、Core Vocabulariesを様々なデータモデルのへの架け橋として使うことが可能である

以下に衝突へのCore Vocabulariesのできることを示す：

1.3.1 スキームレベルでの衝突の緩和

ネーミング：同じコンセプトに対して違う名前で呼ばれたり、違うコンセプトが同じ名前で呼ばれたりする場合、Core Vocabulariesは共通の名前を使用することによってこれらの衝突を避けます。

識別子(ID)：同じ対象への違う識別子について、Core Vocabulariesは情報交換のための識別子を提供します。

同型：同じコンセプトが違う属性によって記述される場合、 Core Vocabulariesの最小限の共通の集合によって衝突を緩和することができる。

一般化：似たようなコンセプトだが、広義や狭義の違いがある場合、Core Vocabulariesではコンセプトを一般化する。狭義的なモデルへのマッピングを行う際はその都度調整する。

集約：いくつかの属性の集合が、他のモデルではひとまとまりにされている場合（例：ある文書では姓と名が別々であるのに対し、別の文書では名前としてひとまとまりに表現される）、Core Vocabulariesはそれらの属性を共通の粒度によって整理する。

スキームの不一致：同じ属性は違うモデルで違う方法で使われたり処理されたりする場合、Core Vocabulariesはもっとも基本的な要素(クラス、性質、関係性)にのみ焦点を当てる。その上で必要に応じて変換を行う。

1.3.2 データレベルでの衝突

Core Vocabulariesデータの表現方法や解釈について多くは影響を与えない

1.4 使用事例

1.4.1Core Vocabulariesで新たなモデルを作る場合

Core Vocabulariesは違う情報システムにおける具体的な情報交換の基盤として使用可能

1.4.2 既存のモデルのCore Vocabulariesへのマッピング

データモデルのCore Vocabulariesによる分析は、どのような調整が可能かの洞察を与える。そのような調整は違うデータ同士の衝突の回避に必要だ。

データモデルがCore Vocabulariesにされたマッピングされたデータは最低限の意味論的な調整が施されている。

1.5 レポートの読み方

この文書は組織がどのようにCore Vocabulariesを実装するかの概要について記述します

第二章ではCore Vocabulariesがどのように作られ、維持されているか、どのようにライセンスの許可のもとで使われるかについて記述します。

第三章ではどのようにデータモデリングの概念を使ってCore Vocabulariesを定義するかについて説明します。それはマッピングの関係についても定義します。それらのマッピングの関係は適合性の要求にとって重要である

第四章では二つの使用事例に詳細な方法論を紹介し、どのようにCore Vocabulariesを使ってデータモデルと設計するかやどのようにマッピングを記録するかを示します。

2. Core Vocabulariesの概要

2.1 概要

欧州連合のISAプログラムは各国のチームを後押しして、四つのCore Vocabulariesの合意を築いた

Core VocabulariesはISAの支持のもとで公開や管理されている

Table1に公開しているモデルを簡単にまとめてある

https://scrapbox.io/files/61270cf7d4360d001dcb65a3.png

core Business vocabulary:

簡単な、再利用および拡張が可能なデータモデル。法人名、活動内容、住所、公的な登録ID、会社の種類など、法人に関する基本的な特徴を記述するのに適している。

core Location vocabulary:

簡単な、再利用および拡張が可能なデータモデル。住所、地理的な名前などの場所に関する記述に適している

core Person vocabulary:

簡単な、再利用および拡張が可能なデータモデル。名前、性別、生年月日など、人の基本的な特性を記述するのに適している

core Service vocabulary:

簡単な、再利用および拡張が可能なデータモデル。行政が提供するサービスの基本的な特徴、例えば公共サービス名、説明、入力、出力、プロバイダー、場所などを記述するのに適している

2.2 表現形式

2.3 ライセンスの条件

3. データモデリングの概念

3.1 モデリング規則

Core Vocabulariesの概念的なモデルは以下の慣例に従います

名前は英数字とスペースで構成され、最初の文字は大文字である

The identifier of a class or data type is the name of the element, where spaces have been removed. For example, the identifier of the “Legal Entity” class is “LegalEntity”.

The identifier of a property, association, or attribute is the concatenation of the identifier of the parent class or data type, and the name of the element, where spaces have been removed. For example, the identifier of the “Company Type” property of the “Legal Entity” class is “LegalEntityCompanyType”.

To avoid identifier clashes, a class or data type name must not be a prefix of another class or data type name. For example, a class named “Address Thoroughfare” would be identified by “AddressThoroughfare”, which would conflict with the identifier of the “Thoroughfare” property of the “Address” class.

Each element is defined by a crisp, oneline definition. The definition starts with a capital letter and ends with a period.

A description may provide complementary information concerning the usage of the element or its relation to relevant standards. For example, a description may contain recommendations about which controlled vocabularies to use. Descriptions may contain multiple paragraphs separated by blank lines. The descriptions should not paraphrase the definitions.

Examples are provided as a commaseparated list. Each example value is enclosed in quotes and is optionally followed by a short explanation enclosed in parentheses.

The UML modelling conventions are based on the conventions mentioned above. Furthermore, the UML diagrams follow the specifications described below.

All data types are defined in the package “DataTypes”. We make the distinction between primitive types (consisting of singular values) and composite types (composed of multiple attributes).

The terminology between the Core Vocabularies and UML is mapped. For example, property is mapped to property, association is mapped to association, etc.

3.2 モデルの特徴

Core Vocabulariesはデータの基本的な特徴を中立な文脈及び語法でとらえた簡単な、再利用可能で拡張可能なデータモデルである。それは以下の特徴を有することを意味する：

No controlled vocabularies: the Core Vocabularies do not propose value vocabularies, i.e. code lists, taxonomies, etc. This is left to the context-specific vocabularies to specify.

No range restrictions: the Core Vocabularies do not include cardinality constraints on associations or attributes. This is left to the context-specific data models to specify on the basis of domaindependent business rules.

No temporal aspects: the Core Vocabularies do not propose a mechanism to deal with temporal aspects. For example, if a country allows a person to change his given name, the Core Vocabularies do not include a mechanism to record the given name of a person at a specific point in time. This is left to the context-specific data models to specify.

No administrative metadata: the Core Vocabularies do not include any administrative guidelines on what should be done with data. For example, it does not contain any guidance on how to deal with personally identifiable information in the context of personal data protection regulations. This is left to the contextspecific data models to specify.

3.3 概念モデルのカスタマイズ

Core Vocabulariesはどのような領域のデータモデルの要求にも適合することを意味していない。これはCore Vocabulariesをデータモデルの基盤として使うにあたって、拡張や制限が必要であることを意味する。以下その方法を示す：

Adding new properties or associations to a class

The most common extension is to add new properties and associations to existing classes. For example, a data model might need to include a property indicating whether a person has a driving licence. The consequences for interoperability are limited, as systems that do not understand the new properties and associations can usually just drop them and still benefit from the information contained in the common properties.

Removing irrelevant properties and associations from a class

Some properties may be irrelevant in a particular domain or for a specific information system. For example, the date of death of a person will not be useful when providing services only to living people. In such cases, the irrelevant properties or associations may be removed from the resulting data model. The direct consequence for interoperability is that a system might be missing information that it would expect from Core Vocabulariesconform models. Hence, removing properties and associations reduces the number of systems with which the data model is interoperable. However, it is the context of information exchange that determines whether the absence of properties and associates can be tolerated or not. On the other hand, if no new properties are added and only some properties removed, there is a guarantee that systems will understand all the remaining properties. Note also that when both adding and removing properties is allowed, this can lead to a situation where no common properties remain. This is however unlikely because of the fundamental character of the core properties. In general, it is desirable for all IT systems aiming at interoperability to understand at least these “core” elements (where applicable). If some “core” information is present in the systems participating in a given information exchange but not needed in all communication scenarios between those systems, it may make sense to first define a more general data model for communication between these systems that includes all core elements, and make sure that all systems “understand” this general model. That general model can then be restricted as needed for any given communication scenario.

Specialising classes, properties, or associations

When using the Core Vocabularies in an information system or information exchange data model, the context refines the meaning of the elements. For example, in a clinical context, a person might be a patient or a doctor. The two specialisations will probably have different additional properties and associations, but share the common properties of the Person class in the Core Vocabularies. Specializing elements may lead to generalization conflicts. Indeed, a patient in a clinical context might not always correspond to a criminal in a judicial context, even though both are specializations of the Person class. However, the common properties and associations defined in the Core Vocabularies, such as the name, should still be valid for the person referred to by the criminal or the patient. Hence, care must be taken when specializing elements so that the resulting elements can still be understood with the semantics of the original elements using the mapping relations “narrow match” as described in Section 3.4.

Replacing classes, properties, or associations

Sometimes, an element from the Core Vocabularies might be close to the requirements of a data model, but still not match them exactly. In such cases, one might replace the element with a new one. Replacing elements has a huge impact on interoperability and is strongly discouraged. Schema-level conflicts, such as schema isomorphism conflicts and schematic discrepancies may occur. To mitigate those issues, it is recommended to use another name (in order to avoid naming conflicts) and to document the difference in the “close match” or “related match” mapping.

3.4 関係のマッピング

3.5 適合要件

4.1 コンテキストと要件

4.2 情報モデリング

4.3 追加要件

4.4 語法の接続

4.5 構文の記録とマッピング

6. 付録

6.1 既存の語法への接続をもつデータモデルの設計の例

6.2 新しい語法のデータモデルの作成の例