この規格 プレビューページの目次
※一部、英文及び仏文を自動翻訳した日本語訳を使用しています。
序章
0.1 一般
この国際標準は、e-ビジネスの分野におけるアプリケーション間の情報の相互運用性の欠如というよく理解されている問題に対する新しいアプローチを説明し、指定しています。従来、ビジネス データ交換の標準は、十分な相互運用性や柔軟性を実現していない静的メッセージ定義に重点が置かれていました。ビジネス セマンティクスを標準化する、より柔軟で相互運用可能な方法が必要です。この国際規格で説明されているコア コンポーネント ソリューションは、今日使用されている一般的なタイプのビジネス データを表すセマンティック ビルディング ブロックの共通セットを開発するための方法論を提示し、新しいビジネス用語の作成と既存のビジネス用語の再構築を提供します。
0.2 概要
この国際規格で説明されているコア コンポーネント仕様 (CCS) は、ビジネス プロセス間の相互運用性をサポートおよび強化するために、ビジネス情報の再利用を特定、文書化、および最大化する方法を提供します。 CCS は、この情報の人間が読み取れる表現と機械で処理できる表現の両方に焦点を当てています。
この国際標準で説明されているコア コンポーネントのアプローチは、この分野の現在の標準よりも柔軟です。これは、セマンティックの標準化が構文に中立な方法で行われるためです。コア コンポーネントを ebXML フレームワークの一部として使用すると、異なる構文 [たとえば、Extensible Markup Language (XML) と国連/行政、商業、および輸送のための EDI (UN/EDIFACT)] を使用する 2 つの取引先がビジネス セマンティクスを使用するのに役立ちます。両方の構文が同じコア コンポーネントに基づいているという条件で、同じように。これにより、構文、業界、地域の境界を越えて、異なるメッセージ定義間の明確なマッピングが可能になります。
ビジネス プロセスおよびコア コンポーネント ソリューションは、メッセージのセマンティクスと構造の違いに関するビジネス上の理由に関する豊富な情報を収集します。過去には、これらのバリエーションによってデータ モデルの互換性がなくなり、相互運用性が失われていました。コア コンポーネント メカニズムにより、これらのモデル間の類似点と相違点を識別できます。非互換性は、大規模ではなく段階的になります。つまり、モデル全体が非互換性として却下されるのではなく、詳細な相違点が記録されます。
0.3 重要な概念
CCS の主要な概念は、コア コンポーネントとビジネス情報エンティティという 2 つのレベルの抽象化に基づいています。これらの重点分野については、箇条 4 および 5 で説明します。それぞれの場合に、概念が導入され、規範的な定義が示され、必要に応じて例が示されます。
注: コア コンポーネントという用語は、基本コア コンポーネント、関連コア コンポーネント、集約コア コンポーネント、およびそれらに関連付けられたコア コンポーネント タイプを含む一般的な用語として使用されます。同様に、ビジネス情報エンティティという用語は、基本ビジネス情報エンティティ、関連ビジネス情報エンティティ、および集約ビジネス情報エンティティを含む一般的な用語として使用されます。
0.4 主要なコア コンポーネントの概念
この国際規格の中心的な概念は、コア コンポーネントです。コア コンポーネントはセマンティック ビルディング ブロックであり、すべての電子ビジネス メッセージを構築するための基礎として使用されます。
コア コンポーネントには 4 つの異なるカテゴリがあります。
- a)基本的なコアコンポーネント;
- b)アソシエーション コア コンポーネント。
- c)コアコンポーネントタイプ;
- d)集約コア コンポーネント。
これらの概念は以下で説明され、その定義は箇条 3 で与えられます。
図 1 —アソシエーション コア コンポーネント
図 1 は、アソシエーション コア コンポーネントの例であり、以下を示しています。
- 3 つの集約コア コンポーネント: 「パーティー。詳細"; "コンタクト。詳細」と「住所。詳細";
- 各集約コア コンポーネントには、多数のプロパティ (つまり、ビジネス特性) があります。
- 集約コアコンポーネント「パーティー。詳細」には、5 つのプロパティ (「名前」、「役割」、「説明」、「定義済みの連絡先」、「郵便番号」) があります。
- 集約コアコンポーネント「連絡先。 Details」には 3 つのプロパティ（「Type」、「Job Title」、「Primary」）があります。
- 集約コアコンポーネント「アドレス。 Details」には 4 つのプロパティ（「Street Name」、「Free Form」、「Postcode」、「Country」）があります。
これらのプロパティのうち 10 は、基本的なコア コンポーネントです。それらはそれぞれ特異なビジネス特性を表し、その許容値のセットはデータ型によって定義されます。
上記の例では:
- "Name"、"Description"、"Job Title"、"Street Name"、"Free Form"、"Postcode" は、Data Type Text です。
- 「役割」と「型」はデータ型コードです。
- 「プライマリ」はデータ型インジケータです。
- 「国」はデータ型識別子です。
他の 2 つのプロパティは、Association Core Components です。これらはそれぞれ複雑なビジネス特性のセットを表し、それぞれの場合、それらの構造は別の関連する集約コア コンポーネントによって定義されます。上記の例では、「パーティー。定義されています。お問い合わせ」と「パーティー。郵便。アドレス」はどちらもアソシエーション コア コンポーネントです。これらの関連する集約コア コンポーネントの構造は、集約コア コンポーネントの「連絡先」によって定義されます。詳細」と「住所。詳細」、それぞれ。
コア コンポーネント (およびビジネス情報エンティティ) には、データ型によって定義されるプロパティがあります。
データ型は、特定のコア コンポーネント プロパティの表現に使用される値の全範囲を表します。データ タイプは、コア コンポーネント タイプの 1 つに基づいていますが、そのコア コンポーネント タイプのコンテンツ コンポーネントおよび/または補足コンポーネントの値のセットの制限を含めることができます。
図 2 の図は、さまざまなコア コンポーネント要素間の関係を示しています。
図 2 —コア コンポーネントの概要
0.5 主要なビジネス情報エンティティの概念
コア コンポーネントとビジネス情報エンティティの主な違いは、ビジネス コンテキストの概念です。ビジネス コンテキストは、コンポーネントの使用コンテキストの特定の要件に従って、コンポーネントのセマンティックな意味を洗練するためのメカニズムです。ビジネス コンテキストが特定されると、コア コンポーネントは、特定のビジネス コンテキストでのコア コンポーネントの使用をサポートするために必要な資格と改良を考慮して設計できます。ビジネス プロセス定義は、メッセージとその内容の使用に関する高レベルの説明を提供します。
コア コンポーネントが実際のビジネス環境で使用される場合、それはビジネス情報エンティティの基礎として機能します。ビジネス情報エンティティは、特定のビジネス コンテキスト内でコア コンポーネントを使用した結果です。
コア コンポーネントとビジネス情報エンティティの間には特定の関係が存在します。コア コンポーネントとビジネス情報エンティティは、多くの点で補完的です。コア コンポーネントは、制御された語彙を使用して相互運用可能なビジネス プロセス モデルとビジネス ドキュメントを作成するための要となることを目的としています。
集約ビジネス情報エンティティは、特定のビジネス コンテキストで一意のビジネス セマンティック定義を持つビジネス データの一部またはビジネス データのグループです。
ビジネス情報エンティティには、次の 3 つの異なるカテゴリがあります。
- a)基本的なビジネス情報エンティティ。
- b)協会ビジネス情報エンティティ。
- c)集約ビジネス情報エンティティ。
これらの中で最も原始的なのは、基本ビジネス情報エンティティです。基本的なビジネス情報エンティティは、特定のビジネス コンテキストで使用される基本的なコア コンポーネントです。
集約ビジネス情報エンティティのプロパティが複雑な性質を持ち、別の集約ビジネス情報エンティティの構造を持つ場合は常に、そのプロパティを表すために関連付けビジネス情報エンティティが使用されます。関連ビジネス情報エンティティは、関連コア コンポーネントに基づいていますが、ビジネス コンテキスト内に存在します。
図 3 —協会ビジネス情報エンティティ
図 3 は Association Business Information Entity の例であり、以下を示しています。
- 3 つの集約ビジネス情報エンティティ: 「Trade_Party.詳細」、「担当_連絡先。詳細」および「構造化アドレス。詳細";
- 各集約コア コンポーネントには、多数のプロパティ (つまり、ビジネス特性) があります。
- 集約ビジネス情報エンティティ「Trade_Party. Details」には 4 つのプロパティ (「Name」、「Role」、「Defined.Responsible_Contact」、「Postal.Structured_Address」) があります。
- 集約ビジネス情報エンティティ「Responsible_Contact.詳細」には 2 つのプロパティ (「タイプ」と「役職」) があります。
- 集約ビジネス情報エンティティ「Structured_Address.詳細」には 2 つのプロパティ (「郵便番号」と「国」) があります。
これらのプロパティのうち 6 つは、基本的なビジネス情報エンティティです。これらはそれぞれ、単一のビジネス特性を表し、それぞれの場合に許可される値のセットは、データ型によって定義されます。
- 「名前」、「役職」、および「郵便番号」はデータ型テキストです。
- 「役割」と「型」はデータ型コードです。
- 「国」はデータ型識別子です。
プロパティのうちの 2 つは関連ビジネス情報エンティティです。これらはそれぞれ一連の複雑なビジネス特性を表し、それぞれの場合、それらの構造は別の関連する集約ビジネス情報エンティティによって定義されます。
- 「貿易_パーティー。定義されています。 Responsible_Contact」および「Trade_Party」。郵便。 Structured_Address」は両方とも関連ビジネス情報エンティティです。
- これらの関連する集約ビジネス情報エンティティの構造は、集約ビジネス情報エンティティ「責任者_連絡先」によって定義されます。 Details」および「Structured_Address.詳細」、それぞれ。
コア コンポーネントとビジネス情報エンティティ間の関係の特徴を図 4 に示します。
図 4 —コア コンポーネントとビジネス情報エンティティの関係
Introduction
0.1 General
This International Standard describes and specifies a new approach to the well-understood problem of the lack of information interoperability between applications in the e-business arena. Traditionally, standards for the exchange of business data have been focused on static message definitions that have not enabled a sufficient degree of interoperability or flexibility. A more flexible and interoperable way of standardizing Business Semantics is required. The Core Component solution described in this International Standard presents a methodology for developing a common set of semantic building blocks that represent the general types of business data in use today and provides for the creation of new business vocabularies and restructuring of existing business vocabularies.
0.2 Overview
The Core Components Specification (CCS) described in this International Standard provides a way to identify, document and maximize the re-use of business information to support and enhance interoperability across Business Processes. CCS focuses both on human-readable and machine-processable representations of this information.
The Core Components approach described in this International Standard is more flexible than current standards in this area because the semantic standardization is done in a syntax-neutral fashion. Using Core Components as part of the ebXML framework will help to ensure that two trading partners using different syntaxes [e.g. Extensible Markup Language (XML) and United Nations/EDI for Administration, Commerce, and Transport (UN/EDIFACT)] are using Business Semantics in the same way on condition that both syntaxes have been based on the same Core Components. This enables clean mapping between disparate message definitions across syntaxes, industry and regional boundaries.
Business Process and Core Component solutions capture a wealth of information about the business reasons for variation in message semantics and structure. In the past, these variations have led to incompatible data models and a subsequent lack of interoperability. The core components mechanism will allow identification of similarities and differences between these models. Incompatibility becomes incremental rather than wholesale, i.e. the detailed points of difference are noted, rather than a whole model being dismissed as incompatible.
0.3 Key Concepts
The CCS key concepts are based two levels of abstraction: Core Components and Business Information Entities. These focus areas are discussed in Clauses 4 and 5: in each case, the concepts are introduced and a normative definition is given, as well as an example, where appropriate.
NOTE The term Core Component is used as a generic term that encompasses Basic Core Components, Association Core Components, Aggregate Core Components, and their associated Core Component Types. Equally, the term Business Information Entity is used as a generic term encompassing Basic Business Information Entities, Association Business Information Entities, and Aggregate Business Information Entities.
0.4 Key Core Component Concepts
The central concept of this International Standard is the Core Component. The Core Component is a semantic building block, which is used as a basis to construct all electronic business messages.
There are four different categories of Core Components:
- a) Basic Core Component;
- b) Association Core Component;
- c) Core Component Type;
- d) Aggregate Core Component.
These concepts are described below and their definitions are given in Clause 3.
Figure 1—Association Core Component
Figure 1 is an example of an Association Core Component and shows the following:
- three Aggregate Core Components: “Party. Details”; “Contact. Details” and “Address. Details”;
- each Aggregate Core Component has a number of Properties (i.e. business characteristics);
- the Aggregate Core Component “Party. Details” has five Properties (“Name”, “Role”, “Description”, “Defined. Contact” and “Postal. Address”);
- the Aggregate Core Component “Contact. Details” has three Properties (“Type”, “Job Title” and “Primary”);
- the Aggregate Core Component “Address. Details” has four Properties (“Street Name”, “Free Form”, “Postcode” and “Country”).
Ten of these Properties are Basic Core Components. They each represent a singular business characteristic and its set of allowed values is defined by a Data Type.
In the above example:
- “Name”, “Description”, “Job Title”, “Street Name”, “Free Form” and “Postcode” are of the Data Type Text;
- “Role” and “Type” are of the Data Type Code;
- “Primary” is of the Data Type Indicator;
- “Country” is of the Data Type Identifier.
The other two Properties are Association Core Components. They each represent a set of complex business characteristics and in each case their structure is defined by another associated Aggregate Core Component. In the above example, “Party. Defined. Contact” and “Party. Postal. Address” are both Association Core Components. The structures of these associated Aggregate Core Components are defined by the Aggregate Core Components “Contact. Details” and “Address. Details”, respectively.
Core Components (and Business Information Entities) have Properties that are defined by Data Types.
A Data Type represents the full range of values to be used for the representation of a particular Core Component Property. A Data Type is based on one of the Core Component Types, but can include restrictions of the set of values of the Content Component and/or Supplementary Component(s) of that Core Component Type.
The diagram in Figure 2 shows the relationships between the various Core Component elements.
Figure 2—Core Component Overview
0.5 Key Business Information Entity Concepts
The key differentiator between Core Components and Business Information Entities is the concept of Business Context. Business context is a mechanism for refining the semantic meaning of components according to the specific requirements of their context of use. Once Business Contexts are identified, Core Components can be designed to take into account any necessary qualification and refinement needed to support the use of their Core Component in the given Business Context. The Business Process definition provides a high level description of the use of a message and its contents.
When a Core Component is used in a real business circumstance it serves as the basis of a Business Information Entity. The Business Information Entity is the result of using a Core Component within a specific Business Context.
A specific relationship exists between Core Components and Business Information Entities. Core Components and Business Information Entities are complementary in many respects. Core Components are intended to be the linchpin for creating interoperable Business Process models and business documents using a Controlled Vocabulary.
An Aggregate Business Information Entity is a piece of business data or a group of pieces of business data with a unique Business Semantic definition in a specific Business Context.
There are three different categories of Business Information Entities:
- a) Basic Business Information Entity;
- b) Association Business Information Entity;
- c) Aggregate Business Information Entity.
The most primitive of these is the Basic Business Information Entity. A Basic Business Information Entity is a Basic Core Component used in a specific Business Context.
Whenever a Property of an Aggregate Business Information Entity is of a complex nature, and has the structure of another Aggregate Business Information Entity, an Association Business Information Entity is used to represent that Property. An Association Business Information Entity is based on an Association Core Component, but exists in a Business Context.
Figure 3—Association Business Information Entity
Figure 3 is an example of Association Business Information Entity and shows the following:
- three Aggregate Business Information Entities: “Trade_ Party. Details”, “Responsible_ Contact. Details” and “Structured Address. Details”;
- each Aggregate Core Component has a number of Properties (i.e. business characteristics);
- the Aggregate Business Information Entity “Trade_ Party. Details” has four Properties (“Name”, “Role”, “Defined. Responsible_ Contact” and “Postal. Structured_ Address”);
- the Aggregate Business Information Entity “Responsible_ Contact. Details” has two Properties (“Type” and “Job Title”);
- the Aggregate Business Information Entity “Structured_ Address. Details” has two Properties (“Postcode” and “Country”).
Six of these Properties are Basic Business Information Entities: they each represent a singular business characteristic and in each case their set of allowed values is defined by their Data Type:
- “Name”, “Job Title” and “Postcode” are of the Data Type Text;
- “Role” and “Type” are of the Data Type Code;
- “Country” is of the Data Type Identifier.
Two of the Properties are Association Business Information Entities: they each represent a set of complex business characteristics and in each case their structure is defined by another associated Aggregate Business Information Entity:
- “Trade_ Party. Defined. Responsible_ Contact” and “Trade_ Party. Postal. Structured_ Address” are both Association Business Information Entities;
- the structures of these Associated Aggregate Business Information Entities are defined by the Aggregate Business Information Entities “Responsible_ Contact. Details” and “Structured_ Address. Details”, respectively.
The features of the relationship between Core Components and Business Information Entities are described in the Figure 4.
Figure 4—Relationships between Core Components and Business Information Entities