CyberLibrarian

【注意】 このドキュメントは、W3CのData Catalog Vocabulary (DCAT) - Version 2 W3C Recommendation 04 February 2020の和訳です。
このドキュメントの正式版はW3Cのサイト上にある英語版であり、このドキュメントには翻訳に起因する誤りがありえます。誤訳、誤植などのご指摘は、訳者までお願い致します。

First Update: 2020年3月7日

データ・カタログ語彙(DCAT) - 第2版

W3C勧告

本バージョン:
https://www.w3.org/TR/2020/REC-vocab-dcat-2-20200204/
最新公開バージョン:
https://www.w3.org/TR/vocab-dcat-2/
最新編集者草案:
https://w3c.github.io/dxwg/dcat/
実装報告書:
https://w3c.github.io/dxwg/dcat-implementation-report/
旧バージョン:
https://www.w3.org/TR/2019/PR-vocab-dcat-2-20191119/
旧勧告:
https://www.w3.org/TR/2014/REC-vocab-dcat-20140116/
編集者:
Riccardo Albertoni (CNR - Consiglio Nazionale delle Ricerche, Italy)
David Browning (Refinitiv)
Simon Cox (CSIRO)
Alejandra Gonzalez Beltran (Scientific Computing Department, Science and Technology Facilities Council, UK) (Previously at the University of Oxford)
Andrea Perego (European Commission, Joint Research Centre)
Peter Winstanley (Scottish Government)
旧編集者:
Fadi Maali (DERI)
John Erickson (Tetherless World Constellation (RPI))
参加可能:
GitHub w3c/dxwg
File a bug
Commit history
Pull requests
貢献者:
Makx Dekkers

公開以後に報告されたエラーや問題がないか正誤表を確認してください。

翻訳版も参照してください。

このドキュメントは、規範以外の形式でも入手できます: Turtle

Copyright © 2020 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and permissive document license rules apply.

注

要約

DCATは、ウェブ上で公開されたデータ・カタログ間の相互運用性の促進を目的とするRDFの語彙です。このドキュメントでは、その利用のために、スキーマを定義し、例を提供します。

DCATにより、公開者は、複数のカタログのメタデータの利用と集約を促進する標準的なモデルと語彙を用いてカタログ内にデータセットとデータ・サービスを記述できます。これにより、データセットとデータ・サービスの発見可能性が向上します。また、データ・カタログの公開に関して分散アプローチを可能にし、同じクエリ・メカニズムと構造を用いて複数サイトのカタログにまたがるデータセットの統合検索を可能にします。集約されたDCATメタデータは、デジタル保存プロセスの一部としてのマニフェスト・ファイルとして使用できます。

DCAT用語の名前空間はhttp://www.w3.org/ns/dcat#です。

DCAT名前空間の推奨接頭辞はdcatです。

このドキュメントのステータス

この項は、このドキュメントの公開時のステータスについて記述しています。他のドキュメントがこのドキュメントに取って代わることがありえます。現行のW3Cの刊行物およびこの技術報告の最新の改訂版のリストは、https://www.w3.org/TR/のW3C技術報告インデックスにあります。

このドキュメントでは、元のDCAT語彙([VOCAB-DCAT-20140116])の公開以後の新たなユースケース、要件、およびコミュニティの経験に対応した主な改訂について定義しています。この改訂は、コミュニティの慣行に沿って元のDCAT標準を拡張すると同時に、データ記述とデータセット交換に対する多様なアプローチをサポートします。DCAT語彙の主な変更点は次のとおりです。

この新しいバージョンの語彙は、元の語彙を更新・拡張しますが、下位互換性を維持しています。重要な変更点の完全なリスト(関連するgithubの課題へのリンク付き)を§ D. 変更履歴に記述しています。

CRの終了基準は、不足している必要な要素を改善する方法としてv1のアプリケーション・プロファイルに含まれていた機能を再現するv2の新機能に焦点を当てています。終了基準には、EC Joinupなどの組織がその取り組みにおいてDCAT v2モデルを採用するという最近のコミットメントも含まれていました。カタログの実装における新しいプロパティー/クラス(または同等の意味を持つ用語)の使用を示すことにより、実装が証明されます。

Data eXchangeワーキンググループによって検討され議論されたものの、成熟度やコンセンサスが不足していたために対処されていなかった課題、要件、機能は、GitHubに集められています。将来のリリース時に優先されると考えられるものは、DCATの将来の優先的取り組みというマイルストーンに含まれています。

DCATの変遷

元のDCAT語彙はDERI(Digital Enterprise Research Institute)で開発・提供された後に、eGov Interest Groupによって精緻化され、2014年[VOCAB-DCAT-20140116]にGLD(Government Linked Data)ワーキンググループによって最終的に標準化されました。

この改訂版のDCATは、元のバージョン以後のDCAT語彙に関する人々の経験から集められた新たなユースケースと要件[DCAT-UCR]や、最初のバージョンでは考慮されていなかった新しいアプリケーションに対応して、Dataset Exchangeワーキンググループによって開発されました。[VOCAB-DCAT-20140116]以後の変更の要約を§ D. 変更履歴に記載しています。

外部の用語

DCATには、foaf:homepageやdct:titleなどの、適切な意味を持つ安定した用語を備えた既存の語彙の用語が組み込まれています。利便性を考慮し、外部で定義された用語の非公式な定義の要約をDCAT語彙に記載していますが、正式な定義は規範的な参考文献にあります。参考文献の定義に変更があった場合は、この仕様で記載している要約が優先します。DCATへの適合性(§ 4. 適合性)はDCAT語彙仕様の用語の使用のみに関係するため、他の外部の定義に変更があったとしても、DCAT実装の適合性には影響しないことに注意してください。

コメントの送信

ワーキンググループは、公開者が、このドキュメントで記述している改訂版のDCATを用いて自身のカタログとデータセットを記述し、DCATの改訂後の実装報告に関する指示に従って実装報告を行うように要請しました。この情報とその後の分析は、実装報告書で公開しています。

このドキュメントは、Dataset Exchangeワーキンググループによって勧告として公開されました。

このドキュメントは、W3Cメンバー、ソフトウェア開発者、他のW3Cグループ、および他の利害関係者によりレビューされ、W3C勧告として管理者の協賛を得ました。これは確定済みドキュメントであり、参考資料として用いたり、別のドキュメントで引用することができます。勧告の作成におけるW3C の役割は、仕様に注意を引き付け、広範囲な開発を促進することです。これによってウェブの機能性および相互運用性が増強されます。

この仕様の議論にはGitHubの課題をお勧めします。または、メーリング・リストにコメントを送信することもできます。コメントはpublic-dxwg-comments@w3.org(アーカイブ)に送信してください。

ワーキンググループの実装報告書を参照してください。

このドキュメントは、W3C特許方針の下で活動しているグループによって作成されました。W3Cは、このグループの成果物に関連するあらゆる特許の開示の公開リストを維持し、このページには特許の開示に関する指示も含まれています。不可欠な請求権(Essential Claim(s))を含んでいると思われる特許に関して実際に知っている人は、W3C特許方針の6項に従って情報を開示しなければなりません。

このドキュメントは、2019年3月1日のW3Cプロセス・ドキュメントによって管理されています。

1. はじめに

この項は非規範的です。

様々な組織、研究者、政府、市民の間でデータ資源を共有するには、メタデータの提供が必要です。これは、データが公開されているかどうかは関係ありません。DCATは、本来はdata.govやdata.gov.ukなどの政府データ・カタログのコンテキストで開発されたデータ・カタログをウェブで公開するための語彙ですが、他のコンテキストにも適用可能であり、使用されています。

この改訂版のDCATは、以前のバージョンを拡張し、さらなるユースケースと要件をサポートしています[DCAT-UCR]。それらには、データ・サービスなどの、データセットに加えて他の資源をカタログ化する可能性が含まれています。この改訂版では、データセット間およびデータセットと他のカタログ化された資源間の関係の記述もサポートしています。カタログ化されたアイテムに関するライセンスと権利のステートメントをドキュメント化する方法に関する手引きを提供しています。

DCATは、データセットとデータ・サービスを記述してカタログに含めることができるように、RDFのクラスとプロパティーを提供します。標準的なモデルと語彙を用いることにより、複数のカタログのメタデータの利用と集約が容易になり、それによって次が可能になります。

  1. データセットとデータ・サービスの発見可能性を向上させる。
  2. 複数サイトのカタログにまたがるデータセットの統合検索を可能にする。

カタログに記述されたデータは、スプレッドシートから、XMLやRDF、様々な特化形式に至るまで、多くの形式で提供されます。DCATは、これらのデータセットのシリアル化形式については何も仮定しませんが、抽象的なデータセットとその様々なマニフェストや配信とを区別します。

多くの場合、データは、抽出物、サブセット、または既存のデータの組み合わせの選択、またはデータ処理機能によって生成された新しいデータの選択をサポートするサービスを通じて提供されます。DCATでは、データ・アクセス・サービスの記述をカタログに含めることができます。

形式固有のより詳細な情報を提供するために、補足的な語彙をDCATと一緒に用いることができます。例えば、データセットがRDF形式であれば、データセットに関する様々な統計を表すために、DCAT内でVoID語彙[VOID]のプロパティーを使用できます。

このドキュメントでは、DCATで表現されるデータ・カタログの特定の展開方法を規定していません。DCATの情報は、SPARQLエンドポイントからアクセス可能なRDF、[HTML-RDFa]としてHTMLページに組み込んだもの、またはRDF/XML[RDF-SYNTAX-GRAMMAR]、[N3]、[Turtle]、[JSON-LD]やその他の形式としてシリアル化したものを含む多くの形式で提示できます。このドキュメントの例では、読みやすいという理由で、[Turtle]を用いています。

2. 変更の動機

この項は非規範的です。

2014年1月に公開された当初の勧告[VOCAB-DCAT-20140116]では、データセットを記述するための基本的なフレームワークを提供しました。そこでは、抽象的なアイデアとしてのデータセットと、データセットのマニフェストとしての配信とを大きく区別しました。DCATは広く採用されてきましたが、当初の仕様には、欧州委員会のDCAT-AP[DCAT-AP]などのプロファイルのメカニズム、または保健医療と生命科学コミュニティ・プロファイル(Healthcare and Life Sciences Community Profile)[HCLS-Dataset]、データ・タグ・スイート(Data Tag Suite)[DATS]などの基本的な標準に基づいて構築された大規模な語彙の開発のいずれかによって追加された多くの本質的な機能が欠けていることが明らかになりました。この改訂版のDCATは、様々なコミュニティの経験を通じて明らかになった特定の欠点に対処するために開発されました。その目的は、これらのより大規模な語彙のアウトプット間の相互運用性を改善することです。例えば、この新しいDCATのバージョンでは、識別子、データセット品質情報、およびデータ引用の課題に対処するために、クラス、プロパティー、指針を提供しています。

この改訂には、仕様全体の書き換えが含まれています。2014勧告からの重要な変更点は、§ D. 変更履歴での記述に加え、「注」の項を用いて本文内で記しています。

3. 名前空間

DCATの名前空間はhttp://www.w3.org/ns/dcat#です。DCATは、他の語彙、特にダブリン・コア[DCTERMS]の用語を広範囲に用いていることに注意してください。DCATは、最小限の独自のクラスとプロパティーを定義しています。

3.1 規範的な名前空間

この勧告の規範的な部分で用いている名前空間と接頭辞を次の表で示します。

接頭辞 名前空間
dc http://purl.org/dc/elements/1.1/
dcat http://www.w3.org/ns/dcat#
dct http://purl.org/dc/terms/
dctype http://purl.org/dc/dcmitype/
foaf http://xmlns.com/foaf/0.1/
locn http://www.w3.org/ns/locn#
odrl http://www.w3.org/ns/odrl/2/
owl http://www.w3.org/2002/07/owl#
prov http://www.w3.org/ns/prov#
rdf http://www.w3.org/1999/02/22-rdf-syntax-ns#
rdfs http://www.w3.org/2000/01/rdf-schema#
skos http://www.w3.org/2004/02/skos/core#
time http://www.w3.org/2006/time#
vcard http://www.w3.org/2006/vcard/ns#
xsd http://www.w3.org/2001/XMLSchema#

3.2 非規範的な名前空間

この項は非規範的です。

勧告の規範的な部分ではなく、ドキュメントの例とガイドラインで用いている名前空間と接頭辞を次の表で示します。

接頭辞 名前空間
adms https://www.w3.org/ns/adms#
dqv http://www.w3.org/ns/dqv#
earl http://www.w3.org/ns/earl#
geosparql http://www.opengis.net/ont/geosparql#
oa http://www.w3.org/ns/oa#
sdmx-attribute http://purl.org/linked-data/sdmx/2009/attribute#
sdo https://schema.org/
w3cgeo http://www.w3.org/2003/01/geo/wgs84_pos#

4. 適合性

非規範的と記している項と同じく、この仕様のすべての作成ガイドライン、図、例、注は、非規範的です。この仕様のその他の部分はすべて規範的です。

このドキュメントの「することができる／してもよい(MAY)」、「しなければならない(MUST)」、「してはならない(MUST NOT)」、「すべきである／する必要がある(SHOULD)」というキーワードは、ここで示しているとおり、すべて大文字で表示される場合にのみ、BCP 14[RFC2119] [RFC8174]で記述されているように解釈されるべきです。

データ・カタログは、次の場合にDCATに準拠しています。

DDCATに準拠したカタログが、カタログのRDF記述に、追加の非DCATメタデータ・フィールドと追加のRDFデータを含むことができる(MAY)。

DCATプロファイルは、DCATに制約を追加するデータ・カタログのための仕様です。プロファイルに準拠しているデータ・カタログは、DCATにも準拠しています。プロファイルの追加の制約には、次のものを含むことができます(MAY)。

注

5. 語彙の概要

この項は非規範的です。

5.1 DCATの範囲

DCATは、データ・カタログを表すためのRDF語彙です。DCATは、次の8つの主要なクラスに基づいています(図1)。

DCATのクラスとプロパティーのUMLモデル
図1 DCATモデルの概要。カタログのメンバーになりえる資源のクラスと、それらの間の関係を示している。
注

DCATのデータセットは、「1つのエージェントによって公開またはキュレーションされ、1つ以上のシリアル化または形式でアクセスまたはダウンロードできるデータのコレクション」と定義されています。データセットは概念的なエンティティーであり、データセットの転送用にシリアル化した1つ以上の配信で表すことができます。データセットの配信は、データ・サービスを介して提供できます。

通常、データ・サービスは、サービスにローカルまたはリモートで提供される可能性のあるデータセットに対し、選択、抽出、組み合わせ、処理、または変換の操作を提供します。データ・サービスへのリクエストの結果は、データセットまたはカタログの一部またはすべての表現です。データ・サービスは、特定のデータセットに関連付けられていたり、リクエスト時や実行時にその情報源データが設定されたりする場合があります。データ配信サービスにより、データセットやサブセットの配信を選択しダウンロードすることができます。データ発見サービスにより、クライアントは適切なデータセットを見つけることができます。その他の種類のデータ・サービスには、座標変換サービス、再サンプリングや補間サービス、シミュレーションやモデリングのサービスを含む様々なデータ処理サービスなどのデータ変換サービスが含まれます。DCATのデータ・サービスは、データへのアクセスを提供する操作のコレクションまたはAPIであることに注意してください。多くの場合、APIの操作に便利にアクセスできるように、インタラクティブなユーザ・インターフェースが利用できますが、それに関する説明はDCATの範囲外です。多くの場合、特定のデータ・サービスのエンドポイントに関する詳細は、標準的なサービス型に準拠した記述で指定され、それによってDCAT語彙自体の範囲が補完されます。

