データカタログ語彙 (DCAT) - バージョン 3

DCATは、データカタログを表現するためのRDF語彙である。 DCATは、7つの主要なクラスを中心に構成されている（図 1）:

• dcat:Catalog はカタログを表す。これは、各個別項目が 何らかのリソースを記述するメタデータレコードであるデータセットであり、 dcat:Catalog の範囲は、データセット、データサービス、 または他のリソース型に関するメタデータのコレクションである。
• dcat:Resource は、カタログ内のメタデータレコードによって 記述され得るデータセット、データサービス、またはその他の任意のリソースを表す。 このクラスは直接使用されることを意図しておらず、dcat:Dataset、dcat:DataService および dcat:Catalog の親クラスである。 カタログ内のリソースは、これらのクラスのいずれかのインスタンス、またはそれらのサブクラス、 あるいはDCATプロファイルまたは他のDCATアプリケーションで定義される dcat:Resource のサブクラスのインスタンスであるべきである。 dcat:Resource は、実際には任意の種類のリソースの カタログを定義するための拡張点である。dcat:Dataset および dcat:DataService は、どのカタログにも記載されていない データセットおよびサービスに使用できる。
• dcat:Dataset は、単一のエージェントまたは識別可能な コミュニティによって公開または管理されるデータのコレクションを表す。DCATにおけるデータセットの概念は 広く包括的であり、すべてのコミュニティから生じるリソース型を受け入れることを意図している。 データは、数値、テキスト、ピクセル、画像、音声、その他のマルチメディア、さらに潜在的には 他の型を含む多くの形態をとり、それらのいずれもデータセットに収集され得る。
• dcat:Distribution は、ダウンロード可能なファイルなど、 データセットのアクセス可能な形式を表す。
• dcat:DataService は、1つ以上のデータセットまたは データ処理機能へのアクセスを提供する、インターフェース（API）を通じてアクセス可能な操作の集合を表す。
• dcat:DatasetSeries は、個別に公開されるが、 それらをグループ化する何らかの特性を共有するデータセットのコレクションを表すデータセットである。
• dcat:CatalogRecord は、主に、誰がいつレコードを 追加したかなどの登録情報に関する、カタログ内のメタデータレコードを表す。

DCATにおけるデータセットは、「単一のエージェントによって公開または管理され、 1つ以上のシリアル化または形式でアクセスまたはダウンロード可能なデータのコレクション」として定義される。 データセットは概念的な実体であり、転送のためにデータセットをシリアル化する1つ以上の配布によって 表現され得る。 データセットの配布は、データサービスを介して提供できる。

データサービスは通常、サービスに対してローカルまたはリモートにホストされ得るデータセットに対して、 選択、抽出、組み合わせ、処理または変換操作を提供する。 データサービスへの任意の要求の結果は、データセットまたはカタログの一部または全部の表現である。 データサービスは特定のデータセットに結び付いている場合もあれば、そのソースデータが要求時または 実行時に構成される場合もある。 データ配布サービスは、データセットまたはサブセットの配布の選択およびダウンロードを可能にする。 データ発見サービスは、クライアントが適切なデータセットを見つけられるようにする。 他の種類のデータサービスには、座標変換サービス、再サンプリングおよび補間サービスなどの データ変換サービス、ならびにシミュレーションおよびモデリングサービスを含む各種データ処理サービスが含まれる。 DCATにおけるデータサービスは、データへのアクセスを提供する操作または API の集合であることに注意。 対話的なユーザーインターフェースは、API操作への便利なアクセスを提供するためにしばしば利用可能であるが、 その記述はDCATの範囲外である。 特定のデータサービスエンドポイントの詳細は、多くの場合、DCAT語彙自体の範囲を補完する標準サービス型に 適合した記述を通じて指定される。

データセットおよびデータサービスの記述は、カタログに含めることができる。 カタログは、そのメンバー項目がデータセットおよびデータサービスの記述である一種のデータセットである。 他の種類のリソースもカタログ化され得るが、DCATの範囲は現在、データセットおよびデータサービスに限定される。 カタログの範囲をデータセットおよびデータサービスを超えて拡張するには、DCATプロファイルまたは 他のDCATアプリケーションで dcat:Resource の追加サブクラスを 定義することが推奨される。 サービス記述の範囲をデータ配布サービスを超えて拡張するには、DCATプロファイルまたは他のDCATアプリケーションで dcat:DataService の追加サブクラスを定義することが推奨される。

カタログレコードは、カタログ内のエントリを記述する。dcat:Resource がデータセットまたはサービス自体を表す一方で、 dcat:CatalogRecord はカタログにおけるリソースの登録を記述する レコードであることに注意。dcat:CatalogRecord の使用は任意とみなされる。 これは、カタログ内のエントリに関する来歴情報を明示的に取得するために使用される。 これが不要であれば、dcat:CatalogRecord は安全に無視できる。

DCAT語彙は、[RDF-SCHEMA] を用いて形式化されたOWL2オントロジー [OWL2-OVERVIEW] である。 DCATの各クラスおよびプロパティは、IRI [RFC3987] によって示される。 ローカルに定義された要素は、名前空間 http://www.w3.org/ns/dcat# にある。 要素は、いくつかの外部語彙、特に [FOAF]、[DCTERMS] および [PROV-O] からも採用されている

RDFでは、リソースがグローバル識別子（IRI）を持つことも、 空白ノードであることもできる。 空白ノードは、IRIで明示的に名前を付けることなく リソースを示すために使用できる。 それらはトリプルの主語および目的語の位置に現れ得る [RDF11-PRIMER]。 たとえば、多くの実際のDCATカタログでは、配布は関連するデータセット記述内にネストされた空白ノードとして 表現される。 空白ノードはいくつかのユースケースに柔軟性を提供し得る一方で、Linked Dataの文脈では、 空白ノードはデータを協調的に注釈付けする能力を制限する。 空白ノードリソースはリンクの対象になることができず、新しい情報を新しいソースから注釈付けすることもできない。 Linked Dataアプローチの最大の利点の1つが「誰でもどこでも何でも言える」ことであるため、 空白ノードの使用は、RDFモデルの広範な採用から得られる利点の一部を損なう。 単一アプリケーションデータセットという閉じた世界の中でさえ、空白ノードの使用は、 新しいデータを統合する際にすぐ制限となり得る [LinkedDataPatterns]。 これらの理由から、DCATの主要クラスのインスタンスにはグローバル識別子を持たせることが推奨され、 RDFでDCATを符号化する際には、空白ノードの使用は一般に推奨されない。

この文書のすべてのRDF例はTurtle構文 [Turtle] で記述され、 その多くは DXWGコードリポジトリから 利用可能である。

この例は、政府カタログとそのデータセットを表現するためにDCATがどのように使用され得るかを 簡潔に概観するものである。言語タグの使用を示すため、タイトル、ラベルおよびキーワードは英語と スペイン語の両方で提供される。

まず、カタログの記述:

カタログの公開者は、相対 IRI ex:transparency-office を持つ。 公開者のさらなる記述は、例 2のように提供できる:

カタログは、dcat:dataset プロパティを通じて各データセットを列挙する。例 1では、相対 IRI ex:dataset-001 を持つ 例示データセットが言及された。DCATを用いたその可能な記述を以下に示す:

このデータセットには5つの異なる時間記述子が示されている。 データセットの公開日および改訂日は、dcterms:issued および dcterms:modified に示される。 dcterms:accrualPeriodicity におけるデータセット更新頻度には、 W3C Data Cube Vocabulary [VOCAB-DATA-CUBE] の取り組みの一部として開発された コンテンツ指向ガイドラインからのインスタンスを使用する。 時間的範囲または広がりは、dcterms:temporal で与えられ、 dcterms:PeriodOfTime を、dcat:startDate および dcat:endDate によって示される閉区間として定義する。 データセット内の項目の最小間隔を記述する時間解像度は、標準データ型 xsd:duration を用いて dcat:temporalResolution に与えられる。

さらに、空間的範囲または広がりは、dcterms:spatial で、Geonames からの IRI を用いて与えられる。 データセット内の項目の最小空間分離を記述する空間解像度は、 標準データ型 xsd:decimal を用いて dcat:spatialResolutionInMeters に与えられる。

データセットに関するコメントおよびフィードバックを送信できる連絡先が提供される。 メールアドレスや電話番号など、連絡先に関するさらなる詳細は、vCard [VCARD-RDF] を用いて 提供できる。