データセットとデータ・サービスの記述をカタログに含めることができます。カタログはデータセットの一種で、そのメンバーのアイテムはデータセットとデータ・サービスの記述です。他の種類のものもカタログ化できる可能性がありますが、DCATの範囲は現在、データセットとデータ・サービスに限定されています。カタログの範囲をデータセットとデータ・サービス以外に拡張するためには、DCATプロファイルやその他のDCATアプリケーションでdcat:Resourceという追加のサブクラスを定義することをお勧めします。サービス記述の範囲をデータ配信サービス以外に拡張するためには、DCATプロファイルやその他のDCATアプリケーションでdcat:DataServiceという追加のサブクラスを定義することをお勧めします。

注

カタログ・レコードは、カタログ内のエントリーを記述したものです。dcat:Resourceはデータセットまたはサービス自体を表しますが、dcat:CatalogRecordはカタログ内のアイテムの登録を記述したレコードです。dcat:CatalogRecordの使用はオプションと考えられています。これは、カタログのエントリーに関する来歴情報を明示的に記録するために用います。必要ではない場合は、dcat:CatalogRecordは安全に無視できます。

5.2 RDFに関する留意点

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

RDFでは、資源は、グローバル識別子(IRI)を持ったり、空白ノードにしたりすることができます。空白ノードは、資源をIRIで明示的に指定せずに示すために使用できます。これは、トリプルの主語と目的語の位置に出現可能です[RDF11-PRIMER]。例えば、実際の多くのDCATカタログでは、配信は、関連するデータセットの記述内に入れ子にされた空白ノードとして表されます。空白ノードは一部のユースケースに柔軟性を提供しますが、リンクト・データのコンテキストでは、空白ノードは共同でデータにアノテーションを付与する機能を制限します。空白ノードの資源をリンクのターゲットにすることはできず、新しい情報源からの新しい情報でアノテーションを付与することはできません。リンクト・データのアプローチの最大の利点の1つは「誰でも、何でも、どこでも発言できる」ことであるため、空白ノードを用いると、RDFモデルを広く採用することにより得られる利点の一部が損なわれます。1つのアプリケーションのデータセットの閉世界内であっても、新しいデータを統合する場合は、空白ノードの使用はすぐに制限的になる可能性があります[LinkedDataPatterns]。これらの理由から、DCATの主なクラスのインスタンスにはグローバル識別子を用いることをお勧めします。また、RDFでDCATをエンコードする場合は、一般的に空白ノードの使用は推奨されません。

このドキュメントのすべてのRDFの例はTurtle構文[Turtle]で記述されており、多くはDXWGコード・リポジトリで入手できます。

注

5.3 基本的な例

この例では、政府のカタログとそのデータセットを表すために、どのようにDCATを用いるかの概要を提供します。

まず、カタログの記述は次のとおりです。

カタログの公開者は、:transparency-officeという相対URIを持っています。公開者の詳細な記述は、 例2のように提供できます。

カタログでは、その個々のデータセットをdcat:datasetプロパティーで列挙します。例1では、データセットの例を:dataset-001という相対URIで記述しました。DCATを用いた記述は、次のようになりえます。

このデータセットには、5つの異なる時間記述子が記述されています。データセットの公開日と改訂日は、dct:issuedとdct:modifiedで示されています。dct:accrualPeriodicity内のデータセットの更新頻度には、W3Cデータ・キューブ語彙[VOCAB-DATA-CUBE]の取り組みの一環として開発されたコンテンツ指向ガイドラインのインスタンスを用いることにしました。時間の範囲は、data.gov.ukのIntervalデータセット(本来はhttp://reference.data.gov.uk/id/intervalから入手可能)のアイテムを用いて、dct:temporalで指定しています。データセット内のアイテムの最小間隔を記述する時間分解能は、標準的なデータ型であるxsd:durationを用いてdcat:temporalResolutionで指定しています。

さらに、空間範囲は、GeonamesのURIを用いてdct:spatialで指定しています。データセット内のアイテムの最小空間分離を記述する空間分解能は、標準的なデータ型であるxsd:decimalを用いてdcat:spatialResolutionInMetersで指定しています。

データセットに関するコメントやフィードバックを送信できる場合には、窓口が提供されます。メール・アドレスや電話番号などの窓口に関する詳細は、vCard[VCARD-RDF]を用いて提供できます。

データセットの1つの表現である:dataset-001-csvは、5KBのCSVファイルとしてダウンロードできます。これは、dcat:Distributionという型のRDF資源として表されます。

5.4 データセットのテーマ別分類

カタログは、:themesという相対URIで表される定義域により、そのデータセットを分類します。次のように、SKOS[SKOS-REFERENCE]で、用いる定義域を記述できます。

このデータセットは、:accountabilityという相対URIで表される定義域のもとに分類されていることに注意してください。カタログの定義域を記述するために用いた:themesというURIで識別される概念スキームの一部として概念を定義することをお勧めします。下記は、SKOS記述の例です。

5.5 データセット型の分類

データセットの型やジャンルは、dct:typeというプロパティーを用いて示すことができます。プロパティーの値は、DCMI型語彙[DCTERMS]、MARCジャンル/用語スキーム、[ISO-19115-1]のMD_Scope codes、DataCite資源型、またはRe3dataのPARSE.Insightコンテンツ型[RE3DATA-SCHEMA]などの、よく管理され、広く認識されている資源型を採用することをお勧めします。

次の例では、様々な語彙の値を用いて(概念的な)データセットを個別に分類しています。

1つの記述内に複数の分類を存在させることも可能です。

5.6 カタログ・レコードのメタデータの記述

カタログの公開者がそのレコードについて記述したメタデータ(つまり、データセットについて記述したメタデータが含まれているレコード)を保持することにした場合には、dcat:CatalogRecordを使用できます。例えば、:dataset-001は2011-12-05に発表されましたが、Imaginary Catalogのその記述は、2011-12-11に追加されました。これは、DCATでは例9のように表すことができます。

5.7 ウェブ・ページの背後でしか利用できないデータセット

:dataset-002はCSVファイルとして利用できます。しかし、:dataset-002は、データにアクセスする前に、ユーザがいくつかのリンクをたどり、情報を提供し、いくつかのボックスにチェックを入れる必要があるウェブ・ページでのみ入手できます。

dcat:landingPageの使用とdcat:Distributionというインスタンスの定義に注意してください。

5.8 ダウンロードおよびウェブ・ページの背後で利用できるデータセット

一方、:dataset-003は、あるランディング・ページで入手できるだけでなく、既知のURLからダウンロードすることもできます。

dcat:downloadURLをダウンロードできる配信とともに用いており、ランディング・ページからアクセスできる他の配信を、dcat:Distributionという別のインスタンスとして別途定義する必要がないことに注意してください。

5.9 サービスにより利用できるデータセット

:dataset-004は、様々なサービスから様々な表現で配信されています。dcat:Distributionごとのdcat:accessURLは、サービスのdcat:endpointURLに対応しています。個々のサービスの特徴は、dct:type(ここでは、INSPIRE空間データ・サービス型の語彙の値を使用)を用いた汎用的な型、dct:conformsToを用いた特定のAPIの定義で示され、dcat:endpointDescriptionを用いて、リンクされた個々のエンドポイントのパラメーターとオプションを詳細に記述しています。

6. 語彙の仕様

6.1 RDFの表現

(改訂版の)DCAT語彙は、RDFで利用できます。基本となる人工物であるdcat2.ttlは、コアDCAT語彙のシリアル化です。それと並んで、次のような、追加情報を提供するその他のRDFファイルがあります。

  1. 手引用に提供される、他の語彙との非規範的な連携
  2. 一部のコンテキストで役立ちえる、追加の公理
  3. DCATの2014バージョン[VOCAB-DCAT-20140116]に対応したdcat2014.ttlとdcat2014.rdfというファイル

6.2 他の語彙の要素

DCATでは、他の多くの語彙の要素を用いる必要があります。さらに、DCATは、通常のRDFS[RDF-SCHEMA]とOWL2[OWL2-OVERVIEW]の規則とパターンに従い、外部語彙の追加要素で拡張できます。

6.2.1 補足的な語彙

多くの補足的な語彙の要素をDCATと一緒に用いて、より詳細な情報を提供できます(MAY)。例えば、VoID語彙[VOID]のプロパティーにより、データセットがRDF形式であれば、DCATが記述されたデータセットに関する様々な統計の記述が可能となり、来歴オントロジー[PROV-O]のプロパティーを用いてデータセットやサービス、そして関連する活動とエージェントを生成したワークフローに関する詳細情報を提供でき、組織オントロジー[VOCAB-ORG]のクラスとプロパティーを用いて責任を有するエージェントに関する詳細な説明を追加できます。

6.2.2 要素の定義

DCAT名前空間にない用語の定義(定義域と値域を含む)は、ここでは便宜上提供しているだけであり、規範的であると考えてはなりません(MUST NOT)。これらの用語の正式な定義は、対応する仕様、つまり[DC11]、[DCTERMS]、[FOAF]、[PROV-O]、[RDF-SCHEMA]、[SKOS-REFERENCE]、[XMLSCHEMA11-2]および[VCARD-RDF]にあります。

6.3 クラス: Catalog(カタログ)

注

catalog record、has part、dataset、service、catalog、homepage、themesのプロパティーはこのクラスに固有です。

distribution、frequency、spatial/geographic coverage、spatial resolution、temporal coverage、temporal resolution、was generated byのプロパティーは、dcat:Datasetというスーパークラスから継承されます。

access rights、conforms to、contact point、creator、description、has policy、identifier、is referenced by、keyword/tag、landing page、license、catalog language、relation、rights、qualified relation、publisher、release date、theme/category、title、type/genre、update/modification date、qualified attributionのプロパティーは、dcat:Resourceというスーパークラスから継承されます。

RDFクラス: dcat:Catalog
定義: 資源に関するメタデータのキュレートされたコレクション(例えば、データ・カタログのコンテキストでのデータセットやデータ・サービス)
～のサブクラス: dcat:Dataset
使用上の注意: 通常、ウェブ・ベースのデータ・カタログは、このクラスの1つのインスタンスとして表されます。
参照: § 6.5 クラス: Catalog Record(カタログ・レコード)、§ 6.6 クラス: Dataset(データセット)

6.3.1 プロパティー: homepage(ホームページ)

RDFプロパティー: foaf:homepage
定義: カタログのホームページ(通常HTMLで利用できる公開ウェブ・ドキュメント)。
値域: foaf:Document
使用上の注意: foaf:homepageは、それが一意であり、正確に資源のウェブ・ページを識別しなければならない(MUST)ことを意味する逆関数型プロパティー(IFP;inverse functional property)です。このプロパティーは正規のウェブ・ページを示し、資源に関するウェブ・ページが複数ある場合に役立ちます。

6.3.2 プロパティー: themes(テーマ)

RDFプロパティー: dcat:themeTaxonomy
定義: カタログのデータセットとサービスを分類するために用いられる知識組織化体系(KOS;knowledge organization system)。
定義域: dcat:Catalog
値域: rdfs:Resource
使用上の注意: タクソノミーは、skos:ConceptScheme、skos:Collection、owl:Ontology、または同様のもので組織化することをお勧めします。それにより、各メンバーがIRIで示され、リンクト・データとして公開できます。

6.3.3 プロパティー: has part(～を部分として持つ)

注
RDFプロパティー: dct:hasPart
定義: カタログに列挙されるアイテム。
定義域: dcat:Catalog
値域: dcat:Resource
使用上の注意: これは、カタログのメンバーシップの最も一般的な述語です。利用可能な場合は、より特定的なサブプロパティーの使用をお勧めします。
参照: dct:hasPartのサブプロパティー、特にdcat:dataset、dcat:catalog、dcat:service。

6.3.4 プロパティー: dataset(データセット)

RDFプロパティー: dcat:dataset
定義: カタログに列挙されるデータのコレクション。
～のサブプロパティー: dct:hasPart
定義域: dcat:Catalog
値域: dcat:Dataset

6.3.5 プロパティー: service(サービス)

注
RDFプロパティー: dcat:service
定義: カタログに列挙されるサイトまたはエンドポイント。
～のサブプロパティー: dct:hasPart
定義域: dcat:Catalog
値域: dcat:DataService

6.3.6 プロパティー: catalog(カタログ)

注
RDFプロパティー: dcat:catalog
定義: このカタログのコンテキストにおいて内容が関心の対象であるカタログ。
～のサブプロパティー: dct:hasPart
定義域: dcat:Catalog
値域: dcat:Catalog

6.3.7 プロパティー: catalog record(カタログ・レコード)

RDFプロパティー: dcat:record
定義: カタログの一部である1つのデータセットまたはデータ・サービスの登録を記述しているレコード。
定義域: dcat:Catalog
値域: dcat:CatalogRecord

6.4 クラス: Cataloged Resource(カタログ化された資源)

注

access rights、conforms to、contact point、creator、description、has policy、identifier、is referenced by、keyword/tag、landing page、license、resource language、relation、rights、qualified relation、publisher、release date、theme/category、title、type/genre、update/modification date、qualified attributionというプロパティーはこのクラスに固有です。

RDFクラス: dcat:Resource
定義: 1つのエージェントによって公開またはキュレートされた資源。
使用上の注意: カタログ化されたすべての資源のクラスで、dcat:Dataset、dcat:DataService、dcat:Catalogおよびdcat:Catalogのその他のメンバーのスーパークラス。このクラスには、データセットやデータ・サービスなど、すべてのカタログ化された資源に共通するプロパティーが含まれます。より特定的なサブクラスの使用を強くお勧めします。dcat：Datasetまたはdcat：DataServiceではない資源を記述する場合は、dcat：Resourceの適切なサブクラスを作成するか、dct：typeプロパティーでdcat：Resourceを用いて特定の型を示すことをお勧めします。
使用上の注意: dcat:Resourceは、あらゆる種類のカタログの定義を可能にする拡張点です。追加のサブクラスは、DCATプロファイルや、その他の種類の資源のカタログ用の他のDCATアプリケーションで定義できます。
参照: § 6.5 クラス: Catalog Record(カタログ・レコード)

6.4.1 プロパティー: access rights(アクセス権)

注
RDFプロパティー: dct:accessRights
定義: 誰が資源にアクセスできるかに関する情報、またはそのセキュリティ・ステータスの表示。
値域: dct:RightsStatement
使用上の注意: ライセンスと権利に関する情報を資源に提供できます(MAY)。§ 8. ライセンスと権利のステートメントの手引きも参照してください。
参照: § 6.4.20 プロパティー: rights(権利)

6.4.2 プロパティー: conforms to(～に準拠)

注
RDFプロパティー: dct:conformsTo
定義: 記述されている資源が準拠する確立された標準。
値域: dct:Standard(「比較の基準。他のものを評価するための基準点。」[DCTERMS])
使用上の注意: カタログ化された資源コンテンツが準拠するモデル、スキーマ、オントロジー、ビュー、またはプロファイルを示すためにこのプロパティーを用いるべきです(SHOULD)。
注

6.4.3 プロパティー: contact point(窓口)

注
RDFプロパティー: dcat:contactPoint
定義: カタログ化された資源に対する関連窓口情報。vCardの使用を推奨します[VCARD-RDF]。
値域: vcard:Kind

6.4.4 プロパティー: resource creator(資源作成者)

注
RDFプロパティー: dct:creator
定義: 資源の作成に責任を持つエンティティー。
値域: foaf:Agent
使用上の注意: このプロパティーの値には、foaf:Agentという型の資源が推奨されます。
参照: § 6.11 クラス: Organization/Person(組織/人)
注

6.4.5 プロパティー: description(内容記述)

RDFプロパティー: dct:description
定義: 自由形式のテキストによるアイテムの説明。
値域: rdfs:Literal

6.4.6 プロパティー: title(タイトル)

RDFプロパティー: dct:title
定義: アイテムに与えられた名前。
値域: rdfs:Literal

6.4.7 プロパティー: release date(公表日)

RDFプロパティー: dct:issued
定義: アイテムの正式な発行(公開など)の日付。
値域: 関連するISO 8601の日付と時間[DATETIME]に準拠した文字列を用いてエンコードされ、適切なXMLスキーマ・データ型[XMLSCHEMA11-2]を用いて型付けされたrdfs:Literal(xsd:gYear、xsd:gYearMonth、xsd:date、またはxsd:dateTime)。
使用上の注意: このプロパティーは、判明している最初の発行日を用いて設定すべきです(SHOULD)。
参照: § 6.5.3 プロパティー: listing date(記載日)、§ 6.7.3 プロパティー: release date(公表日)

6.4.8 プロパティー: update/modification date(更新/修正日)

RDFプロパティー: dct:modified
定義: アイテムが変更、更新、修正された最も最近の日付。
値域: 関連するISO 8601の日付と時間[DATETIME]に準拠した文字列を用いてエンコードされ、適切なXMLスキーマ・データ型[XMLSCHEMA11-2]を用いて型付けされたrdfs:Literal(xsd:gYear、xsd:gYearMonth、xsd:date、またはxsd:dateTime)。
使用上の注意: このプロパティーの値は、カタログ・レコードに対する変更ではなく、実際のアイテムに対する変更を示します。値が存在しない場合は、最初に公開された後にアイテムが変更されていないか、最後の修正日が不明か、アイテムが常に更新されていることを示す可能性があります(MAY)。
参照: § 6.6.2 プロパティー: frequency(頻度)、§ 6.5.4 プロパティー: update/modification date(更新/修正日)、§ 6.7.4 プロパティー: update/modification date(更新/修正日)

6.4.9 プロパティー: language(言語)

RDFプロパティー: dct:language
定義: アイテムの言語。これは、カタログ化された資源(つまり、データセットまたはサービス)のテキスト形式のメタデータ(つまり、タイトル、内容記述など)またはデータセット配信のテキスト形式の値に用いられる自然言語を指します。
値域:

dct:LinguisticSystem

米国議会図書館(Library of Congress)が定義している資源(ISO 639-1、ISO 639-2)を用いるべきです(SHOULD)。

言語にISO 639-1(2文字)コードが定義されていれば、その対応するIRIを用いるべきで(SHOULD)、ISO 639-1コードが定義されていなければ、ISO 639-2(3文字)コードに対応するIRIを用いるべきです(SHOULD)。
使用上の注意: 資源が複数の言語で使用できる場合は、このプロパティーを繰り返してください。
使用上の注意: カタログ(つまり、データセットまたはサービス)のメンバーに提供された値が、カタログに提供された値よりも優先します(それらが競合する場合)。
使用上の注意: データセットの表現が言語ごとに別々に利用できる場合には、dcat:Distributionのインスタンスを言語ごとに定義し、dct:languageを用いて、個々の配信の特定の言語を記述してください(つまり、データセットは複数のdct:languageの値を持ち、個々の配信は、1つのみを、そのdct:languageプロパティーの値として持つでしょう)。

6.4.10 プロパティー: publisher(公開者)

注
RDFプロパティー: dct:publisher
定義: アイテムを利用可能にすることに責任を持つエンティティー。
使用上の注意: このプロパティーの値には、foaf:Agentという型の資源が推奨されます。
参照: § 6.11 クラス: Organization/Person(組織/人)

6.4.11 プロパティー: identifier(識別子)

RDFプロパティー: dct:identifier
定義: アイテムの一意の識別子。
値域: rdfs:Literal
使用上の注意: 識別子は、アイテムのURIの一部として用いられるかもしれませんが、それでもなお、明示的にそれを表すことは有用です。

6.4.12 プロパティー: theme/category(テーマ/カテゴリー)

注
RDFプロパティー: dcat:theme
定義: 資源の主要カテゴリー。資源は複数のテーマを持つことができます。
～のサブプロパティー: dct:subject
値域: skos:Concept
使用上の注意: 資源を分類するために用いられるskos:Conceptの集合は、カタログのすべてのカテゴリーとそれらの関係を記述しているskos:ConceptSchemeで組織化されます。
参照: § 6.3.2 プロパティー: themes(テーマ)

6.4.13 プロパティー: type/genre(タイプ/ジャンル)

注
RDFプロパティー: dct:type
定義: 資源の性質やジャンル。
～のサブプロパティー: dc:type
値域: rdfs:Class
使用上の注意: 値は、次のような、よく管理され、広く認識されている統制語彙を採用すべきです(SHOULD)。
  1. DCMI型語彙[DCTERMS]
  2. [ISO-19115-1]スコープ・コード
  3. Datacite資源型[DataCite]
  4. re3data.orgによって用いられているPARSE.Insightコンテンツ型[RE3DATA-SCHEMA](アイテム15のcontentTypeを参照)
  5. MARC知的資源型
これらの統制語彙の一部のメンバーは、データセットやデータ・サービス(例えば、DCMI型のイベント(Event)、物理的オブジェクト(PhysicalObject);[ISO-19115-1]の収集用機器(CollectionHardware)、収集作業(CollectionSession)、イニシアチブ(Initiative)、サンプル(Sample)、リポジトリ(Repository))に厳密には適していませんが、DCATプロファイルやアプリケーションで定義されている他の種類のカタログのコンテキストで用いられる場合があります。
使用上の注意: 資源のファイル形式、物理メディアや大きさを記述するためには、dct:format要素を用いてください。

6.4.14 プロパティー: resource relation(資源関係)

注
RDFプロパティー: dct:relation
定義: カタログ化されたアイテムに対する関係が指定されていない資源。
使用上の注意: dct:relationは、カタログ化されたアイテムと関連する資源との関係の性質が不明な場合に用いるべきです(SHOULD)。リンクの関係の性質が分かっている場合は、より特定的なサブプロパティーを用いるべきです(SHOULD)。dcat:Datasetからデータセットの表現にリンクするために、dcat:distributionというプロパティーを用いるべきです(SHOULD)(dcat:Distributionとして記述)。
参照: dct:relationのサブプロパティー、特にdcat:distribution、dct:hasPart、(および、そのサブプロパティーであるdcat:catalog、dcat:dataset、dcat:service)、dct:isPartOf、dct:conformsTo、dct:isFormatOf、dct:hasFormat、dct:isVersionOf、dct:hasVersion、dct:replaces、dct:isReplacedBy、dct:references、dct:isReferencedBy、dct:requires、dct:isRequiredBy

多くの既存のレガシーなカタログは、データセットのコンポーネント、表現、ドキュメント、スキーマ、およびデータセットの一部としてまとめられたその他の資源を区別しません。dct:relationは、より正確な関係を表す多くのより特定的なプロパティーのスーパープロパティーであるため、dct:relationの使用は、より特定的なセマンティクスを持った後続の再分類と矛盾しませんが、可能であれば、データセットをコンポーネントと補助資源にリンクするために、より特化したサブプロパティーを用いるべきです(SHOULD)。

6.4.15 プロパティー: qualified relation(修飾付き関係)

注
RDFプロパティー: dcat:qualifiedRelation
定義: 別の資源との関係に関する記述へのリンク
～のサブプロパティー: prov:qualifiedInfluence
定義域: dcat:Resource
値域: dcat:Relationship
使用上の注意: 関係の性質は分かっているけれども標準的な[DCTERMS]プロパティー(dct:hasPart、dct:isPartOf、dct:conformsTo、dct:isFormatOf、dct:hasFormat、dct:isVersionOf、dct:hasVersion、dct:replaces、dct:isReplacedBy、dct:references、dct:isReferencedBy、dct:requires、dct:isRequiredBy)または[PROV-O]プロパティー(prov:wasDerivedFrom、prov:wasInfluencedBy、prov:wasQuotedFrom、prov:wasRevisionOf、prov:hadPrimarySource、prov:alternateOf、prov:specializationOf)のどれとも一致しない場合に、別の資源にリンクするために用いられます。

このDCATプロパティーは、§ 13. 修飾付き関係で記述している一般的な修飾付き関係のパターンに従います。

注

6.4.16 プロパティー: keyword/tag(キーワード/タグ)

注
RDFプロパティー: dcat:keyword
定義: 資源を記述しているキーワードまたはタグ。
値域: rdfs:Literal

6.4.17 プロパティー: landing page(ランディング・ページ)

注
RDFプロパティー: dcat:landingPage
定義: カタログ、データセット、その配信および(または)追加情報にアクセスするためにウエブ・ブラウザでナビゲートできるウェブ・ページ。
～のサブプロパティー: foaf:page
値域: foaf:Document
使用上の注意: ランディング・ページを通じてしか配信にアクセスできない場合(つまり、直接的なダウンロードURLが不明な場合)には、配信におけるdcat:accessURLとしてランディング・ページのリンクをコピーすべきです(SHOULD)。(§ 5.7 ウェブ・ページの背後でしか利用できないデータセットを参照)

6.4.18 プロパティー: qualified attribution(修飾付き属性)

注
RDFプロパティー: prov:qualifiedAttribution
定義: 資源に対して何らかの形の責任を持つエージェントへのリンク
～のサブプロパティー: prov:qualifiedInfluence
定義域: prov:Entity
値域: prov:Attribution
使用上の注意: 関係の性質は分かっているけれども標準的な[DCTERMS]プロパティー(dct:creator、dct:publisher)のどれとも一致しない場合に、エージェントにリンクするために用いられます。資源に関してエージェントの責任を捕捉するために、prov:Attributionでdcat:hadRoleを用いてください。使用例に関しては、§ 13.1 データセットとエージェントの関係を参照してください。

このDCATプロパティーは、§ 13. 修飾付き関係で記述している一般的な修飾付き関係のパターンに従います。

注

6.4.19 プロパティー: license(ライセンス)

RDFプロパティー: dct:license
定義: 資源を利用可能にする法的ドキュメント。
値域: dct:LicenseDocument
使用上の注意: ライセンスと権利に関する情報を資源に提供できます(MAY)。§ 8. ライセンスと権利のステートメントの手引きも参照してください。
参照: § 6.4.20 プロパティー: rights(権利)、§ 6.7.5 プロパティー: license(ライセンス)

6.4.20 プロパティー: rights(権利)

RDFプロパティー: dct:rights
定義: 著作権表示など、dct:licenseやdct:accessRightsでは対処されないすべての権利に関する記述。
値域: dct:RightsStatement
使用上の注意: ライセンスと権利に関する情報を資源に提供できます(MAY)。§ 8. ライセンスと権利のステートメントの手引きも参照してください。
参照: § 6.4.19 プロパティー: license(ライセンス)、§ 6.7.7 プロパティー: rights(権利)、§ 6.4.1 プロパティー: access rights(アクセス権)

6.4.21 プロパティー: has policy(方針を持つ)

注
RDFプロパティー: odrl:hasPolicy
定義: 資源に関連付けられている権利を表すODRL適合の方針。
値域: odrl:Policy
使用上の注意: ODRL語彙[ODRL-VOCAB]を用いてODRL[ODRL-MODEL]の方針として表された権利に関する情報を資源に提供できます(MAY)。§ 8. ライセンスと権利のステートメントの手引きも参照してください。
参照: § 6.4.19 プロパティー: license(ライセンス) 、§ 6.4.1 プロパティー: access rights(アクセス権)、§ 6.4.20 プロパティー: rights(権利)

6.4.22 プロパティー: is referenced by(～に参照される)

注
RDFプロパティー: dct:isReferencedBy
定義: カタログ化された資源を参照、引用、またはその他の方法で指し示す、出版物などの関連資源。
使用上の注意: データ引用のユースケースに関して、カタログ化された資源がデータセットである場合、dct:isReferencedByというプロパティーにより、データセットを、そのデータセットを引用または指し示す資源(学術出版物など)に関連付けることができます。複数のdct:isReferencedByプロパティーを用いて、データセットが複数の出版物や他の資源によって参照されていることを示すことができます。
使用上の注意: このプロパティーは、資源を件の資源(dcat:Resourceという型)に関連付けるために用いられます。このプロパティーでカバーしていない資源とのその他の関係には、より汎用的なプロパティーであるdcat:qualifiedRelationを使用できます。§ 13. 修飾付き関係も参照してください。

このプロパティーの使用例に関しては、§ C.3 データセットと出版物のリンクを参照してください。

6.5 クラス: Catalog Record(カタログ・レコード)

conforms to、description、listing date、primary topic、title、update/modification dateのプロパティーはこのクラス(dcat:CatalogRecord)に固有です。

RDFクラス: dcat:CatalogRecord
定義: 1つのdcat:Resourceの登録を記述したカタログ内のレコード。
使用上の注意: このクラスはオプションであり、すべてのカタログがこれを用いるとは限りません。これは、データセットまたはサービスに関するメタデータとデータセットまたはサービスに関するカタログ内のエントリーに関するメタデータとが区別されるカタログのために存在しています。例えば、データセットの公開日のプロパティーは、公開機関が情報を最初に利用可能とした日付を示しますが、カタログ・レコードの公開日は、データセットがカタログに追加された日付です。両方の日付が異なっていたり、後者だけが分かっていたりする場合は、カタログ・レコードに対してのみ公開日を指定すべきです(SHOULD)。W3CのPROVオントロジー[PROV-O]を用いれば、データセットやその登録に対する特定の変更に関連するプロセスやエージェントの詳細などの、さらに詳しい来歴情報の記述が可能となることに注意してください。
参照: § 6.6 クラス: Dataset(データセット)

カタログが、名前付きグラフを有するRDFデータセットとして表されている場合は([SPARQL11-QUERY]で定義されているように)、個々のデータセット(dcat:Dataset、dcat:CatalogRecordおよび、そのdcat:Distributionのうちのいずれかを記述したすべてのRDFトリプルから成る)の記述は、別の名前付きグラフに置くのが適切です。そのグラフの名前は、カタログ・レコードのIRIであるべきです(SHOULD)。

6.5.1 プロパティー: title(タイトル)

RDFプロパティー: dct:title
定義: レコードに与えられた名前。
値域: rdfs:Literal

6.5.2 プロパティー: description(内容記述)

RDFプロパティー: dct:description
定義: 自由形式のテキストによるレコードの説明。
値域: rdfs:Literal

6.5.3 プロパティー: listing date(記載日)

RDFプロパティー: dct:issued
定義: 対応するデータセットやサービスをカタログに記載した(つまり、正式な記録)日付。
値域: 関連するISO 8601の日付と時間[DATETIME]に準拠した文字列を用いてエンコードされ、適切なXMLスキーマ・データ型[XMLSCHEMA11-2]を用いて型付けされたrdfs:Literal(xsd:gYear、xsd:gYearMonth、xsd:date、またはxsd:dateTime)。
使用上の注意: これは、データセット自体の公開日ではなく、カタログにデータセットを記載した日付を示します。
参照: § 6.4.7 プロパティー: release date(公表日)

6.5.4 プロパティー: update/modification date(更新/修正日)

RDFプロパティー: dct:modified
定義: カタログのエントリーが変更、更新、修正された最も最近の日付。
値域: 関連するISO 8601の日付と時間[DATETIME]に準拠した文字列を用いてエンコードされ、適切なXMLスキーマ・データ型[XMLSCHEMA11-2]を用いて型付けされたrdfs:Literal(xsd:gYear、xsd:gYearMonth、xsd:date、またはxsd:dateTime)。
使用上の注意: これは、カタログのエントリー、つまり、データセット自体の日付ではなく、データセットのカタログのメタデータ記述の最後の変更日を示します。
参照: § 6.4.8 プロパティー: update/modification date(更新/修正日)

6.5.5 プロパティー: primary topic(主要なトピック)

RDFプロパティー: foaf:primaryTopic
定義: レコード内に記述されているdcat:Resource(データセットまたはサービス)。
使用上の注意: foaf:primaryTopicというプロパティーは関数型です。各カタログ・レコードには、高々1つの主要なトピックがありえる、つまり、1つのデータセットまたはサービスを記述します。

6.5.6 プロパティー: conforms to(～に準拠)

注
RDFプロパティー: dct:conformsTo
定義: 記述されている資源が準拠する確立された標準。
値域: dct:Standard(比較の基準。他のものを評価するための基準点。)
使用上の注意: カタログ・レコードのメタデータが準拠するモデル、スキーマ、オントロジー、ビュー、またはプロファイルを示すためにこのプロパティーを用いるべきです(SHOULD)。
注

6.6 クラス: Dataset(データセット)

注

distribution、frequency、spatial/geographic coverage、spatial resolution、temporal coverage、temporal resolution、was generated byのプロパティーはこのクラスに固有です。

access rights、conforms to、contact point、creator、description、has policy、identifier、is referenced by、keyword/tag、landing page、license、resource language、relation、rights、qualified relation、publisher、release date、theme/category、title、type/genre、update/modification date、qualified attributionのプロパティーは、dcat:Resourceというスーパークラスから継承されます。

ライセンスと権利に関する情報は、配信のレベルで提供すべきです(SHOULD)。ライセンスと権利に関する情報は、そのデータセットの配信に提供する情報の代わりではなく、それに追加する形でデータセットに提供できます(MAY)。そのデータセットの配信に提供された情報とは異なるデータセットにライセンスまたは権利の情報を提供すると、法的な矛盾が生じる可能性があるため避けるべきです(SHOULD)。

RDFクラス: dcat:Dataset
定義: 1つのエージェントによって公開またはキュレートされ、1つ以上の表現でアクセスまたはダウンロードできるデータのコレクション。
～のサブクラス: dcat:Resource
使用上の注意: このクラスは、概念的なデータセットを記述します。スキーマのレイアウトと形式またはシリアル化が異なる、1つ以上の表現が利用できる場合があります。
使用上の注意: このクラスは、データセットの提供者が公開する実際のデータセットを記述します。カタログ内の実際のデータセットとそのエントリーとの区別が必要な場合(修正日などのメタデータが異なるかもしれないので)は、後者にカタログ・レコードというクラスを使用できます。

6.6.1 プロパティー: dataset distribution(データセット配信)

RDFプロパティー: dcat:distribution
定義: データセットの利用可能な配信
～のサブプロパティー: dct:relation
定義域: dcat:Dataset
値域: dcat:Distribution

6.6.2 プロパティー: frequency(頻度)

RDFプロパティー: dct:accrualPeriodicity
定義: データセットの公開頻度。
値域: dct:Frequency(循環レート)
使用上の注意: dct:accrualPeriodicityの値は、全体としてのデータセットの更新レートを示します。これは、時系列内のデータの収集時刻の間隔を提供するdcat:temporalResolutionによって補完されます。

dct:accrualPeriodicityとdcat:temporalResolutionを組み合わせる方法を示す例を§ 9.1 時間プロパティーで示しています。

6.6.3 プロパティー: spatial/geographical coverage(空間/地理範囲)

RDFプロパティー: dct:spatial
定義: データセットがカバーする地理的領域。
値域: dct:Location(空間的な領域または指定された場所)
使用上の注意: データセットの空間範囲は、dct:Locationのインスタンスとしてエンコードするか、場所を記述している資源へのURI参照(リンク)を用いて示すことができます。リンクは、Geonamesなどのよく管理された地名辞典のエントリーに対して行うことをお勧めします。

dct:Locationの詳細を表現するためのオプションを§ 6.15 クラス: Locationで提供しています。

6.6.4 プロパティー: spatial resolution(空間分解能)

注
RDFプロパティー: dcat:spatialResolutionInMeters
定義: メートル単位で測定された、データセット内の分解可能な最小の空間分離。
値域: xsd:decimal
使用上の注意: データセットが画像またはグリッドの場合、これはアイテム間の間隔に対応すべきです。その他の種類の空間データセットの場合、このプロパティーは通常、データセット内のアイテム間の最小の距離を示します。

このプロパティーの値域は、メートル単位の長さを表す10進数です。これは、データの空間分解能を1つの数値として要約して示すことを目的としています。データ品質語彙[VOCAB-DQV]を用いて、空間の精度、正確性、分解能、およびその他の統計の様々な側面のより複雑な記述を提供できます。

6.6.5 プロパティー: temporal coverage(時間範囲)

RDFプロパティー: dct:temporal
定義: データセットがカバーする時間的な期間。
値域: dct:PeriodOfTime(その開始日と終了日で指定または定義される時間の間隔)
使用上の注意: データセットの時間範囲は、dct:PeriodOfTimeのインスタンスとしてエンコードするか、期間または間隔を記述している資源へのURI参照(リンク)を用いて示すことができます。

dct:PeriodOfTimeの詳細を表現するためのオプションを§ 6.14 クラス: Period of Time(期間)で提供しています。

6.6.6 プロパティー: temporal resolution(時間分解能)

注
RDFプロパティー: dcat:temporalResolution
定義: データセット内の分解可能な最小の期間。
値域: xsd:duration
使用上の注意: データセットが時系列の場合、これは系列内のアイテム間の間隔に対応すべきです。その他の種類のデータセットの場合、このプロパティーは通常、データセット内のアイテム間の最小の時間差を示します。

これは、データ配信の時間分解能を1つの値として要約して示すことを目的としています。データ品質語彙[VOCAB-DQV]を用いて、時間の精度、正確性、分解能、およびその他の統計の様々な側面のより複雑な記述を提供できます。

dcat:temporalResolutionとdct:accrualPeriodicityの違いを§ 9.1 時間プロパティーの例で示しています。

6.6.7 プロパティー: was generated by(～によって生成された)

注
RDFプロパティー: prov:wasGeneratedBy
定義: データセットの作成をもたらせた、またはそのためのビジネス・コンテキストを提供する活動。
定義域: prov:Entity
値域: prov:Activity 活動は、一定期間にわたって発生し、エンティティーに対して、またはエンティティーを用いて行う事物です。エンティティーの利用、処理、変換、変更、再配置、使用、または生成が含まれる場合があります。
使用上の注意: 通常、データセットの生成に関連する活動は、イニシアチブ、プロジェクト、ミッション、調査、進行中の活動(「通常業務」)などです。複数のprov:wasGeneratedByプロパティーを用いて、様々なレベルの粒度でデータセット生成のコンテキストを示すことができます。
使用上の注意: 例えば、プロジェクトの存続期間中にデータセットが作成された正確な時間などの、データセットと活動の間の関係に関する詳細を追加するためには、prov:qualifiedGenerationを用いてください。
注

プロジェクト、イニシアチブ、進行中の活動、ミッション、調査などの、データセットを生成した活動の記述方法に関する詳細は、このドキュメントの範囲外です。prov:Activityは、開始時間と終了時間、関連するエージェントなどの基本的なプロパティーを提供します。詳細は、アプリケーションで定義されているクラスを介して提供できます。例えば、学術研究プロジェクト用のVIVO[VIVO-ISF]、ソフトウェア・プロジェクト用のDOAP(Description of a Project)[DOAP]、様々なアプリケーションに適していると思われる一般的なプロジェクト用のDBPedia[DBPEDIA-ONT]など、プロジェクトを記述するための多くのオントロジーが利用できます。

6.7 クラス: Distribution(配信)

access rights、access URL、access service、byte size、compression format、conforms to、description、download URL、format、has policy、license、media type、packaging format、release date、rights、spatial resolution、temporal resolution、title、update/modification dateのプロパティーはこのクラスに固有です。

RDFクラス: dcat:Distribution
定義: データセットの特定の表現。データセットは、自然言語、メディア・タイプや形式、スキーマ構成、時間的および空間的な分解能、詳細レベルやプロファイル(上記のいずれかまたはすべてを指定する場合がある)を含む、様々な点で異なりえる複数のシリアル化で使用できる場合があります。
使用上の注意: これは、データセットの一般的な利用可能性を表します。これは、データの実際のアクセス方式に関する情報(つまり、直接ダウンロードなのか、APIなのか、ウェブ・ページを介したものなのか)を意味しません。dcat:downloadURLというプロパティーの使用は、直接ダウンロード可能な配信を意味します。
参照: § 6.8 クラス: Data Service(データ・サービス)
注

dcat:Distributionとサービスまたはそれにアクセスできるウェブ・アドレスとの間のリンクは、図1で示し、以下の定義で記述しているように、dcat:accessURL、dcat:accessService、dcat:downloadURLを用いて表されます。

6.7.1 プロパティー: title(タイトル)

RDFプロパティー: dct:title
定義: 配信に与えられた名前。
値域: rdfs:Literal

6.7.2 プロパティー: description(内容記述)

RDFプロパティー: dct:description
定義: 自由形式のテキストによる配信の説明。
値域: rdfs:Literal

6.7.3 プロパティー: release date(公表日)

RDFプロパティー: dct:issued
定義: 配信の正式な発行(公開など)の日付。
値域: 関連するISO 8601の日付と時間[DATETIME]に準拠した文字列を用いてエンコードされ、適切なXMLスキーマ・データ型[XMLSCHEMA11-2]を用いて型付けされたrdfs:Literal(xsd:gYear、xsd:gYearMonth、xsd:date、またはxsd:dateTime)。
使用上の注意: このプロパティーは、判明している最初の発行日を用いて設定すべきです(SHOULD)。
参照: § 6.4.7 プロパティー: release date(公表日)

6.7.4 プロパティー: update/modification date(更新/修正日)

RDFプロパティー: dct:modified
定義: 配信が変更、更新、修正された最も最近の日付。
値域: 関連するISO 8601の日付と時間[DATETIME]に準拠した文字列を用いてエンコードされ、適切なXMLスキーマ・データ型[XMLSCHEMA11-2]を用いて型付けされたrdfs:Literal(xsd:gYear、xsd:gYearMonth、xsd:date、またはxsd:dateTime)。
参照: § 6.4.8 プロパティー: update/modification date(更新/修正日)

6.7.5 プロパティー: license(ライセンス)

RDFプロパティー: dct:license
定義: 配信を利用可能にする法的ドキュメント。
値域: dct:LicenseDocument
使用上の注意: ライセンスと権利に関する情報は、配信のレベルで提供すべきです(SHOULD)。ライセンスと権利に関する情報は、そのデータセットの配信に提供する情報の代わりではなく、それに追加する形でデータセットに提供できます(MAY)。そのデータセットの配信に提供された情報とは異なるデータセットにライセンスまたは権利の情報を提供すると、法的な矛盾が生じる可能性があるため避けるべきです(SHOULD)。§ 8. ライセンスと権利のステートメントの手引きも参照してください。
参照: § 6.7.7 プロパティー: rights(権利)、§ 6.4.19 プロパティー: license(ライセンス)

6.7.6 プロパティー: access rights(アクセス権)

RDFプロパティー: dct:accessRights
定義: 配信へのアクセス方法に関する権利ステートメント。
値域: dct:RightsStatement
使用上の注意: ライセンスと権利に関する情報を配信に提供できます(MAY)。§ 8. ライセンスと権利のステートメントの手引きも参照してください。
参照: § 6.7.5 プロパティー: license(ライセンス)、§ 6.7.7 プロパティー: rights(権利)、§ 6.4.1 プロパティー: access rights(アクセス権)

6.7.7 プロパティー: rights(権利)

RDFプロパティー: dct:rights
定義: 配信の内外で保持されている権利に関する情報。
値域: dct:RightsStatement
使用上の注意:

配信をライセンスのドキュメントにリンクするためにdct:rightsのサブプロパティーであるdct:licenseを使用できます。しかし、dct:rightsにより、ライセンス情報や、帰属などのライセンスを補足するその他の情報を含めることができる権利ステートメントにリンクできます。

ライセンスと権利に関する情報は、配信のレベルで提供すべきです(SHOULD)。ライセンスと権利に関する情報は、そのデータセットの配信に提供する情報の代わりではなく、それに追加する形でデータセットに提供できます(MAY)。そのデータセットの配信に提供された情報とは異なるデータセットにライセンスまたは権利の情報を提供すると、法的な矛盾が生じる可能性があるため避けるべきです(SHOULD)。§ 8. ライセンスと権利のステートメントの手引きも参照してください。
参照: § 6.7.5 プロパティー: license(ライセンス)、§ 6.4.20 プロパティー: rights(権利)

6.7.8 プロパティー: has policy(方針を持つ)

注
RDFプロパティー: odrl:hasPolicy
定義: 配信に関連付けられている権利を表すODRL適合の方針。
値域: odrl:Policy
使用上の注意: ODRL語彙[ODRL-VOCAB]を用いてODRL[ODRL-MODEL]の方針として表された権利に関する情報を配信に提供できます(MAY)。§ 8. ライセンスと権利のステートメントの手引きも参照してください。
参照: § 6.4.19 プロパティー: license(ライセンス) 、§ 6.7.6 プロパティー: access rights(アクセス権)、§ 6.7.7 プロパティー: rights(権利)

6.7.9 プロパティー: access URL(アクセスURL)

RDFプロパティー: dcat:accessURL
定義: データセットの配信へのアクセスを提供する資源のURL。例えば、ランディング・ページ、フィード、SPARQLエンドポイント。
定義域: dcat:Distribution
値域: rdfs:Resource
使用上の注意:

dcat:accessURLは、通常、ウェブ・フォーム、クエリ、またはAPIの呼び出しを介して、この配信へのアクセスを提供できるサービスまたは場所のURLに用いるべきです(SHOULD)。

dcat:downloadURLは、ダウンロード可能な資源への直接リンクに適しています。

ランディング・ページを介してしか配信にアクセスできない場合(つまり、直接的なダウンロードURLが不明)は、dcat:Datasetに関連付けられているランディング・ページのURLを配信のアクセスURLとしてコピーすべきです(SHOULD)(§ 5.7 ウェブ・ページの背後でしか利用できないデータセットを参照してください)。
参照: § 6.7.11 プロパティー: download URL(ダウンロードURL)、§ 6.7.10 プロパティー: access service(アクセス・サービス)

dcat:accessURLは、プロパティー連鎖であるdcat:accessService/dcat:endpointURLと一致します。DCATのRDF表現では、これはOWLプロパティー連鎖公理として公理化されています。

6.7.10 プロパティー: access service(アクセス・サービス)

注
RDFプロパティー: dcat:accessService
定義: データセットの配信へのアクセスを提供するデータ・サービス
値域: dcat:DataService
使用上の注意: この配信へのアクセスを提供できるdcat:DataServiceの記述にリンクするためには、dcat:accessServiceを用いるべきです(SHOULD)。
参照: § 6.7.11 プロパティー: download URL(ダウンロードURL)、§ 6.7.9 プロパティー: access URL(アクセスURL)

6.7.11 プロパティー: download URL(ダウンロードURL)

RDFプロパティー: dcat:downloadURL
定義: 指定された形式のダウンロード可能なファイルのURL。例えば、CSVファイルやRDFファイル。形式は、配信のdct:formatおよび(または)dcat:mediaTypeによって示されます。
定義域: dcat:Distribution
値域: rdfs:Resource
使用上の注意: この配信が直接(通常はHTTP Getリクエストを通じて)利用可能なURLにdcat:downloadURLを用いるべきです(SHOULD)。
参照: § 6.7.9 プロパティー: access URL(アクセスURL)、§ 6.7.10 プロパティー: access service(アクセス・サービス)

6.7.12 プロパティー: byte size(バイト・サイズ)

RDFプロパティー: dcat:byteSize
定義: バイトによる配信のサイズ。
定義域: dcat:Distribution
値域: xsd:decimalと型付けされたrdfs:Literal
使用上の注意: 正確なサイズが不明である場合、バイトによるサイズは、近似値で示すことができます。

6.7.13 プロパティー: spatial resolution(空間分解能)

注
RDFプロパティー: dcat:spatialResolutionInMeters
定義: メートル単位で測定された、データセットの配信内の分解可能な最小の空間分離。
値域: xsd:decimal
使用上の注意: データセットが画像またはグリッドの場合、これはアイテム間の間隔に対応すべきです。その他の種類の空間データセットの場合、このプロパティーは通常、データセット内のアイテム間の最小の距離を示します。
使用上の注意: 異なるデータセット配信として代替の空間分解能が提供される場合があります。

このプロパティーの値域は、メートル単位の長さを表す10進数です。これは、データ配信の空間分解能を1つの数値として要約して示すことを目的としています。データ品質語彙[VOCAB-DQV]を用いて、空間の精度、正確性、分解能、およびその他の統計の様々な側面のより複雑な記述を提供できます。

6.7.14 プロパティー: temporal resolution(時間分解能)

注
RDFプロパティー: dcat:temporalResolution
定義: データセット配信内の分解可能な最小の期間。
値域: xsd:duration
使用上の注意: データセットが時系列の場合、これは系列内のアイテム間の間隔に対応すべきです。その他の種類のデータセットの場合、このプロパティーは通常、データセット内のアイテム間の最小の時間差を示します。
使用上の注意: 異なるデータセット配信で代替の時間分解能が提供される場合があります。

これは、データ配信の時間分解能を1つの値として要約して示すことを目的としています。データ品質語彙[VOCAB-DQV]を用いて、時間の精度、正確性、分解能、およびその他の統計の様々な側面のより複雑な記述を提供できます。

6.7.15 プロパティー: conforms to(～に準拠)

注
RDFプロパティー: dct:conformsTo
定義: 配信が準拠する確立された標準。
値域: dct:Standard(比較の基準。他のものを評価するための基準点。)
使用上の注意: データセットのこの表現が準拠するモデル、スキーマ、オントロジー、ビュー、またはプロファイルを示すためにこのプロパティーを用いるべきです(SHOULD)。これは、(一般的に)メディア・タイプや形式に対する補完的な懸念事項です。
参照: § 6.7.17 プロパティー: format(形式)、§ 6.7.16 プロパティー: media type(メディア・タイプ)
注

6.7.16 プロパティー: media type(メディア・タイプ)

注
RDFプロパティー: dcat:mediaType
定義: IANA[IANA-MEDIA-TYPES]が定義している配信のメディア・タイプ。
～のサブプロパティー: dct:format
定義域: dcat:Distribution
値域: dct:MediaType
使用上の注意: このプロパティーは、配信のメディア・タイプがIANA[IANA-MEDIA-TYPES]で定義されているときに用いるべきで(SHOULD)、そうでない場合には、dct:formatを様々な値と共に使用できます(MAY)。
参照: § 6.7.17 プロパティー: format(形式)、§ 6.7.15 プロパティー: conforms to(～に準拠)

6.7.17 プロパティー: format(形式)

RDFプロパティー: dct:format
定義: 配信のファイル形式。
値域: dct:MediaTypeOrExtent
使用上の注意: 配信の種類がIANA[IANA-MEDIA-TYPES]で定義されているときには、dcat:mediaTypeを用いるべきです(SHOULD)。
参照: § 6.7.16 プロパティー: media type(メディア・タイプ)、§ 6.7.15 プロパティー: conforms to(～に準拠)

6.7.18 プロパティー: compression format(圧縮形式)

注
RDFプロパティー: dcat:compressFormat
定義: 例えば、ダウンロード可能なファイルのサイズを縮小するために、データを圧縮形式で含んでいる配信の圧縮形式。
値域: dct:MediaType
使用上の注意: このプロパティーは、例えば、ZIPファイルで配信内のファイルが圧縮されている場合に用いられます。可能であればIANA[IANA-MEDIA-TYPES]で定義されているメディア・タイプを用いて形式を表すべきです(SHOULD)。
参照: § 6.7.19 プロパティー: packaging format(パッケージ化形式)

このプロパティーの使用例に関しては、§ C.5 圧縮およびパッケージ化された配信を参照してください。

6.7.19 プロパティー: packaging format(パッケージ化形式)

注
RDFプロパティー: dcat:packageFormat
定義: 例えば、関連するファイルの集合を一緒にダウンロードできるようにするために、1つ以上のデータ・ファイルをグループ化している配信のパッケージ形式。
値域: dct:MediaType
使用上の注意: このプロパティーは、例えば、TARファイル、Frictionless Dataパッケージ、またはBagitファイルで、配信内のファイルがパッケージ化されているときに用いられます。可能であればIANA[IANA-MEDIA-TYPES]で定義されているメディア・タイプを用いて形式を表すべきです(SHOULD)。
参照: § 6.7.18 プロパティー: compression format(圧縮形式)

このプロパティーの使用例に関しては、§ C.5 圧縮およびパッケージ化された配信を参照してください。

6.8 クラス: Data Service(データ・サービス)

注

endpoint description、endpoint URL、serves datasetのプロパティーはこのクラスに固有です。

access rights、conforms to、contact point、creator、description、has policy、identifier、is referenced by、keyword/tag、landing page、license、resource language、relation、rights、qualified relation、publisher、release date、theme/category、title、type/genre、update/modification date、qualified attributionのプロパティーは、dcat:Resourceというスーパークラスから継承されます。

RDFクラス: dcat:DataService
定義: 1つ以上のデータセットまたはデータ処理機能へのアクセスを提供する操作のコレクション。
～のサブクラス: dcat:Resource
～のサブクラス: dctype:Service
使用上の注意: dcat:DataServiceが1つ以上の指定されたデータセットにバインドされている場合、それらはdcat:servesDatasetというプロパティーによって示されます。
使用上の注意: サービスの種類は、dct:typeというプロパティーを用いて示すことができます。その値は、INSPIRE空間データ・サービス型コード・リスト[INSPIRE-SDST]などの統制語彙を採用できます。

このクラスおよび関連するプロパティーの使用例に関しては、§ C.4 データ・サービスを参照してください。

6.8.1 プロパティー: endpoint URL(エンドポイントURL)

RDFプロパティー: dcat:endpointURL
定義: サービスのルートの位置または主要エンドポイント(Webで解決可能なIRI)。
定義域: dcat:DataService
値域: rdfs:Resource

6.8.2 プロパティー: endpoint description(エンドポイント記述)

RDFプロパティー: dcat:endpointDescription
定義: 操作、パラメーターなどを含む、エンドポイントを介して利用可能なサービスの記述
定義域: dcat:DataService
値域: rdfs:Resource
使用上の注意: エンドポイントの記述は、実際のエンドポイントのインスタンスの特定の詳細を提供しますが、dct:conformsToは、エンドポイントが実装する一般的な標準や仕様を示すために用いられます。
使用上の注意: エンドポイントの記述は、OpenAPI(Swagger)記述[OpenAPI]、OGC GetCapabilities応答[WFS]、[ISO-19142]、[WMS]、[ISO-19128]、SPARQLサービス記述[SPARQL11-SERVICE-DESCRIPTION]、[OpenSearch]または[WSDL20]ドキュメント、Hydra API記述[HYDRA]などの機械可読形式か、正式な表現が不可能な場合はテキストやその他の非公式モードで表現できます。

6.8.3 プロパティー: serves dataset(データセットを提供)

RDFプロパティー: dcat:servesDataset
定義: このデータ・サービスが配信できるデータのコレクション。
値域: dcat:Dataset

6.9 クラス: Concept Scheme(概念スキーム)

RDFクラス: skos:ConceptScheme
定義: カタログ内のデータセットのテーマ/カテゴリーを表すために用いられる知識組織化体系(KOS；knowledge organization system)。
参照: § 6.3.2 プロパティー: themes(テーマ)、§ 6.4.12 プロパティー: theme/category(テーマ/カテゴリー)

6.10 クラス: Concept(概念)

RDFクラス: skos:Concept
定義: カタログ内のデータセットを記述するために用いられるカテゴリーまたはテーマ。
使用上の注意: それが属している概念スキームを関連付けるためにデータセットを分類するのに用いるすべてのskos:Conceptにskos:inSchemeまたはskos:topConceptOfを用いることをお勧めします。この概念スキームは、一般的にdcat:themeTaxonomyを用いて、カタログと関係付けられます。
参照: § 6.3.2 プロパティー: themes(テーマ)、§ 6.4.12 プロパティー: theme/category(テーマ/カテゴリー)

6.11 クラス: Organization/Person(組織/人)

RDFクラス: 人の場合はfoaf:Person、政府機関やその他のエンティティーの場合はfoaf:Organization
使用上の注意: [FOAF]は、これらのエンティティーを記述するためにいくつかのプロパティーを提供します。

6.12 クラス: Relationship(関係性)

注

relation、had roleのプロパティーはこのクラスに固有です。

このクラスとそのプロパティーの使用方法を示した例を§ 13. 修飾付き関係で示しています。

RDFクラス: dcat:Relationship
定義: DCAT資源間の関係に追加情報を加えるための関連付けクラス
～のサブクラス: prov:EntityInfluence
使用上の注意: 関係の性質は分かっているけれども、標準的な[DCTERMS]プロパティー(dct:hasPart、dct:isPartOf、dct:conformsTo、dct:isFormatOf、dct:hasFormat、dct:isVersionOf、dct:hasVersion、dct:replaces、dct:isReplacedBy、dct:references、dct:isReferencedBy、dct:requires、dct:isRequiredBy)または[PROV-O]プロパティー(prov:wasDerivedFrom、 prov:wasInfluencedBy、prov:wasQuotedFrom、prov:wasRevisionOf、prov:hadPrimarySource、prov:alternateOf、prov:specializationOf)によって適切に特徴付けられていない場合に、データセット間、および潜在的に他の資源間の関係を特徴付けるために用いてください。

6.12.1 プロパティー: relation(関係)

RDFプロパティー: dct:relation
定義: 情報源の資源に関連する資源。
使用上の注意: dcat:Relationshipのコンテキストでは、これは別のdcat:Datasetまたは他のカタログ化された資源を指すことが期待されます。

6.12.2 プロパティー: had role(役割を持っていた)

注
RDFプロパティー: dcat:hadRole
定義: 別のエンティティーや資源に関するエンティティーやエージェントの機能。
定義域: prov:Attribution or dcat:Relationship
値域: dcat:Role
使用上の注意: エンティティーに関するエージェントの役割を指定するために修飾付き属性で使用できます。値は、[ISO-19115]のCI_RoleCodeなどのエージェントの役割に関する統制語彙を採用することをお勧めします。
使用上の注意: 別のエンティティーに関するエンティティーの役割を指定するために修飾付き関係で使用できます。エンティティーの役割に関する統制語彙の値を採用することをお勧めします。

このDCATプロパティーは、活動に関するエンティティーまたはエージェントの機能を提供するprov:hadRoleを補完します。

6.13 クラス: Role(役割)

注

このクラスの使用方法を示した例を§ 13. 修飾付き関係で示しています。

RDFクラス: dcat:Role
定義: 資源の属性または資源の関係のコンテキストで、役割は、別の資源に関する資源やエージェントの機能です。
～のサブクラス: skos:Concept
使用上の注意: エンティティーに関するエージェントの役割を指定するために修飾付き属性で用いられます。値は、[ISO-19115-1]のCI_RoleCodeなどのエージェントの役割に関する統制語彙として管理することをお勧めします。
使用上の注意:

別のエンティティーに関するエンティティーの役割を指定するために修飾付き関係で用いられます。値は、次のようなエンティティーの役割に関する統制語彙として管理することをお勧めします。

このDCATクラスは、活動に関するエンティティーまたはエージェントの機能を提供するprov:Roleを補完します。

6.14 クラス: Period of Time(期間)

注

start date、end date、beginning、endのプロパティーはこのクラスに固有です。

データセットの時間範囲に対するこれらのオプションの使用方法を示した例を§ 9.1 時間プロパティーで示しています。

RDFクラス: dct:PeriodOfTime
定義: その開始と終了で指定または定義される時間の間隔。
使用上の注意: 間隔の開始と終了は、dcat:startDateまたはtime:hasBeginning、およびdcat:endDateまたはtime:hasEndのプロパティーをそれぞれ用いて指定すべきです(SHOULD)。間隔は未指定にする、つまり、開始または終了のみにすることもできます。

6.14.1 プロパティー: start date(開始日)

注
RDFプロパティー: dcat:startDate
定義: 期間の開始。
定義域: dct:PeriodOfTime
値域: 関連するISO 8601の日付と時間[DATETIME]に準拠した文字列を用いてエンコードされ、適切なXMLスキーマ・データ型[XMLSCHEMA11-2]を用いて型付けされたrdfs:Literal(xsd:gYear、xsd:gYearMonth、xsd:date、またはxsd:dateTime)。

6.14.2 プロパティー: end date(終了日)

注
RDFプロパティー: dcat:endDate
定義: 期間の終了。
定義域: dct:PeriodOfTime
値域: 関連するISO 8601の日付と時間[DATETIME]に準拠した文字列を用いてエンコードされ、適切なXMLスキーマ・データ型[XMLSCHEMA11-2]を用いて型付けされたrdfs:Literal。

6.14.3 プロパティー: beginning(始点)

注
RDFプロパティー: time:hasBeginning
定義: 期間または間隔の始点
値域: time:Instant
使用上の注意: time:hasBeginningというプロパティーの使用は、dct:temporalというプロパティーの値が[OWL-TIME]のtime:TemporalEntityというクラスのメンバーであることを含意します。このコンテキストでは、これは、dct:PeriodOfTimeがtime:ProperIntervalというサブクラスと同等であることを意味すると見ることができます。
注

6.14.4 プロパティー: end(終点)

注
RDFプロパティー: time:hasEnd
定義: 期間または間隔の終点
値域: time:Instant
使用上の注意: time:hasEndというプロパティーの使用は、dct:temporalというプロパティーの値が[OWL-TIME]のtime:TemporalEntityというクラスのメンバーであることを含意します。このコンテキストでは、これは、dct:PeriodOfTimeがtime:ProperIntervalというサブクラスと同等であることを意味すると見ることができます。
注

6.15 クラス: Location(場所)

注

geometry、bounding box、centroidのプロパティーはこのクラスに固有です。

データセットの 空間範囲に対するこれらのオプションの使用方法を示した例を§ 9.2 空間プロパティーで示しています。

RDFクラス: dct:Location
定義: 空間的な領域または指定された場所。
使用上の注意:
  • 広範なジオメトリ(つまり、関連する地理的領域の頂点を示す一連の座標)には、locn:geometry[LOCN]というプロパティーを用いるべきです(SHOULD)。
  • 空間的領域を区切る地理的バウンディング・ボックスには、dcat:bboxというプロパティーを用いるべきです(SHOULD)。
  • 空間的領域の地理的中心や別の特徴点には、dcat:centroidというプロパティーを用いるべきです(SHOULD)。

6.15.1 プロパティー: geometry(ジオメトリ)

注
RDFプロパティー: locn:geometry
定義: 任意の資源を対応するジオメトリに関連付けます。[LOCN]
値域: rdfs:Literal
使用上の注意: このプロパティーの値域は、異なるジオメトリのエコーディングを可能とすることを目的として、意図的に汎用的です。例えば、ジオメトリは、WKTとしてエンコードできます(geosparql:asWKT[GeoSPARQL])。
注

6.15.2 プロパティー: bounding box(バウンディング・ボックス)

注
RDFプロパティー: dcat:bbox
定義: 資源の地理的バウンディング・ボックス。
値域: rdfs:Literal
使用上の注意: このプロパティーの値域は、異なるジオメトリのエコーディングを可能とすることを目的として、意図的に汎用的です。例えば、ジオメトリは、WKTとしてエンコードできます(geosparql:asWKT[GeoSPARQL])。
注

6.15.3 プロパティー: centroid(重心)

注
RDFプロパティー: dcat:centroid
定義: 資源の地理的中心(重心)。
値域: rdfs:Literal
使用上の注意: このプロパティーの値域は、異なるジオメトリのエコーディングを可能とすることを目的として、意図的に汎用的です。例えば、ジオメトリは、WKTとしてエンコードできます(geosparql:asWKT[GeoSPARQL])。
注

7. 逆参照可能な識別子

この項は非規範的です。

科学やデータ提供者のコミュニティは、出版物、著者、データに様々な識別子を用います。DCATは、識別子を実用的なものにする効果的な方法として、主に永続的なHTTP URIに依拠しています。とりわけ、相当数の識別子スキームは、逆参照可能なHTTP URIとしてエンコードでき、その一部は機械可読のメタデータも返します(例えば、DOIs[ISO-26324]やORCID)。それにも関わらず、データ提供者が、レガシーな識別子、HTTPで逆参照不可能な識別子、ローカルで作成された識別子、または第三者が提供する識別子を参照する必要がある場合があります。これらの場合、[DCTERMS]と[VOCAB-ADMS]が役立つ可能性があります。

dct:identifierというプロパティーは、HTTP URIとレガシーな識別子を明示的に示します。次の例では、dct:identifierはデータセットを識別していますが、あらゆる種類の資源でも同様に使用できます。

資源にHTTPで逆参照可能なIDがない場合、プロキシで逆参照可能なURIを使用できます。例えば、例14では、https://example.org/proxyidはidに対するプロキシです。

adms:identifier[VOCAB-ADMS]というプロパティーは、識別子がグローバルに一意で安定している限り、創造的な作品に関してはDOI、ELI、arΧiv、著者や出版者などの関係者に関してはORCID、VIAF、ISNIなど、他のローカルで作成された識別子や外部の識別子を表現できます。

例15では、adms:schemaAgencyとdct:creatorを用いて、識別子スキームを定義している機関(例えば、例にあるDOI財団など)を表し、機関にURIが関連付けられていない場合にはadms:schemaAgencyを用いています。CrossRefとDataCiteの表示ガイドラインでは、DOIをhttps://doi.org/10.xxxx/xxxxx/という形式で完全なURLリンクとして表示することを推奨しています。

登録者の指定はDOIの指針に反するため、例15では、そのスキームを用いた識別子の割り当てと管理に責任を有する機関が示されておらず(例えば、Zenodo)、それらを登録する組織から部分空間が抽象化されています。これは、組織が変更されたり、その部分空間の責任が他の人に譲渡されたりしてもDOIは変わらないという利点を利用しています。例15では、データセットの作成者に関してローカルに作成された識別子(例えば、https://example.org/PoelenJorritHID)とその対応するORCID識別子(例えば、https://orcid.org/0000-0003-3138-4118)が示されています。

HTTPで逆参照可能なIDがデータセットのRDF/OWL記述を返す場合は、owl:sameAsの使用が考えられる場合があります。例えば、

は、text/turtleというメディア・タイプで逆参照すると、https://doi.org/10.5281/zenodo.1486279がデータセットに[SCHEMA-ORG]の記述を返すケースです。これにより、https://example.org/idが提供する記述が動的に充実する可能性があります。

注

要件として、DCAT内のデータセットのプライマリ識別子と代替(またはレガシーの)識別子を区別する必要性が提起されています。しかし、これは非常にアプリケーションに固有のものであり、一般的なアプローチを義務付けるよりも、DCATプロファイルで対処する方が適切です。

アプリケーションのコンテキストに応じて、信頼できるデータセットと第三者のカタログによって収集されたデータセットとを区別するために、「DCAT-AP: どのように重複を管理する?」などの特定のガイドラインを採用できます。

7.1 一般的な識別子の型の指示

識別子がHTTPで逆参照できない場合は、相互運用性のために、一般的な識別子の型がRDFデータ型[RDF11-CONCEPTS]やカスタムのOWLデータ型[OWL2-SYNTAX]としての役割を果たします。例17のex:typeを参照してください。

登録済みのURIの型が用いられている場合([RFC3986]、§ 3.1 スキームに従って)、識別子のスキームはそのURIの一部です。したがって、「型」で別の識別子スキームを示すことは冗長です。例えば、DOIはinfo URIスキーム[IANA-URI-SCHEMES]の名前空間として登録されているため(DOI FAQ #11を参照)、[RFC3986]に従って、例18のようにエンコードすべきです。

そうでない場合は、識別子スキームの一般的な型の例(arXivなど)は、DataCiteスキーマとFAIRsharingレジストリで定義されます。

8. ライセンスと権利のステートメント

この項は非規範的です。

注

資源へのアクセスと再利用の条件を表現する正しい方法の選択は複雑になる可能性があります。実装者は、記述されている資源に適用する条件を決定する前に、常に法的助言を求めるべきです。

この仕様では、3つの主要な状況を区別しています。1つは、ステートメントが「ライセンス」として明示的に宣言されている資源に関連付けられている場合です。2つ目は、ステートメントがアクセス権のみを示している資源に関連付けられている場合です。3つ目は、他のすべてのケースを対象としたもの、すなわち、ライセンス条件および(または)アクセス権に関係のないステートメント(例えば、著作権ステートメント)です。

注

これらのシナリオに対処するには、dct:rightsというプロパティーとそのサブプロパティーであるdct:licenseとdct:accessRightsを用いることをお勧めします。より正確には、次のとおりです。

  1. dct:licenseを用いてライセンスを参照します。

    注

  2. dct:accessRightsを用いて、アクセス権のみに関するステートメントを表します(例えば、誰でもがデータにアクセスできるか、または許可された関係者のみがアクセスできるか)。

    注

  3. その他のすべての型の権利ステートメント(著作権ステートメントなどの、dct:licenseとdct:accessRightsでカバーされていないもの)にはdct:rightsを用います。

    注

最後に、ODRLの方針による権利表現という特定のケースでは、同じODRL方針の型と一致する関連するDCTERMSプロパティーに加えて、カタログ化された資源や配信の記述からODRLの方針へのリンクとして、odrl:hasPolicyプロパティーを用いることをお勧めします。

注

DCATで定義されている様々な種類の資源におけるこれらのプロパティーの使用に関する勧告は、関連するクラスの記述で提供されています。

9. 時間と空間

この項は非規範的です。

9.1 時間プロパティー

DCATを用いて資源の5つの時間プロパティーを記述できます。

  1. 資源の公表時刻はdct:issuedを用いて示します。通常、値はxsd:dateとしてエンコードされます。
  2. 資源の改訂または更新の時刻はdct:modifiedを用いて示します。通常、値はxsd:dateとしてエンコードされます。
  3. 資源の更新スケジュールはdct:accrualPeriodicityを用いて示します。値は、ダブリン・コア・コレクション記述頻度語彙(Dublin Core Collection Description Frequency Vocabulary)などの統制語彙を採用すべきです。
  4. データセット内のアイテムの最小の時間分離はdcat:temporalResolutionを用いて示します。値は、xsd:durationとしてエンコードされます。以下で示しているように、更新スケジュールと時間分解能を組み合わせて、様々な種類の時系列データの記述をサポートできます。
  5. データセットの時間範囲はdct:temporalを用いて示します。値はdct:PeriodOfTimeです。dct:PeriodOfTimeの詳細を表すための多くのオプションが§ 6.14 クラス: Period of Time(期間)で推奨されています。これらの例を次に示します。

9.2 空間プロパティー

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

  1. データセット内のアイテムの最小の空間分離はdcat:spatialResolutionInMetersを用いて示します。値は10進数です。

    dcat:spatialResolutionInMetersの使用例を例3で示しています。

  2. データセットの空間範囲はdct:spatialを用いて示します。値はdct:Locationです。dct:Locationの詳細を表すための多くのオプションが§ 6.15 クラス: Locationで推奨されています。

    これらの例を次に示します。

注

10. バージョン付け

この項は非規範的です。

バージョン付けは、カタログ、データセット、配信を含むあらゆる第一級のDCAT資源に適用できます。バージョンの概念は、コミュニティの慣行、データ管理方針、実施されているワークフローと深い関連があります。新しいバージョンの公表時期と理由の決定はデータの提供者次第です。そのため、DCATでは、いつ資源の変更を新たに公表すべきかに関する定義や規則を提供しないようにしています。

バージョン付けにはデータセット間の関係付けと理解でき、これは、dcat:qualifiedRelationでサポートされており、§ 13.2 データセットと他の資源との関係で説明しています。dcat:Relationshipというクラスは、関係に関する情報の提供をサポートしており、バージョン付け情報のために拡張できます。

11. データの引用

この項は非規範的です。

データセットの引用は、このDCATの改訂版で確認された要件の1つです。データの引用とは、データが調査プロセスにおける第一級のアウトプットであるとの認識で書誌的参考文献を提供するのと同じような方法でデータを参照することです。データ引用には、データの作成者への適切な帰属やクレジットの表示をサポートしたり、データの発見を促進したり、データの影響と再利用の追跡をサポートしたり、データの共同制作と再利用を可能にしたり、データに基づく結果の再現性を可能にするなど、複数の利点があります。

データの引用をサポートするには、データセットの記述に、データセットの識別子、データセットの作成者、データセットのタイトル、データセットの公開者、およびデータセットの公開日または公表日が少なくとも含まれているべきです。これらは、DataCiteメタデータ・スキーマ[DataCite]の必須要素で、[DataCite]が研究データに対して割り当てている永続識別子(DOI;デジタルオブジェクト識別子)によって関連付けられているメタデータです。

データの引用をサポートするために、このDCATの改訂版では、逆参照可能な識別子に関する留意点と、カタログ化された資源の作成者を示すためのサポートを追加しました。データの引用に必要な残りのプロパティーは、DCAT 2014[VOCAB-DCAT-20140116]で既に提供されていました。

データセット記述内のデータの引用に必要なプロパティーの可用性に関する制約は、DCATデータ引用プロファイルとして表すことができます。

12. 品質情報

この項は非規範的です。

注

データ品質語彙(DQV)[VOCAB-DQV]は、データ品質の様々な側面に共通するモデリング・パターンを提供します。これは、DCATデータセットと配信を、以下を含む様々な種類の品質情報に関連付けることができます。

品質情報はそれぞれ、1つ以上の品質次元、つまり、利用者に関する品質特性と関係がありえます。品質管理の分野では、品質を多次元空間として見る慣行が確立されており、品質管理はアドレス指定可能なチャンクに分割されます。DQVは、品質次元の規範的なリストを定義していません。これは、2つの可能な出発点として、ISO/IEC 25012 [ISO-IEC-25012]と[ZaveriEtAl]で提案されている品質次元を提供します。また、後者で定義されている品質次元とカテゴリのRDF表現も提供します。最終的に、実装者は自分のニーズに最も合う品質次元のコレクションを選択する必要があります。次の項では、DCATとDQVを組み合わせてデータセットと配信の品質を記述する方法を示します。包括的な解説や使用例に関しては、[VOCAB-DQV]を参照してください。

注

12.1 品質情報の提供

あるデータの利用者(:consumer1)が、ジオリファレンスを行ったジェノヴァのバス停のリストが含まれている:genoaBusStopsDatasetというデータセットの品質を記述します。彼/彼女は、データセットには30000のバス停のうち20500のバス停しか含まれていないことを警告するために、データの完全性(ldqd:completeness)に関するDQVの品質注記(:genoaBusStopsDatasetCompletenessNote)を用いてデータセットにアノテーションを付与します。

:myQualityCheckingという活動は、:genoaBusStopsDatasetというデータセットの品質を確認するために:myQualityCheckerというサービスを用いています。データセットの完全性(ldqd:completeness)を測定するために:completenessWRTExpectedNumberOfEntitiesという測定基準が適用され、結果として:genoaBusStopsDatasetCompletenessMeasurementという品質測定値になります。

データセットの正確性と精度を表す方法の例を含む、品質に関するドキュメントの他の例が[VOCAB-DQV]にあります。

12.2 標準に対する適合性のドキュメント化

この項では、[VOCAB-DQV]を[PROV-O]およびEARL[EARL10-Schema]と組み合わせた様々なモデリング・パターンを示し、規定の品質標準に対する適合度と適合性テストの詳細を表します。

12.2.1 標準に対する適合性

dct:conformsToとdct:Standardの使用は、標準に対する適合性を表す有名なパターンです。[SDW-BP](例51)から直接借用した例33は、空間のデータセットとサービスの相互運用性に関するEU INSPIRE規則に準拠した架空のa:Datasetを宣言しています(「空間のデータセットとサービスの相互運用性に関する欧州議会および理事会の指令2007/2/ECを実装している2010年11月23日の委員会規則(EU) No 1089/2010」)。

別の例は、データセットで用いられる座標参照系(CRS) - 通常、地理空間メタデータに含まれている情報 - の仕様に関するものです。例34は、データセットのCRSをDCATで指定する方法を示しています。

例34では、http://www.opengis.net/def/crs/EPSG/0/28992はOGC CRSレジストリのURIであり、EPSG:28992(「Amersfoort / RD New」)に対応しています(例28も参照)。

注

12.2.2 適合度

一部の法的文脈では、適合度を指定する必要があります。例えば、INSPIREメタデータは、完全な準拠性に加えて、不適合や非評価を表現するために、特定の統制語彙[INSPIRE-DoC]を採用しています。同様の統制語彙を他のコンテキストで定義できます。

例35では、適合度(つまり、適合、不適合)を表すいくつかの新しく作成された概念を指定し、適合テストの結果を示すためにdct:typeを宣言しています。[GeoDCAT-AP]で用いられているパターンに従い、この例では、適合性テスト(例えば、a:testResult）をモデル化するためにprov:Entityを、テスト活動(例えば、a:testingActivity)をモデル化するたにprov:Activityを、ベスト・プラクティスの全体を確認するためにウェブ上のデータのベスト・プラクティス[DWBP](例えば、a:conformanceTest)から派生したprov:Planを用いています。修飾付きPROV associationは、テスト活動を適合性テストにバインドします。

注

また、特定の標準に対する準拠性を評価するために[VOCAB-DQV]を展開できます。例36では、:levelOfComplianceToDWBPは、合格した準拠性テストの割合に関し、[DWBP]に対するデータセットの準拠性を測定する品質測定基準です。例36では、isoを、ISO/IEC 25012[ISO-IEC-25012]で定義されている品質の次元とカテゴリを表す名前空間接頭辞であると仮定しています。

品質の測定値である:measurement_complianceToDWBPは、a:Datasetというデータセットの準拠レベル、つまり:levelOfComplianceToDWBPという測定基準の測定値を表します。準拠性テストの一部(例えば、準拠性テストの半分)のみが成功した場合、測定値は 例37のようになります。

12.2.3 適合性テストの結果

テストに関する詳細情報は、EARL[EARL10-Schema]を用いて提供できます。EARLは、[PROV-O]と組み合わせて採用できる、テスト活動を記述するための特定のクラスを提供します。例38では、a:testingActivityというテスト活動を、prov:Activityの修飾付きの関連付けではなく、earl:Assertionとして記述しています。earl:Assertionは、a:Datasetというデータセットがa:conformanceTestという適合テストでテストされ、a:testResultで記述されているようにテストに合格したと述べています。

例39は、a:testq1というサブテストが失敗した場合に記述がどのようになるかを示しています。特に、dct:descriptionとearl:infoは、人間が読める形式で追加の警告やエラーメッセージを提供します。

[VOCAB-DQV]は、テストに必要な詳細さに応じてテスト活動とエラーも表現できます。例40では、:errorは以前のエラーを表す品質のアノテーションであり、a:testResultはdqv:QualityMetadataとして定義され、上記のアノテーションと来歴情報を提供する準拠性の測定値を収集します。

もちろん、上記のモデリング・パターンは、標準への準拠のみでなく、あらゆる品質テストを表すことができます。

13. 修飾付き関係

この項は非規範的です。

DCATには、データセットとデータ・サービスの多くの側面の記述をサポートする要素が含まれています。それにも関わらず、一部の関係のセマンティクスを完全に表現するためには、追加情報が必要です。例えば、[DCTERMS]は、責任のある関係者やエージェントに資源を帰属させるための標準的な役割である作成者、寄与者、および公開者を提供しますが、他にも多くの潜在的な役割があります。例として、[ISO-19115-1]のCI_RoleCodeという値を参照してください。同様に、[DCTERMS]と[PROV-O]は、～から派生、～から引用、～のバージョン、参照などを含む、資源間の関係を捕捉するためのいくつかのプロパティーを提供しますが、[ISO-19115-1] DS_AssociationTypeCodes、リンク関係のIANAレジストリ[IANA-RELATIONS]、DataCiteメタデータ・スキーマ[DataCite]、MARC関連指示子のリストにはさらに多くの懸念事項があります。これらの関係は、dct:relation、dct:contributorなどの追加のサブプロパティーで捕捉できますが、これによりプロパティーの数が爆発的に増加し、潜在的な役割と関係の完全な集合はいずれにしても不明です。

この種の要件を満たすための一般的なアプローチは、関係を修飾するパラメーターを伝えるために追加の資源を導入することです。先例には、[PROV-O]の修飾付き用語と、セマンティック・センサー・ネットワーク・オントロジー[VOCAB-SSN]のサンプル関係があります。一般的な修飾付き関係のパターンについては、[LinkedDataPatterns]で説明されています。

[PROV-O]の修飾付き用語の多くは、カタログ内の資源の記述に関連していますが、PROV-Oは活動中心の観点を取っているため、これらは不完全です。一部のギャップに対処するため、DCAT語彙には、明示的な活動を伴わない要件を満たすための追加の形式が含まれています。これらを図5で要約しています。

DCAT修飾付き関係のUMLモデル
図5 修飾付き関係は、資源をエージェントやその他の資源に関連付ける拡張可能な役割をサポートします。

これらの修飾付き形式の焦点は、関係に役割を追加できるようにすることですが、特定のノードを用いてこのような関係を記述すると、適用可能な時間間隔などの、関係の他の側面が簡単に付加されることに注意してください(例えば、一部の例に関して、[PROV-O]の影響関係の図表を参照してください)。

注

13.1 データセットとエージェントの関係

標準的な[DCTERMS]プロパティーであるdct:contributor、dct:creatorとdct:publisher、そして[PROV-O]の汎用的なprov:wasAttributedToは、責任のあるエージェントとカタログ化された資源との基本的な関連付けをサポートします。しかし、データセットやサービスに関連する重要な役割は他にもたくさんあります - 例えば、資金提供者、配信者、管理人、編集者。これらの役割の一部は、[ISO-19115-1]のCI_RoleCodeの値、[DataCite]のメタデータ・スキーマで列挙されており、MARC関連指示子に含まれています。

[PROV-O]の修飾付き形式であるprov:qualifiedAttributionを用いることにより、指定された役割を持つ資源にエージェントを割り当てる一般的な方法が提供されます。例41で例を示します。

例41では、役割は、[ISO-19115-1]のCI_RoleCodeコード・リストの(非規範的な)リンクト・データ表現のIRIによって示されています。

注

13.2 データセットと他の資源との関係

標準的な[DCTERMS]プロパティーであるdct:relationと、dct:hasPart / dct:isPartOf、dct:hasVersion / dct:isVersionOf、dct:replaces / dct:isReplacedBy、dct:requires / dct:isRequiredBy、prov:wasDerivedFrom、prov:wasQuotedFromなどのサブプロパティーは、データセットとその他のカタログ化された資源との間の関係の記述をサポートします。しかし、他にも多くの重要な関係があります - 例えば、代替、正規、オリジナル、プレビュー、ステレオ仲間、作業用コピー。これらの役割の一部は、[ISO-19115-1]のDS_AssociationTypeCodesの値、リンク関係のIANAレジストリ[IANA-RELATIONS]、[DataCite]のメタデータ・スキーマで列挙されており、MARC関連指示子に含まれています。

指定された役割を持つ別の資源に資源を関連付ける一般的な方法は、dcat:qualifiedRelationの修飾付き形式を用いて提供されます。例42で例を示します。

例42では、役割は[IANA-RELATIONS]と[ISO-19115-1]のDS_AssociationTypeCodeコードリストの(非規範的な)リンクト・データ表現のIRIによって示されています。

注

14. DCATプロファイル

この項は非規範的です。

DCAT-2014語彙[VOCAB-DCAT-20140116]は、様々な定義域のデータ・カタログのアプリケーション向けに拡張されています。これらの新しい仕様はそれぞれ、DCATプロファイル、つまり、DCATに基づく名前付き制約の集合を構成します(§ 4. 適合性を参照)。場合によっては、プロファイルは、参照DCATプロファイルでカバーされていないメタデータ・フィールドのクラスとプロパティーを追加することにより、DCATプロファイル自体の1つを拡張します。

DCATプロファイルの一部は次のとおりです。

15. セキュリティとプライバシー

DCAT語彙は、資源の作成者、公開者、その他の修飾付き関係を介した関係者やエージェントなどの様々な参加者に対するデータとメタデータの帰属をサポートしているため、個人情報に関連がありえる用語が定義されています。さらに、権利とライセンスと、カタログ化された資源と配信との関連付けもサポートします。これらの権利とライセンスには、[ODRL-VOCAB]で記述されているユーザーや資産の識別子などの機密情報が含まれていたり参照されていたりする可能性があります。このような語彙の用語を作成、維持、公開、または利用する実装では、アプリケーション・レベルでセキュリティとプライバシーの留意事項に対処するための措置を講じなければなりません。

A. 謝辞

編集者は、ワーキンググループの全メンバー、特にAnnette Greiner、Antoine Isaac、Armin Haller、Dan Brickley、Ine de Visser、Jaroslav Pullmann、Lars G. Svensson、Linda van den Brink、Makx Dekkers、Nicholas Car、Rob Atkinson、Tom Bakerによるこのドキュメントに対する貢献に謝意を表します。

編集者は、Addison Phillips、Andreas Kuckartz、Anna Odgaard Ingram、Armando Stellato、Bert van Nuffelen、Chris Little、Chris Sweeney、Chris Wood、Clemens Portele、Daniel Pop、Dave Reynolds、Guillaume Duffes、Ian Davis、Jakob Vos、Jakub Klimek、James Passmore、Leigh Dodds、Luca Trani、Marco Brattinga、Matthias Palmer、Melanie Barlow、Nancy Fallgren、Nuno Freire、Oystein Asnes、Pano Maria、Peter Parslow、Renato Iannella、Ruth Duerr、Siri Jodha S. Khalsa、Stephane Fellah、Stephen Richard、Stijn Goedertier、Tom Kralidis、Vladimir Alexiev、Wouter Beek、Yves Coeneから受け取ったコメントにも感謝したいと思います。

編集者は、このワーキンググループの議長であるKaren Coyle、Caroline Burle、Peter Winstanleyおよび窓口スタッフのPhil ArcherとDave Raggettにも謝意を表します。

B. Schema.orgとの連携

この項は非規範的です。

注

Schema.org[SCHEMA-ORG]には、元のDCATの成果(手始めとしてsdo:Datasetを参照してください)に基づく多くの型とプロパティーが含まれており、Googleのデータセット検索サービスのインデックスは、schema.orgとDCATの両方を用いたデータセットに関するウェブ・ページの構造記述に依存しています。上記の図1で示したDCATバックボーンと、図6の[SCHEMA-ORG]の関連するクラスとの比較により、特に、次の点の類似性が明らかです。

データセットのカタログに関連するschema.orgのクラスとプロパティーのUMLモデル
図6 データセットのカタログに関するschema.orgのサポート。表示されているクラスに関連するschema.orgプロパティーの選択範囲を示します。

メタデータを用いた一般的な目的のウェブ検索サービスは、主に[SCHEMA-ORG]に依拠しているため、DCATと[SCHEMA-ORG]との関係は、自身のデータセットとサービスをそれらのインデックスによって公開したいと考えているデータ提供者とカタログ公開者にとって関心事です。

DCAT 2014とschema.orgとのマッピングについては、当初の提案時に、データセットとデータ・カタログを記述するための[SCHEMA-ORG]の拡張が議論されました。DCAT 2014[VOCAB-DCAT-20140116]と[SCHEMA-ORG]との部分的なマッピングは、以前の成果に基づいて構築され、以前にウェブ上の空間データ・ワーキンググループが提供しました。

改訂版のDCAT(このドキュメント)から[SCHEMA-ORG]バージョン3.4への推奨されるマッピングは、RDFファイルで利用可能です。このマッピングは、[SCHEMA-ORG]のセマンティクスと一致させるために、rdfs:subClassOf、rdfs:subPropertyOf、owl:equivalentClass、owl:equivalentProperty、skos:closeMatchという述語を用いて、また、sdo:domainIncludesおよびsdo:rangeIncludesというアノテーション・プロパティーを用いて公理化されています。sdoという接頭辞をhttp://schema.org/と見なして、連携を以下の表に要約します。

DCAT要素 schema.orgのターゲット要素
dcat:Resource sdo:Thing
dct:title sdo:name
dct:description sdo:description
dcat:keyword
dcat:keyword is singular, sdo:keywords is plural		 sdo:keywords
dcat:theme sdo:about
dct:identifier sdo:identifier
dct:type sdo:additionalType
dct:issued sdo:datePublished
dct:modified sdo:dateModified
dct:language sdo:inLanguage
dct:relation sdo:isRelatedTo
dcat:landingPage sdo:url
dct:publisher sdo:publisher
dcat:contactPoint sdo:contactPoint
dcat:Catalog sdo:DataCatalog
dct:hasPart sdo:hasPart
dcat:dataset sdo:dataset
dcat:distribution sdo:distribution
dcat:Dataset sdo:Dataset
dcat:Dataset
dct:accrualPeriodicity fixed to
<http://purl.org/cld/freq/continuous>		 sdo:DataFeed
dct:spatial sdo:spatialCoverage
dct:temporal sdo:temporalCoverage
dct:accrualPeriodicity sdo:repeatFrequency
prov:wasGeneratedBy [ owl:inverseOf sdo:result ]
dcat:Distribution sdo:DataDownload
dct:format sdo:encodingFormat
dcat:mediaType sdo:encodingFormat
dcat:byteSize sdo:contentSize
dcat:accessURL sdo:contentUrl
dcat:downloadURL sdo:contentUrl
dct:license sdo:license
dcat:DataService sdo:WebAPI
dcat:endPointURL sdo:url
dcat:endPointDescription sdo:documentation, sdo:hasOfferCatalog
dct:type
in context of a dcat:DataService		 sdo:serviceType
dcat:servesDataset sdo:serviceOutput
dcat:Relationship sdo:Role

C. 例

この項は非規範的です。

C.1 緩く構造化したカタログ

注

多くのレガシーなカタログやリポジトリ(例えば、CKAN)では、「データセット」は「単なるファイルの袋」です。データセットから各ファイルに至るまで、部分/全体、配信(表現)、およびその他の種類の関係(例えば、ドキュメント、スキーマ、サポート・ドキュメント)の間に区別はありません。

データセットとカタログ、リポジトリなどのコンポーネント資源との関係の性質が不明な場合は、dct:relationを使用できます。

これらの関連する資源のいずれかがデータセットの適切な表現であることが明らかな場合は、dcat:distributionを用いるべきです。

この例は、csiro-dap-examples.ttlのDXWGコード・リポジトリから入手できます。

関連する資源の性質に関するさらなる詳細は、DCATのデータセット記述子とともに、他のRDF語彙の適切な要素を用いて提供できます。例えば、上記の例は、次のようにより完全に表現できます(組み込みコメントは、グラフ内の様々な資源について説明している)。

この例は、csiro-stratchart.ttlのDXWGコードリポジトリから入手できます。

C.2 データセットの来歴

データセットの来歴やビジネス・コンテキストは、W3C来歴オントロジー[PROV-O]の要素を用いて記述できます。

例えば、データセットの記述からデータセットを生成したプロジェクトへのシンプルなリンクは、次のように形式化できます(明確化のため、その他の詳細は省略)。

この例は、csiro-dap-examples.ttlのDXWGコード・リポジトリから入手できます。

いくつかのプロパティーにより、引用やタイトル内などの来歴情報が捕捉されていますが、プロジェクトの公式な記述への主なリンクはprov:wasGeneratedByによります。プロジェクトの簡潔な記述がprov:Activityとして示されていますが、これは必ずしも同じカタログの一部ではありません。プロジェクトが進行中であるため、活動には終了日がないことに注意してください。

その他のPROVの開始点プロパティー、特にprov:wasAttributedTo(データセットの生成に関連しているエージェントにリンクするため)とprov:wasDerivedFrom(以前の(predecessor)データセットにリンクするため)を用いて、さらなる来歴情報を提供できるかもしれません。これは両方とも、次のように、DCATで既に用いられているダブリン・コアのプロパティーを補完します。

資源の属性と相互関係のために修飾付きプロパティーを用いるその他のパターンを§ 13. 修飾付き関係で説明しています。

多くの場合、データセットは出版物(学術論文、報告など)に関連付けられており、このバージョンのDCATはdct:isReferencedByというプロパティーに依拠して、データセットに関する出版物をデータセットにリンクする方法を提供します。

次の例は、Dryadリポジトリで公開されているデータセットが、どのようにNature Scientific Data誌で利用できる出版物にリンクされるかを示しています。

この例は、dryad-globtherm-sdata.ttlのDXWGコード・リポジトリから入手できます。

C.4 データ・サービス

データ・サービスは、DCATを用いて記述できます。dct:type、dct:conformsToおよびdcat:endpointDescriptionという分類子の値は、実際のエンドポイントがdcat:endpointURLによって指定されるサービスに関する詳細を段階的に提供します。

最初の例は、欧州環境庁(EEA;European Environment Agency)が提供するデータ・カタログについて記述しています。これは、dcat:DataServiceとして分類されており、空間データ・サービス型のINSPIRE分類[INSPIRE-SDST]の「発見」(discovery)に設定されたdct:typeを持っています。

この例は、eea-csw.ttlのDXWGコード・リポジトリから入手できます。

例49は、オーストラリア地球科学局(Geoscience Australia)が提供するデータセットを示しており、各サービス記述のdcat:servesDatasetプロパティーの値で示されているとおり、3つの異なるサービスから利用できます。これらはdcat:DataServiceとして分類されており、空間データ・サービス型のINSPIRE分類[INSPIRE-SDST]の「ダウンロード」(download)と「ビュー」(view)に設定されたdct:typeを持っています。

例49は、ga-courts.ttlのDXWGコード・リポジトリから入手できます。

C.5 配信の圧縮とパッケージ化

最初の例は、GZIPファイルに圧縮されたダウンロード可能ファイルを用いた配信に関するものです。

2番目の例は、いくつかのファイルをTARファイルにパッケージ化した配信です。

3番目の例は、GZIPファイルに圧縮されていたいくつかのファイルをTARファイルにパッケージ化した配信に関するものです。

これらの例は、compress-and-package.ttlのDXWGコード・リポジトリから入手できます。

D. 変更履歴

完全な変更履歴はGitHubで入手できます。

D.1 2014年1月16日のW3C勧告以後の変更

このドキュメントには、2014年1月16日のW3C勧告[VOCAB-DCAT-20140116]以後、次の変更がありました。

E. 参考文献

E.1 規範的な参考文献

[DC11]
Dublin Core Metadata Element Set, Version 1.1. DCMI. 14 June 2012. DCMI Recommendation. URL: http://dublincore.org/documents/dces/
[DCTERMS]
DCMI Metadata Terms. DCMI Usage Board. DCMI. 14 June 2012. DCMI Recommendation. URL: http://dublincore.org/documents/dcmi-terms/
[FOAF]
FOAF Vocabulary Specification 0.99 (Paddington Edition). Dan Brickley; Libby Miller. FOAF project. 14 January 2014. URL: http://xmlns.com/foaf/spec
[GeoSPARQL]
GeoSPARQL - A Geographic Query Language for RDF Data. Matthew Perry; John Herring. OGC. 10 September 2012. URL: http://www.opengeospatial.org/standards/geosparql
[IANA-MEDIA-TYPES]
Media Types. IANA. URL: https://www.iana.org/assignments/media-types/
[LOCN]
ISA Programme Location Core Vocabulary. Andrea Perego; Michael Lutz. European Commission. 23 March 2015. Second version in w3.org/ns space. URL: http://www.w3.org/ns/locn
[ODRL-MODEL]
ODRL Information Model 2.2. Renato Iannella; Serena Villata. W3C. 15 February 2018. W3C Recommendation. URL: https://www.w3.org/TR/odrl-model/
[ODRL-VOCAB]
ODRL Vocabulary & Expression 2.2. Renato Iannella; Michael Steidl; Stuart Myles; Victor Rodriguez-Doncel. W3C. 15 February 2018. W3C Recommendation. URL: https://www.w3.org/TR/odrl-vocab/
[OWL-TIME]
Time Ontology in OWL. Simon Cox; Chris Little. W3C. 19 October 2017. W3C Recommendation. URL: https://www.w3.org/TR/owl-time/
[OWL2-OVERVIEW]
OWL 2 Web Ontology Language Document Overview (Second Edition). W3C OWL Working Group. W3C. 11 December 2012. W3C Recommendation. URL: https://www.w3.org/TR/owl2-overview/
[PROV-O]
PROV-O: The PROV Ontology. Timothy Lebo; Satya Sahoo; Deborah McGuinness. W3C. 30 April 2013. W3C Recommendation. URL: https://www.w3.org/TR/prov-o/
[RDF-SCHEMA]
RDF Schema 1.1. Dan Brickley; Ramanathan Guha. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf-schema/
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119
[RFC8174]
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://tools.ietf.org/html/rfc8174
[SKOS-REFERENCE]
SKOS Simple Knowledge Organization System Reference. Alistair Miles; Sean Bechhofer. W3C. 18 August 2009. W3C Recommendation. URL: https://www.w3.org/TR/skos-reference/
[XMLSCHEMA11-2]
W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes. David Peterson; Sandy Gao; Ashok Malhotra; Michael Sperberg-McQueen; Henry Thompson; Paul V. Biron et al. W3C. 5 April 2012. W3C Recommendation. URL: https://www.w3.org/TR/xmlschema11-2/

E.2 参考情報の参考文献

[DataCite]
DataCite Metadata Schema. DataCite Metadata Working Group. DataCite e.V. 16 August 2019. URL: https://schema.datacite.org/
[DATETIME]
Date and Time Formats. W3C. 27 August 1998. W3C Note. URL: https://www.w3.org/TR/NOTE-datetime
[DATS]
Data Tag Suite. Alejandra Gonzalez-Beltran; Philippe Rocca-Serra. NIH Big Data 2 Knowledge bioCADDIE and NIH Data Commons projects. 2016. URL: https://datatagsuite.github.io/docs/html/
[DBPEDIA-ONT]
DBPedia ontology. URL: http://dbpedia.org/ontology/
[DCAP]
Guidelines for Dublin Core Application Profiles. Karen Coyle; Thomas Baker. DCMI. 18 May 2009. DCMI Recommended Resource. URL: http://dublincore.org/documents/profile-guidelines/
[DCAT-AP]
DCAT Application Profile for data portals in Europe. Version 1.2.1. European Commission. 28 May 2019. URL: https://joinup.ec.europa.eu/solution/dcat-application-profile-data-portals-europe
[DCAT-AP-IT]
Profilo metadatazione DCAT-AP_IT. AgID & Team Digitale. URL: https://docs.italia.it/italia/daf/linee-guida-cataloghi-dati-dcat-ap-it/it/stabile/dcat-ap_it.html
[DCAT-AP-NO]
Standard for beskrivelse av datasett og datakataloger (DCAT-AP-NO). URL: https://doc.difi.no/dcat-ap-no/
[DCAT-AP-SE]
DCAT-AP-SE: Swedish recommendation for DCAT-AP1.1. Matthias Palmer. URL: https://lankadedata.se/spec/DCAT-AP-SE
[DCAT-AP.de]
Vokabulare und Dokumente fur DCAT-AP.de. URL: https://dcat-ap.de/def/
[DCAT-BE]
Linking data portals across Belgium.. URL: http://dcat.be/
[DCAT-UCR]
Dataset Exchange Use Cases and Requirements. Jaroslav Pullmann; Rob Atkinson; Antoine Isaac; Ixchel Faniel. W3C. 17 January 2019. W3C Note. URL: https://www.w3.org/TR/dcat-ucr/
[DOAP]
Description of a Project. Edd Wilder-James. URL: https://github.com/ewilderj/doap/wiki
[DWBP]
Data on the Web Best Practices. Bernadette Farias Loscio; Caroline Burle; Newton Calegari. W3C. 31 January 2017. W3C Recommendation. URL: https://www.w3.org/TR/dwbp/
[EARL10-Schema]
Evaluation and Report Language (EARL) 1.0 Schema. Shadi Abou-Zahra. W3C. 2 February 2017. W3C Note. URL: https://www.w3.org/TR/EARL10-Schema/
[FAIR]
The FAIR Guiding Principles for scientific data management and stewardship. Mark D. Wilkinson et al. Nature. Scientific Data, vol. 3, Article nr. 160018. URL: https://doi.org/10.1038/sdata.2016.18
[GeoDCAT-AP]
GeoDCAT-AP: A geospatial extension for the DCAT application profile for data portals in Europe. Version 1.0.1. European Commission. 2 August 2016. URL: https://joinup.ec.europa.eu/solution/geodcat-application-profile-data-portals-europe
[GeoDCAT-AP-IT]
GeoDCAT-AP in Italy, the national guidelines published. URL: https://joinup.ec.europa.eu/news/geodcat-apit
[HCLS-Dataset]
Dataset Descriptions: HCLS Community Profile. Alasdair Gray; M. Scott Marshall; Michel Dumontier. W3C. 14 May 2015. W3C Note. URL: https://www.w3.org/TR/hcls-dataset/
[HTML-RDFa]
HTML+RDFa 1.1 - Second Edition. Manu Sporny. W3C. 17 March 2015. W3C Recommendation. URL: https://www.w3.org/TR/html-rdfa/
[HYDRA]
Hydra Core Vocabulary. Markus Lanthaler. Hydra W3C Community Group. 15 March 2018. Unofficial Draft. URL: https://www.hydra-cg.com/spec/latest/core/
[IANA-RELATIONS]
Link Relations. IANA. URL: https://www.iana.org/assignments/link-relations/
[IANA-URI-SCHEMES]
Uniform Resource Identifier (URI) Schemes. IANA. URL: https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml
[INSPIRE-DoC]
INSPIRE Registry: Degrees of conformity. European Commission. URL: http://inspire.ec.europa.eu/metadata-codelist/DegreeOfConformity/
[INSPIRE-SDST]
INSPIRE Registry: Spatial data service types. European Commission. URL: http://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceType/
[IRI]
Internationalized Resource Identifiers (IRIs). M. Duerst; M. Suignard. IETF. January 2005. Proposed Standard. URL: https://tools.ietf.org/html/rfc3987
[ISO-19115]
Geographic information -- Metadata. ISO/TC 211. ISO. 2003. International Standard. URL: https://www.iso.org/standard/26020.html
[ISO-19115-1]
Geographic information -- Metadata -- Part 1: Fundamentals. ISO/TC 211. ISO. 2014. International Standard. URL: https://www.iso.org/standard/53798.html
[ISO-19128]
Geographic information -- Web map server interface. ISO/TC 211. ISO. 2005. International Standard. URL: https://www.iso.org/standard/32546.html
[ISO-19142]
Geographic information -- Web Feature Service. ISO/TC 211. ISO. 2010. International Standard. URL: https://www.iso.org/standard/42136.html
[ISO-26324]
Information and documentation -- Digital object identifier system. ISO/TC 46/SC 9. ISO. 2012. International Standard. URL: https://www.iso.org/standard/43506.html
[ISO-IEC-25012]
ISO/IEC 25012 - Data Quality model. URL: http://iso25000.com/index.php/en/iso-25000-standards/iso-25012
[JSON-LD]
JSON-LD 1.0. Manu Sporny; Gregg Kellogg; Markus Lanthaler. W3C. 16 January 2014. W3C Recommendation. URL: https://www.w3.org/TR/json-ld/
[LinkedDataPatterns]
Linked Data Patterns: A pattern catalogue for modelling, publishing, and consuming Linked Data. Leigh Dodds; Ian Davis. 31 May 2012. URL: http://patterns.dataincubator.org/book/
[MDR-AR]
Named Authority List: Access rights. Publications Office of the European Union. URL: https://publications.europa.eu/en/web/eu-vocabularies/at-dataset/-/resource/dataset/access-right
[N3]
Notation3 (N3): A readable RDF syntax. Tim Berners-Lee; Dan Connolly. W3C. 14 January 2008. W3C Team Submission. URL: https://www.w3.org/TeamSubmission/2008/SUBM-n3-20080114/
[netCDF]
Network Common Data Form (NetCDF). UNIDATA. URL: https://www.unidata.ucar.edu/software/netcdf/
[ODRS]
Open Data Rights Statement Vocabulary. Leigh Dodds. ODI. 29 July 2013. URL: http://schema.theodi.org/odrs
[OpenAPI]
OpenAPI Specification. Darrell Miller; Jeremy Whitlock; Marsh Gardiner; Mike Ralphson; Ron Ratovsky; Uri Sarid; Tony Tam; Jason Harmon. OpenAPI Initiative. URL: https://www.openapis.org/
[OpenSearch]
OpenSearch 1.1 Draft 6. DeWitt Clinton. OpenSearch. 17 April 2018. URL: https://github.com/dewitt/opensearch/blob/master/opensearch-1-1-draft-6.md
[OWL2-SYNTAX]
OWL 2 Web Ontology Language Structural Specification and Functional-Style Syntax (Second Edition). Boris Motik; Peter Patel-Schneider; Bijan Parsia. W3C. 11 December 2012. W3C Recommendation. URL: https://www.w3.org/TR/owl2-syntax/
[RDF-SYNTAX-GRAMMAR]
RDF 1.1 XML Syntax. Dave Beckett. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf-syntax-grammar/
[RDF11-CONCEPTS]
RDF 1.1 Concepts and Abstract Syntax. Richard Cyganiak; David Wood; Markus Lanthaler. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf11-concepts/
[RDF11-PRIMER]
RDF 1.1 Primer. Guus Schreiber; Yves Raimond. W3C. 24 June 2014. W3C Note. URL: https://www.w3.org/TR/rdf11-primer/
[RE3DATA-SCHEMA]
Metadata Schema for the Description of Research Data Repositories: version 3. Jessika Rucknagel et al. GFZ Potsdam. 17 December 2015. URL: https://doi.org/10.2312/re3.008
[RFC3986]
Uniform Resource Identifier (URI): Generic Syntax. T. Berners-Lee; R. Fielding; L. Masinter. IETF. January 2005. Internet Standard. URL: https://tools.ietf.org/html/rfc3986
[SCHEMA-ORG]
Schema.org. URL: https://schema.org/
[SDW-BP]
Spatial Data on the Web Best Practices. Jeremy Tandy; Linda van den Brink; Payam Barnaghi. W3C. 28 September 2017. W3C Note. URL: https://www.w3.org/TR/sdw-bp/
[SHACL]
Shapes Constraint Language (SHACL). Holger Knublauch; Dimitris Kontokostas. W3C. 20 July 2017. W3C Recommendation. URL: https://www.w3.org/TR/shacl/
[ShEx]
Shape Expressions Language 2.1. Shape Expressions W3C Community Group. 17 November 2018. Draft Community Group Report. URL: http://shex.io/shex-semantics/
[SPARQL11-QUERY]
SPARQL 1.1 Query Language. Steven Harris; Andy Seaborne. W3C. 21 March 2013. W3C Recommendation. URL: https://www.w3.org/TR/sparql11-query/
[SPARQL11-SERVICE-DESCRIPTION]
SPARQL 1.1 Service Description. Gregory Williams. W3C. 21 March 2013. W3C Recommendation. URL: https://www.w3.org/TR/sparql11-service-description/
[StatDCAT-AP]
StatDCAT-AP ? DCAT Application Profile for description of statistical datasets. Version 1.0.1. European Commission. 28 May 2019. URL: https://joinup.ec.europa.eu/solution/statdcat-application-profile-data-portals-europe
[Turtle]
RDF 1.1 Turtle. Eric Prud'hommeaux; Gavin Carothers. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/turtle/
[VCARD-RDF]
vCard Ontology - for describing People and Organizations. Renato Iannella; James McKinney. W3C. 22 May 2014. W3C Note. URL: https://www.w3.org/TR/vcard-rdf/
[VIVO-ISF]
VIVO-ISF Data Standard. URL: https://github.com/vivo-isf/vivo-isf
[VOCAB-ADMS]
Asset Description Metadata Schema (ADMS). Phil Archer; Gofran Shukair. W3C. 1 August 2013. W3C Note. URL: https://www.w3.org/TR/vocab-adms/
[VOCAB-DATA-CUBE]
The RDF Data Cube Vocabulary. Richard Cyganiak; Dave Reynolds. W3C. 16 January 2014. W3C Recommendation. URL: https://www.w3.org/TR/vocab-data-cube/
[VOCAB-DCAT-20140116]
Data Catalog Vocabulary (DCAT). Fadi Maali; John Erickson. W3C. 16 January 2014. W3C Recommendation. URL: https://www.w3.org/TR/2014/REC-vocab-dcat-20140116/
[VOCAB-DQV]
Data on the Web Best Practices: Data Quality Vocabulary. Riccardo Albertoni; Antoine Isaac. W3C. 15 December 2016. W3C Note. URL: https://www.w3.org/TR/vocab-dqv/
[VOCAB-ORG]
The Organization Ontology. Dave Reynolds. W3C. 16 January 2014. W3C Recommendation. URL: https://www.w3.org/TR/vocab-org/
[VOCAB-SSN]
Semantic Sensor Network Ontology. Armin Haller; Krzysztof Janowicz; Simon Cox; Danh Le Phuoc; Kerry Taylor; Maxime Lefrancois. W3C. 19 October 2017. W3C Recommendation. URL: https://www.w3.org/TR/vocab-ssn/
[VOID]
Describing Linked Datasets with the VoID Vocabulary. Keith Alexander; Richard Cyganiak; Michael Hausenblas; Jun Zhao. W3C. 3 March 2011. W3C Note. URL: https://www.w3.org/TR/void/
[W3C-BASIC-GEO]
Basic Geo (WGS84 lat/long) Vocabulary. Dan Brickley. W3C Semantic Web Interest Group. 1 February 2006. URL: https://www.w3.org/2003/01/geo/
[WFS]
Web Feature Service 2.0 Interface Standard. Panagiotis (Peter) A. Vretanos. OGC. 10 July 2014. OGC Interface Standard. URL: http://www.opengeospatial.org/standards/wfs
[WMS]
Web Map Service Implementation Specification. Jeff de la Beaujardiere. OGC. 15 March 2006. OpenGIS Implementation Standard. URL: http://www.opengeospatial.org/standards/wms
[WSDL20]
Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language. Roberto Chinnici; Jean-Jacques Moreau; Arthur Ryman; Sanjiva Weerawarana et al. W3C. 26 June 2007. W3C Recommendation. URL: https://www.w3.org/TR/wsdl20/
[ZaveriEtAl]
Quality assessment for Linked Data: A Survey. Amrapali Zaveri et al. IOS Press. 2015. Semantic Web, vol. 7, no. 1, pp. 63-93. URL: https://doi.org/10.3233/SW-150175