データセット ex:dataset-001-csv の1つの表現は、5kBのCSVファイルとしてダウンロードできる。 これは dcat:Distribution 型のRDFリソースとして表現される。

カタログは、相対 IRI ex:themes によって表される ドメインの集合に従って、そのデータセットを分類する。SKOS [SKOS-REFERENCE] は、 使用されるドメインを記述するために使用できる:

このデータセットが、相対 IRI ex:accountability によって表される ドメインの下に分類されていることに注意。 カタログのドメインを記述するために使用された IRI ex:themes によって識別される 概念スキームの一部として、その概念を定義することが推奨される。SKOS記述の例:

データセットの型またはジャンルは、dcterms:type プロパティを用いて示すことができる。 プロパティの値は、適切に管理され、広く認知されたリソース型の集合から取得することが推奨される。 たとえば、DCMI Type Vocabulary [DCTERMS]、 MARC Genre/Terms Scheme、 [ISO-19115-1] の MD_Scope codes、 DataCite resource types [DataCite]、 またはRe3dataのPARSE.Insight content-types [RE3DATA-SCHEMA] である。

次の例では、（名目上の）データセットが、異なる語彙からの値を用いて別々に分類される。

単一の記述内に複数の分類が存在することも可能である。

カタログ公開者が、自身のレコード（すなわち、データセットを記述するメタデータを含むレコード）を 記述するメタデータを保持することにした場合、dcat:CatalogRecord を使用できる。たとえば、 ex:dataset-001 は2011-12-05に発行されたが、Imaginary Catalog上のその記述は 2011-12-11に追加された。これは、例 9のようにDCATで表現できる:

ex:dataset-002 はCSVファイルとして利用可能である。しかし、ex:dataset-002 は、 ユーザーがいくつかのリンクをたどり、何らかの情報を提供し、いくつかのチェックボックスを選択してから データにアクセスする必要がある、何らかのWebページを通じてのみ取得できる。

dcat:landingPage の使用と、 dcat:Distribution インスタンスの定義に注意。

一方、ex:dataset-003 は、何らかのランディングページを通じて取得できるが、 既知のURLからダウンロードすることもできる。

ダウンロード可能な配布に dcat:downloadURL を使用し、 ランディングページを通じてアクセス可能な他の配布は、別個の dcat:Distribution インスタンスとして定義する必要がないことに注意。

ex:dataset-004 は、異なるサービスから異なる表現で配布される。 各 dcat:Distribution の dcat:accessURL は、そのサービスの dcat:endpointURL に対応する。 各サービスは、dcterms:type を用いて一般的な型によって特徴付けられ （ここではINSPIRE空間データサービス型語彙からの値を使用）、 dcterms:conformsTo を用いて具体的な API 定義によって特徴付けられ、 個別エンドポイントのパラメータおよびオプションの詳細な記述は dcat:endpointDescription を用いてリンクされる。

識別子がHTTP参照解決可能でない場合、相互運用性のために、共通識別子型をRDFデータ型 [RDF11-CONCEPTS] またはカスタムのOWLデータ型 [OWL2-SYNTAX] として提供できる。例 17の ex:type を参照。

登録済みの IRI 型が使用される場合 （[RFC3986]、 § 3.1 Scheme に従う）、識別子スキームは IRI の一部である。したがって、'type' で 別個の識別子スキームを示すことは冗長である。たとえば、DOIは info IRI スキーム [IANA-URI-SCHEMES] の名前空間として登録されている （DOI FAQ #11を参照）ため、 [RFC3986] に従えば、 例 18のように符号化すべきである。

それ以外の場合、識別子スキームの共通型（arXiv など）の例は、DataCite schema [DataCite] および FAIRsharing Registry で定義されている。

リソースの5つの時間プロパティをDCATを用いて記述できる。

1. リソースの公開時刻は、dcterms:issued を用いて与えられる。 値は通常、xsd:date として符号化される。
2. リソースの改訂または更新時刻は、dcterms:modified を用いて与えられる。 値は通常、xsd:date として符号化される。
3. リソースの更新スケジュールは、dcterms:accrualPeriodicity を用いて示される。 値は、Dublin Core Collection Description Frequency Vocabulary などの統制語彙から取得すべきである。
4. データセット内の項目の最小時間分離は、dcat:temporalResolution を用いて与えられる。 値は xsd:duration として符号化される。 以下に示すように、更新スケジュールと時間解像度を組み合わせて、さまざまな種類の時系列データの 記述をサポートできる。
5. データセットの時間的広がりは、dcterms:temporal を用いて与えられる。 値は dcterms:PeriodOfTime である。 dcterms:PeriodOfTime の詳細を表現するためのいくつかの選択肢は、 6.15 クラス: 期間で推奨されている。 これらの例を以下に示す。

データセットの2つの空間プロパティをDCATを用いて記述できる。

1. データセット内の項目の最小空間分離は、dcat:spatialResolutionInMeters を用いて与えられる。 値は10進数である。

   dcat:spatialResolutionInMeters の使用例は、例 3に示されている。

2. データセットの空間的広がりは、dcterms:spatial を用いて与えられる。 値は dcterms:Location である。 dcterms:Location の詳細を表現するためのいくつかの選択肢は、 6.16 クラス: 場所で推奨されている。

   これらの例を以下に示す。

DCATは、バージョン間の次の種類の関係をサポートする:

1. バージョン連鎖および階層（バージョン履歴）を示すもの。
2. あるバージョンが別のものによって置き換えられる/取って代わられるかどうかを示すもの。

前のセクションで説明した関係に加えて、バージョン化されたリソースには、たとえば 元のリソースとの差異（バージョン「デルタ」）、バージョン識別子、公開日を記述する 追加情報を関連付けてもよい。

これらの目的のために、DCATは次のプロパティを使用する:

• dcat:version（pav:version と等価 [PAV]）、 バージョン名/識別子のため;
• dcterms:issued [DCTERMS]、 バージョン公開日のため;

• adms:versionNotes [VOCAB-ADMS]、 リソースの前のバージョンとの後方互換性の問題を含む変更のテキスト記述のため。

次の例は、[DWBP] の Best Practice 7: Provide a version indicator にあるものを再利用し、バージョン情報をDCATでどのように指定できるかを示す。

リソースのライフサイクルは、バージョン管理に直交する側面であり、時には厳密に関連する。 リソースがそのライフサイクル（構想から作成および公開まで）に沿って進化することは、 新しいバージョンを生じさせる可能性があるが、常にそうであるとは限らない（例: 承認ワークフローが 存在する場合、改訂が不要であればリソースに変更が加わらないことがある）。同様に、 新しいバージョンの作成は、必ずしも状態の変化につながるとは限らない（例: 変更が実質的でない場合、 および/またはまだ開発中のリソースに実装される場合）。さらに、リソースが改訂 （誤りの修正、新しいコンテンツの追加など）によって置き換えられる場合、異なる ライフサイクル状態（例: 非推奨または撤回）へ移されることがある。

ライフサイクルに関するリソースの状態は、それ自体がしばしば重要な情報であることに注意する価値がある。 これはデータ提供者およびデータ消費者の双方の観点から重要である。データ消費者にとっては、 リソースがまだ開発中かどうか、および非推奨または撤回されているかどうか （そのような場合、使用すべき新しいバージョンがあるかどうか）を知ることが重要である。 一方、データ提供者にとっては、リソースにライフサイクル上の状態を付けることは、データ管理 ワークフローを正しく管理するために不可欠である。たとえば、リソースは公開される前に安定している 必要があり、場合によっては承認済みおよび/または登録済みとして示される必要がある。 最後に、リソースの実際の状態に加えて、リソースが別の状態へ移った時点 （例: 作成、レビュー、承認、公開された時点）も有用な情報である。

バージョン管理と同様に、リソースのライフサイクルは、コミュニティの実践、データ管理ポリシー、 および実施中のワークフローに依存する。さらに、異なるリソース型（例: データセットと カタログレコード）では、異なるライフサイクル状態を持つ場合がある。

ライフサイクル状態の指定について、DCATはプロパティ adms:status [VOCAB-ADMS] を、適切な [DCTERMS] の時間関連プロパティ （dcterms:created, dcterms:dateSubmitted, dcterms:dateAccepted, dcterms:dateCopyrighted, dcterms:issued, dcterms:modified, dcterms:valid）とともに使用する。しかし、DCATは特定のライフサイクル状態集合の 使用を規定せず、関連するアプリケーションシナリオに適した既存の標準およびコミュニティの 実践を参照する。

DCATのバージョン管理アプローチは、特定のコミュニティ、領域、およびリソース型で使用されているような 既存のバージョン管理実践と共存できる。

例として、次の表は、DCATのバージョン管理プロパティと、類似の概念を指定するために最も頻繁に 使用される語彙、すなわちオントロジー向けのOWL、 [DCTERMS]、および [PROV-O] との対応を示す。

対応は等価性を意味しないことに注意。これらのプロパティは異なる範囲とセマンティクスを持つため、 互いに補完できるが置き換えることはできない。特に、OWLプロパティは owl:Ontology として型付けできるリソース上で使用されることを意図している一方、 [DCTERMS] のものは、（版や改作を含む）非常に広い バージョンの概念を使用する。一方、DCATのバージョン管理プロパティは カタログ内の任意のリソースで使用されることを意図しており、11. バージョン管理の導入で説明したように、非常に具体的なバージョンの概念を使用する。 最後に、[PROV-O] プロパティ prov:wasRevisionOf は、意味的には dcat:previousVersion に類似しているが、 バージョン連鎖を構築するために使用されることを明示的には意図していない。一方、 prov:generalizationOf および prov:specializationOf は、それぞれの サブプロパティ dcat:hasVersion および dcat:isVersionOf よりも 意味的に広い。

次の例は、DCAT 3のバージョン管理にDCATとOWLを補完的にどのように使用できるかを示す [VOCAB-DCAT-2]。

DCATは、新しいクラス dcat:DatasetSeries を導入することにより、 データセット系列をデータカタログの第一級市民にする。このクラスは dcat:Dataset のサブクラスとして定義される。 データセットは、プロパティ dcat:inSeries を用いてデータセット系列にリンクされる。 データセット系列は階層的にもなり得て、データセット系列が別のデータセット系列のメンバーに なり得ることに注意。

データセット系列は、新しいデータセットを取得することによって、時間の経過とともに発展し得る。 たとえば、年次予算データに関するデータセット系列は、毎年新しい子データセットを取得する。 そのような場合、年次リリースを、最初、前、次、および最新のものを指定する関係で リンクすることが重要になり得る。このようなシナリオでは、DCATはそれぞれプロパティ dcat:first, dcat:prev, および dcat:last を使用する。dcat:next については 7. 逆プロパティの使用を参照。

系列内のデータセットは、もちろんバージョン化できる。そのような場合、データセットは 11.1.1 バージョン連鎖と階層で説明されたアプローチを用いて そのバージョンにリンクできる。これは 例 39に示されている。

データセット系列に関するプロパティは、2つのグループに分類できる。

第1のグループは、データセット系列自体を記述するプロパティに関するものである。たとえば、 プロパティ dcterms:accrualPeriodicity は この場合に該当し、その値は新しい子データセットが追加される頻度に対応すべきである。

第2のグループは、上流継承、すなわち子データセットのプロパティ値が親 （データセット系列）に継承されることを通じて、子データセットメタデータで記述される 次元を反映するプロパティに関するものである。

典型的には、これは、関連する各プロパティについて、データセット系列が子データセットで 指定された値の和集合を値として取ることを意味する。たとえば:

• 子データセットの時間的範囲が異なる年、たとえば2018年、2019年、2020年である場合、 系列の時間的範囲は2018年から2020年までの期間になる。
• 子データセットが空間的範囲として異なる地理的境界ボックスを持つ場合、系列の空間的範囲は これらの境界ボックスの和集合（すなわち、子データセットのものを含む境界ボックス）になる。
• 各子データセットが異なる空間参照系を使用する場合、データセット系列は複数の空間参照系を持つ。

最後に、子データセットの一部の注釈プロパティも、データセット系列のレベルで考慮する必要がある場合がある。 特に、子データセットの作成/公開/更新日に関するプロパティは、系列内の対応するものに影響し得る。 これらのプロパティについて、DCATは次のアプローチを推奨する:

• データセット系列の作成日（dcterms:created）は、子データセットの最も早い作成日に対応すべきである。
• データセット系列の公開日（dcterms:issued）は、 子データセットの最も早い公開日に対応すべきである。
• データセット系列の更新日（dcterms:modified）は、 子データセットの最新の公開日または更新日に対応すべきである。

既存のDCAT実装は、データセット系列を指定するために主に2つの代替アプローチを採用している:

1. データセット系列は dcat:Dataset として型付けされ、その子データセットは dcat:Distribution として型付けされる。
2. データセット系列とその子データセットの両方が dcat:Dataset として型付けされ、 両者は通常、[DCTERMS] プロパティ dcterms:hasPart / dcterms:isPartOf を用いてリンクされる。

どちらの場合も、データセット系列は、[DCTERMS] プロパティ dcterms:type を用いてソフト型付けされることがある（例: これは [GeoDCAT-AP] で使用されるアプローチであり、[DCAT-AP-IT] および [GeoDCAT-AP-IT] で採用されている）。

これらの選択肢はDCATと形式的に非互換ではないため、DCAT 3へのアップグレード中に dcat:DatasetSeries と共存できる。

データ消費者（ex:consumer1）は、ジェノヴァのバス停の地理参照付きリストを含む データセット ex:genoaBusStopsDataset の品質を記述する。その消費者は、 データ完全性（ldqd:completeness）に関するDQV品質注記 （ex:genoaBusStopsDatasetCompletenessNote）をデータセットに注釈として付け、 既存の30000停留所のうち20500停留所のみが含まれていることを警告する。

活動 ex:myQualityChecking は、サービス ex:myQualityChecker を用いて ex:genoaBusStopsDataset データセットの品質を検査する。 メトリック ex:completenessWRTExpectedNumberOfEntities は、データセット完全性 （ldqd:completeness）を測定するために適用され、その結果として品質測定 ex:genoaBusStopsDatasetCompletenessMeasurement が得られる。

品質文書化の他の例は [VOCAB-DQV] で利用可能であり、 そこにはデータセットの 正確性および精度をどのように表現するかに関する例も含まれる。

このセクションでは、[VOCAB-DQV] を [PROV-O] および EARL [EARL10-Schema] と組み合わせ、 表明された品質標準への適合度および適合性テストに関する詳細を表現するための、 異なるモデリングパターンを示す。

標準的な [DCTERMS] プロパティである dcterms:contributor、dcterms:creator および dcterms:publisher、ならびに [PROV-O] の汎用的な prov:wasAttributedTo は、 責任を持つエージェントとカタログ化リソースとの基本的な関連付けをサポートする。 しかし、データセットおよびサービスに関して重要な役割は他にも多く存在する。たとえば、 資金提供者、配布者、管理者、編集者などである。 これらの役割の一部は、[ISO-19115-1] の CI_RoleCode 値、[DataCite] メタデータスキーマ、および MARC relators に列挙されている。

指定された役割を持つエージェントをリソースに割り当てる一般的な方法は、 [PROV-O] の修飾形式 prov:qualifiedAttribution を用いることで提供される。 例 53 はその説明を提供する:

例 53では、役割は [ISO-19115-1] の CI_RoleCode コードリストの非規範的で参照解決不能な表現からの IRI によって示される （例: urn:example:isotc211/CI_RoleCode のようなURN）。 Linked Dataとして参照解決可能で規範的な表現が利用可能な場合は、それを優先すべきである。

標準的な [DCTERMS] プロパティ dcterms:relation および次のような サブプロパティ: dcterms:hasPart / dcterms:isPartOf, dcterms:hasVersion / dcterms:isVersionOf, dcterms:replaces / dcterms:isReplacedBy, dcterms:requires / dcterms:isRequiredBy, prov:wasDerivedFrom, prov:wasQuotedFrom は、データセットと他のカタログ化リソースとの関係の記述をサポートする。 しかし、他にも重要な関係は多く存在する。たとえば、alternate、canonical、original、 preview、stereo-mate、working-copy-of などである。 これらの役割の一部は、[ISO-19115-1] の DS_AssociationTypeCodes 値、IANA Link Relations Registry [IANA-RELATIONS]、 [DataCite] メタデータスキーマ、および MARC relators に列挙されている。

指定された役割を持つリソースを別のリソースに関連付ける一般的な方法は、 修飾形式 dcat:qualifiedRelation を用いることで 提供される。 例 54 は説明を提供する:

例 54では、役割は [IANA-RELATIONS] からの IRI と、[ISO-19115-1] の DS_AssociationTypeCode コードリストの（非規範的な）linked data表現からの IRI によって示される。