【注意】 このドキュメントは、W3CのData on the Web Best Practices W3C Recommendation 31 January 2017の和訳です。
このドキュメントの正式版はW3Cのサイト上にある英語版であり、このドキュメントには翻訳に起因する誤りがありえます。誤訳、誤植などのご指摘は、訳者までお願い致します。
First Update: 2017年2月23日
公開以後に報告されたエラーや問題がないか正誤表を確認してください。
この仕様の英語版が唯一の規範のバージョンです。非規範の翻訳版も利用可能かもしれません。
Copyright © 2017 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and document use rules apply.
このドキュメントでは、自律的エコシステムのサポートに役立つことを目指した、ウェブ上でのデータの公開と利用に関するベスト・プラクティスを提供します。データは、人間と機械が発見し、理解できるべきです。データの利用時に際しては、データの最初の作成者が提供するのか外部関係者が提供するのかに関わらず、その利用方法も発見できるようになっているべきであり、データの公開者の努力も認識されるべきです。簡潔に言えば、これらのベスト・プラクティスに従うことにより、公開者と利用者の相互作用が容易になります。
この項は、このドキュメントの公開時のステータスについて記述しています。他のドキュメントがこのドキュメントに取って代わることがありえます。現行のW3Cの刊行物およびこの技術報告の最新の改訂版のリストは、http://www.w3.org/TR/のW3C技術報告インデックスにあります。
ウェブ上のデータのベスト・プラクティス・ワーキンググループは、(1) オープン・データのエコシステムを開発し、開発者と公開者との間のよりよいコミュニケーションを促進するため、(2) 公開者に指針を提供し、データの管理方法の一貫性を向上させ、ひいてはデータの再利用を促進するため、(3) 開発者がいかなる技術を用いることを選択しても、開発者間のデータの信頼性を培い、真の革新の可能性を高めるために設立されました。このベスト・プラクティス・ドキュメントは、データ品質語彙とデータセット利用語彙によって補完されます。
このドキュメントは、ウェブ上のデータのベスト・プラクティス・ワーキンググループによって勧告として発表されました。このドキュメントに関してコメントを行いたい場合には、public-dwbp-comments@w3.org(購読、アーカイブ)にお送りください。どのようなコメントでも歓迎します。
ワーキンググループの実装報告書を参照してください。
このドキュメントは、W3Cメンバー、ソフトウェア開発者、他のW3Cグループ、および他の利害関係者によりレビューされ、W3C勧告として管理者の協賛を得ました。これは確定済みドキュメントであり、参考資料として用いたり、別のドキュメントで引用したりすることができます。勧告の作成におけるW3Cの役割は、仕様に注意を引き付け、広範囲な開発を促進することです。これによってウェブの機能性および相互運用性が増強されます。
このドキュメントは、2004年2月5日のW3C特許方針の下で活動しているグループによって作成されました。W3Cは、このグループの成果物に関連するあらゆる特許の開示の公開リストを維持し、このページには特許の開示に関する指示も含まれています。不可欠な請求権(Essential Claim(s))を含んでいると思われる特許に関して実際に知っている人は、W3C特許方針の6項に従って情報を開示しなければなりません。
このドキュメントは、2015年9月1日のW3Cプロセス・ドキュメントによって管理されています。
この項は非規範的です。
以下に記述しているベスト・プラクティスは、データ交換用の媒体としてのウェブの継続的な拡張を促進し、有効とするために開発されました。世界中の政府によるオープン・データのオンライン共有の拡大[OKFN-INDEX] [ODB] [ODB]、研究データ同盟(Research Data Alliance)[RDA]などの組織によって奨励されている研究データのオンライン出版の増加、ソーシャル・メディアのデータの収集、分析およびオンライン出版、情報のクラウド・ソーシング、フランス国立図書館[BNF]におけるような重要な文化遺産コレクションのウェブ上のプレゼンスの向上、オープン・リンクト・データ・クラウド[LODC]の継続的な拡大は、データを公開するためにウェブの利用が拡大している例の一部です。
しかし、この拡大は形式に一貫性がなく、多くの場合、ある事実を別の事実とリンク付け、関連する資源を発見し、インタラクティブに視覚化するオープン・ウェブ・プラットフォームの性能の潜在性を十分には活用できていません。
広い意味で、データの公開者は、データを公開するかアクセスを制御するかのどちらかの方法で共有することを目指します。データの利用者(自身が作成者でもありえる)は、データが正確で、定期的に更新され、常に利用可能であることが保証されている場合に特に、そのデータを発見し、利用し、リンクしたいと考えます。これにより、データの公開者と利用者との間に共通理解に対する根本的な必要性が生じます。この共通認識がなければ、データの公開者の努力はデータの利用者の望みと一致しないかもしれません。
ウェブの開放性と柔軟性は、データを発見し理解するのが容易な方法で表現、記述、利用可能にする方法など、データの公開者とデータの利用者にとって新たな課題を生み出しています。例えば、データを表現するために1つのデータ・モデルとデータのアクセス制御を行うデータベース管理システム(DBMS)があるような従来のデータベースとは対照的に、ウェブ上のデータは、データを表現しアクセスする複数の方法の存在が可能です。課題の詳細については、ウェブ上のデータの課題の項を参照してください。
このような状況では、データの管理方法の一貫性を改善する指針を公開者に提供することが重要になります。このような指針は、どのようなテクノロジーの利用を選択しても、データの再利用を促進し、開発者間のデータへの信頼を醸成し、真の革新の可能性が高まります。
しかし、すべてのデータとメタデータがオープンに共有されるべきというわけではありません。セキュリティ、商業上の機密情報や、とりわけ、個人のプライバシーを考慮する必要があります。どのデータをどの状況で共有すべきかに関する方針を決定するのはデータの公開者です。データ共有方針により、漏洩のリスクが評価され、安全な認証や認可などの、機密性のあるデータを保護するために取るべき適切なセキュリティ対策が決定される可能性が高いです。
状況により、個人に関する機密情報には、氏名、住所、電子メール・アドレス、国民識別番号、IPアドレス、車両登録番号、運転免許証番号、顔、指紋または筆跡、クレジット・カード番号、デジタルID、生年月日、出生地、遺伝情報、電話番号、ログイン名、ハンドル・ネーム、ニックネーム、健康記録が含まれるかもしれません。そのような情報の一部をオープンに共有したり、さらには制御された環境下で共有したりすることは、安全なように思われますが、複数の情報源のデータを組み合わせることで、想定外に個人の識別が可能となりえることを公開者は心に留めておくべきです。
ウェブ上でデータを公開するための一般的なベスト・プラクティスは、標準を用いることです。様々な組織が、特定のドメインとアプリケーションに関連付けられているデータセットの公開に特化した標準を、そのデータに興味があるユーザのコミュニティが関与する形で規定しています。これらの標準は、これらのコミュニティのユーザ間で情報をやり取りするための共通方式を定義しています。例えば、交通機関の時刻表を公開するために使用できる標準には、General Transit Feed Specification[GTFS]とService Interface for Real Time Information [SIRI]の2つがあります。これらは、標準化された用語、標準化されたデータ形式、標準化されたデータ・アクセスを組み合わせて規定しています。別の一般的なベスト・プラクティスは、文字および文字列データを処理するためにユニコードを用いることです。ユニコードにより、多言語のテキスト処理が改善され、ソフトウェアのローカライゼーションがより容易になります。
ベスト・プラクティスは、データ形式、データ・アクセス、データ識別子、メタデータなどの、データの公開と利用に関する様々な側面をカバーしています。ウェブ上のデータのベスト・プラクティスのスコープを定め、必要な機能を導き出すために、DWBPワーキンググループは、ウェブ上でのデータの一般的な公開方法とその利用方法のシナリオを表すユースケース[DWBP-UCR]をまとめました。このユースケースから導き出された要件は、ドメインとアプリケーションに依存しないベスト・プラクティスの開発を導くために用いられました。しかし、それらは、他のベスト・プラクティスのドキュメントや、より専門的な状況をカバーする標準によって拡張したり補完したりすることができます。例えば、語彙に関しては、W3Cのリンクト・データ公開のためのベスト・プラクティス[LD-BP]は有益な参考文献です。ODRLというライセンスやその他の許諾、義務ステートメントの表現に特化した勧告[ODRL-model] や、来歴に関する一連の標準[PROV-Overview]があり、ここで紹介するベスト・プラクティスは、ウェブ上の空間データのベスト・プラクティス[SDW-BP]による空間的および時間的なデータの発見可能性、アクセス可能性、相互運用性に関するより特化したアドバイスをカバーするように拡張されています。
DWBPはリンクト・データの利用を推奨していますが、CSVなどの他のオープンな形式のウェブ上のデータに関するベスト・プラクティスも奨励します。データ・ポイント間をリンク付けするウェブの可能性を最大化する方法で、CSVファイルを含む表形式のデータを共有する方法は、表形式データ入門[Tabular-Data-Primer]で記述されています。
データの公開者によるDWBPの採用が促進されるように、理解、処理可能性、発見可能性、再利用、信頼、リンク可能性、アクセス、相互運用性という、多くの明確なメリットを明らかにしています。これらについては、ベスト・プラクティスのメリットの項で説明しており、ベスト・プラクティスと関連付けています。
この項は非規範的です。
このドキュメントでは、主にウェブ上にデータを公開する人に合わせて調整したベスト・プラクティスを提示しています。ベスト・プラクティスは、情報管理担当者、開発者、さらに、ウェブ上の研究データの共有や再利用に関心のある科学者などのより広いグループのニーズに合うように設計されています。データの公開者が主な対象者ですが、関連する取り組みに従事しているすべての人々も熟知していることをお奨めします。技術的な仕様で必要とされる正確さと明確さを確保しつつ、ドキュメントをできる限り読みやすく、利用できるようにするために、あらゆる試みを行いました。
このドキュメントの読者は、多くのデータ形式に加え、資源やURIなどのウェブ・アーキテクチャ[WEBARCH]の一部の基本概念にも精通していることが期待されます。個々のベスト・プラクティスの規範的な要素が、意図する結果です。可能な実装方法を提案しており、適切な場合には、特定の技術の利用を推奨しています。語彙とデータ・モデルに関する基本知識は、このドキュメントの一部の側面をよりよく理解するのに役立ちます。
この項は非規範的です。
このドキュメントは、次のベスト・プラクティスにのみ関係しています。
上記のように、ベスト・プラクティスに従っているかどうかは、指針として提供している可能な実装アプローチではなく、意図する結果に照らして判断すべきです。ウェブについて一緒に学び、進化させるにつれ、ベスト・プラクティスは常に改善の対象となります。
この項は非規範的です。
下記の図は、このドキュメントで検討しているコンテキストを示しています。一般的に、ウェブ上のデータの公開と利用のために提案されるベスト・プラクティスは、データセットと配信に関するものです。データは、データセットの特定の物理形式である様々な配信で公開されます。データとは「記録可能で、暗黙の意味を有する既知の事実を意味します」[Navathe]。この配信により、大規模なデータの共有が容易になり、目的、対象者、関心またはライセンスとは関係なく、複数のデータの利用者のグループがデータセットを利用できるようになります。この異質性と、データの公開者とデータの利用者が見知らぬ同士でありえるという事実から考えると、構造メタデータ、記述メタデータ、アクセス情報、データ品質情報、起源情報、ライセンス情報、利用情報などの、信頼性と再利用にも貢献しうるデータセットと配信に関する何らかの情報を提供する必要があります。
ウェブ上でのデータの公開と共有の重要な側面は、ウェブ・アーキテクチャの基礎[WEBARCH]に関係しています。これと関連のある側面としては、資源を識別するためにURIを用いるべきであるという識別の原則があります。このドキュメントの文脈では、資源は、データセット全体またはあるデータセットの特定のアイテムでありえます。すべての資源は、参照でき、複数の資源間をURIでリンクできるように、安定的なURIで公開されるべきです。最後に、データセット間の相互運用性を促進するために、データ語彙と標準の採用が重要です。
この項は非規範的です。
このドキュメントでは、下記の名前空間接頭辞を用います。
| 接頭辞 | 名前空間IRI | 説明 |
|---|---|---|
| dcat | http://www.w3.org/ns/dcat# | データ・カタログ語彙(DCAT) |
| dct | http://purl.org/dc/terms/ | DCMI(Dublin Core Metadata Initiative)メタデータ語彙 |
| dqv | http://www.w3.org/ns/dqv# | DWBPデータ品質語彙(DQV) |
| duv | http://www.w3.org/ns/duv# | DWBPデータセット利用語彙(DUV) |
| foaf | http://xmlns.com/foaf/0.1/ | FOAF(Friend of a Friend)語彙 |
| oa | http://www.w3.org/ns/oa# | ウェブ・アノテーション・オントロジー |
| owl | http://www.w3.org/2002/07/owl# | ウェブ・オントロジー言語(OWL) |
| pav | http://pav-ontology.github.io/pav/ | 来歴、オーサリングおよびバージョン付けオントロジー(PAV) |
| prov | http://www.w3.org/ns/prov# | 来歴オントロジー(PROV) |
| rdf | http://www.w3.org/1999/02/22-rdf-syntax-ns# | RDF(Resource Description Framework) |
| rdfs | http://www.w3.org/2000/01/rdf-schema# | RDFスキーマ語彙(RDFS) |
| skos | http://www.w3.org/2004/02/skos/core# | SKOS(Simple Knowledge Organization System) |
この項では、ウェブ上のデータのベスト・プラクティスを記述するために用いるテンプレートを示します。
ベスト・プラクティスのテンプレート
ベスト・プラクティスに関する簡単な説明
この項では2つの重要な質問に答えます。
ベスト・プラクティスで取り組んだ問題のフル・テキストの説明も提供される可能性があります。これは、任意の長さでありえますが、数行以下の文であることが多いです。
データの公開者がベスト・プラクティスに従った場合に可能となるはずのこと。
可能な実装方法を説明しています。執筆時点で利用可能な最善のアドバイスを示していますが、特定の状況や将来的な開発によっては、意図する結果を達成するためには別の実装方法がより適切であることがありえます。
ベスト・プラクティスが満たされているかの検証方法に関する情報。これは機械的に検証可能でないかもしれなし、あるかもしれません。
ベスト・プラクティスの関連性に関する情報。これは、ウェブ上のデータのベスト・プラクティス ユースケース及び要件ドキュメント[DWBP-UCR]で記述されている1つ以上の関連要件によって記述されています。
この項には、データの公開者とデータの利用者が、ウェブ上でデータを公開し利用する時に直面する様々な課題を乗り越えるために役に立つようにデータの公開者が用いるベスト・プラクティスが含まれています。課題ごとに1つ以上のベスト・プラクティスを提案しており、それに関してはウェブ上のデータの課題の項で説明しています。
各ベスト・プラクティスは、その開発を導いたウェブ上のデータのベスト・プラクティス ユースケース及び要件ドキュメント[DWBP-UCR]の1つ以上の要件に関連付けられています。各ベスト・プラクティスには、その関連性の根拠としてこれらの要件を少なくとも1つ掲載しています。
一部のベスト・プラクティスを適用したRDFの例を、Turtle[Turtle]またはJSON-LD[JSON-LD]を用いて示しています。
ウェブは、オープンな情報空間であり、会社の内部情報システムのような特定の状況が存在しないということは、メタデータの提供が基本要件であることを意味します。十分なメタデータが提供されていなければ、公開者以外の誰かがデータを発見したり再利用したりすることはできないでしょう。メタデータは、データの利用者がデータの意味、その構造をより理解し、権利、ライセンス条項、データを作成した組織、データ品質、データ・アクセス方法、データセットの更新スケジュールなどのその他の課題を明確にするために役立つ追加情報を提供します。公開者は、人間が読める情報を複数の言語で提供し、できる限り、対象とするユーザが理解する言語で情報を提供することが推奨されます。
メタデータは、データセットの発見や再利用などの目的に役立つように用いることができ、資源の1つのプロパティーからデータセット全体または特定の組織のすべてのデータセットまでの、様々なレベルの粒度を考慮して割り当てることができます。メタデータは、様々な種類のものでもありえます。これらの種類は、様々な分類基準を用いて、様々なタクソノミーに分類できます。例えば、あるタクソノミーは、記述、構造、管理という特性に応じた3種類のメタデータを定義することができます。別のタクソノミーは、例えば、発見と再利用などの、メタデータを用いる目的に応じたスキームを用いてメタデータの種類を定義することができます。
ベスト・プラクティス1: メタデータを提供する。
人間のユーザとコンピュータ・アプリケーションの両方にメタデータを提供してください。
データの公開者とデータの利用者は見知らぬ同士でありえるため、メタデータの提供は、ウェブ上でデータを公開する際の基本要件です。そして、データセットや配信を表す他の重要な側面の提供に加え、人間のユーザとコンピュータ・アプリケーションがデータを理解するのに役立つ情報を提供することが不可欠です。
人間はメタデータを理解でき、コンピュータ・アプリケーション、とりわけユーザ・エージェントはそれを処理できます。
人間が読めるメタデータを提供するために可能なアプローチ
機械可読なメタデータを提供するために可能なアプローチ
人間が読めるメタデータの記述が利用できるかを確認してください。
有効な機械可読形式で文法エラーなしにメタデータを利用できるかを確認してください。
関連要件: R-MetadataAvailable、R-MetadataDocum、R-MetadataMachineRead
ベスト・プラクティス2: 記述メタデータを提供する。
データセットと配信に関する全般的な特性を記述したメタデータを提供してください。
データセットに記述情報を明示的に提供することにより、ユーザ・エージェントはウェブで利用可能なデータセットを自動的に発見できるようになり、それにより、人間はデータセットとその配信の性質を理解できるようになります。
人間はデータセットとその配信の性質を解釈することができ、ソフトウェア・エージェントはデータセットと配信を自動的に発見することができます。
記述メタデータには、データセットに関する以下の全般的な特性を含むことができます。
記述メタデータには、配信に関する以下の全般的な特性を含むことができます。
記述メタデータの機械可読バージョンは、データセットを記述するためにW3Cが勧告している語彙、つまり、データ・カタログ語彙[VOCAB-DCAT]を用いて提供できます。これは、データセットを抽象的なエンティティーとして記述できる枠組みを提供します。
データセットの全般的な特性が、データセット自体のメタデータに人間が読める形式で含まれているかを確認してください。
記述メタデータが、有効な機械可読形式で利用可能かを確認してください。
関連要件: R-MetadataAvailable、R-MetadataMachineRead、R-MetadataStandardized
ベスト・プラクティス3: 構造メタデータを提供する。
配信のスキーマおよび内部構造を記述したメタデータを提供してください。
配信の内部構造に関する情報の提供は、データセットを調査したりクエリを行いたいと考えている人にとって不可欠です。これは、人がデータの意味を理解するのにも役立ちます。
人間はデータセットのスキーマを解釈でき、ソフトウェア・エージェントは配信を自動的に処理できます。
人間が読める構造メタデータは、通常、データセットのスキーマのプロパティーまたはカラムを提供します。
機械可読な構造メタデータは、特定の配信の形式に従って利用でき、別のドキュメント内で提供するか、ドキュメントに組み込むことができます。詳細は、下記のリンクを参照してください。
構造メタデータが、人間が読める形式で提供されているかを確認してください。
配信のメタデータに、データセットに関する構造の情報が機械可読形式で文法エラーなく含まれているかを確認してください。
関連要件: R-MetadataAvailable
ライセンスは、ウェブ上のデータに付随する非常に有益な情報です。公開者が採用しているライセンスの種類に応じて、データの共有と再利用には、多かれ少なかれ制限がありえます。ウェブ上のデータの場合、データセットのライセンスは、メタデータ内、または、メタデータの外のリンク先の別のドキュメントで指定できます。
ベスト・プラクティス4: データ・ライセンス情報を提供する。
データの利用を管理するライセンス契約にリンクするかコピーを提供してください。
ライセンス情報の存在は、データの利用者がデータの使いやすさを評価するために不可欠です。ユーザ・エージェントは、潜在的な利用者に提示するデータを含むまたは除外するきっかけとしてライセンス情報の有無を利用できます。
人間は、ある配信の利用に対して可能な制限を記述しているデータ・ライセンス情報を理解でき、ソフトウェア・エージェントは配信のデータ・ライセンスを自動的に検出できます。
データ・ライセンス情報は、人間が読めるライセンス契約に対するリンクまたは組み込まれたコピーとして利用できます。それは、機械可読なライセンス契約に対するリンクまたは組み込まれたコピーとして処理にも利用できます。
ライセンスにリンクするためのプロパティーが含まれている下記の語彙のうち1つを使用できます。
dct:license)cc:license)schema:license)xhtml:license)下記を含む、機械可読な権利言語も幾つか存在しています。
データ・ライセンス情報が、データセット自体のメタデータに人間が読める形式で含まれているかを確認してください。
ユーザ・エージェントが、データセットのデータ・ライセンスを自動的に検出または発見できるかを確認してください。
関連するユースケース: R-LicenseAvailable、R-MetadataMachineRead、R-LicenseLiability
ウェブは、ビジネス、工学、科学のコミュニティを結び付け、以前には想像できなかった共同の機会を作り出します。ウェブ上でデータを公開する挑戦により、その起源に関する適切なレベルの詳細が提供されています。データの作成者は、必ずしもデータの公開者ではない可能性があるため、この関連するメタデータを収集して伝えることが特に重要です。来歴がないと、利用者には、共有されているデータの完全性と信頼性を信頼する方法はありません。データの公開者は、来歴の詳細がどれだけ適切なのかを知ることに対する将来的な利用者コミュニティのニーズに気づいている必要があります。
ベスト・プラクティス5: データの来歴情報を提供する。
データの起源と、行った変更に関する完全な情報を提供してください。
来歴は、データセットの利用者がその品質を判断する手段の1つです。その起源と歴史を理解していると、データを信頼するかどうかを判断するのに役立ち、重要な解釈上のコンテキストを得ることができます。
人間はデータセットの起源と歴史を知り、ソフトウェア・エージェントは来歴情報を自動的に処理できるでしょう。
データ来歴の機械可読バージョンは、W3Cの来歴オントロジー[PROV-O]などの来歴情報を記述するために勧告されているオントロジーを用いて提供できます。
データセットに関する来歴情報が、データセット自体のメタデータに人間が読める形式で含まれていることを確認してください。
コンピュータ・アプリケーションが、データセットに関する来歴情報を自動的に処理できるかを確認してください。
データセットの品質は、それを利用するアプリケーションの品質に大きな影響を与える可能性があります。結果として、データの公開と利用の情報経路にデータ品質に関する情報を含めることが最も重要です。通常、品質の評価には様々な種類の品質次元が関わっており、それぞれが、公開者と利用者に関する特性の集合を表します。データ品質語彙[VOCAB-DQV]は、品質次元ごとに品質を評価するための測度や測定基準などの概念を定義しています。品質指標に依存した特定の評価状況(つまり、データ・コンテンツの一部、データメタ情報の一部、意図する利用に対するデータの適合性の指標となる人間による格付け)に合わせて設計されたヒューリスティックスがあります。
ベスト・プラクティス6: データ品質情報を提供する。
特定の目的に対するデータ品質と適合性に関する情報を提供してください。
データ品質は、元々作成された目的と非常に異なるアプリケーションなどの、特定のアプリケーションに対するデータの適合性に深刻な影響を与える可能性があります。データ品質をドキュメント化すると、データセットの選択プロセスがかなり容易になり、再利用の機会が増えます。領域固有の特異性とは別に、データ品質をドキュメント化し、既知の品質上の課題をメタデータで明示すべきです。
人間とソフトウェア・エージェントは品質を評価でき、そのため、そのアプリケーションに対するデータセットの適合性を評価することができます。
データセット品質メタデータの機械可読バージョンは、DWBPワーキンググループが開発したデータ品質語彙[VOCAB-DQV]を用いて提供できます。
データセットに関する品質情報が、データセット自体のメタデータに含まれていることを確認してください。
コンピュータ・アプリケーションが、データセットに関する品質情報を自動的に処理できるかを確認してください。
関連要件: R-QualityMetrics、R-DataMissingIncomplete、R-QualityOpinions
ウェブ上で公開されたデータセットは、時間の経過とともに変わる可能性があります。スケジュールに従ってデータセットが更新される場合もあれば、データ収集時の改善により更新する価値が生じた時にデータセットが変更される場合もあります。これらの変更に対応するために、新しいバージョンのデータセットを作成することができます。残念ながら、データセットへの変更は、新しいバージョンではなく、まったく別のデータセットとみなすべきであるというコンセンサスはありません。下記では、改訂を既存のデータセットの新しいバージョンと見なすことにほとんどの公開者が同意するだろうと思われるシナリオをいくつか示しています。
一般的に、領域や年が異なる同種のデータなどの、時系列または空間系列を表す複数のデータセットは、同じデータセットの複数のバージョンであると見なされません。その場合、各データセットは、世界に関する異なる見解をカバーしており、新しいデータセットとして扱うべきです。これは、ある都市の週間天気予報のデータを収集したデータセットである場合もあり、その場合、その特定の週のデータを格納するために新しいデータセットが毎週作成されます。
シナリオ1とシナリオ2はメジャー・バージョンのきっかけとなりますが、シナリオ3はマイナー・バージョンのみのきっかけとなります。しかし、バージョンがマイナーかメジャーかをどのように判断するかは、バージョン表示の値を増やさずに変更を行うことを避けるより重要ではありません。データセットを信頼できるものにするためには、小さな変更であっても異なるデータセットのバージョンを記録することが重要です。公開者は、あるデータセットを1人以上のデータの利用者が利用している可能性があることを忘れないようにすべきであり、新しいバージョンをリリースした時に、妥当な措置を講じて利用者に知らせるべきです。リアルタイムのデータの場合、自動化されたタイム・スタンプをバージョンの識別子として提供できます。データセットごとに、公開者はバージョン付けに一貫性のある有益なアプローチを取るべきであり、それにより、データの利用者は変化するデータを理解して処理できます。
ベスト・プラクティス7: バージョン表示を提供する。
データセットごとにバージョン番号や日付を割り当てて示してください。
バージョン情報によって、データセットの改訂を一意に識別できるようになります。データの利用者は、一意性を利用して、時間の経過とともにデータが変更されたかどうか、またどのように変更されたのかを判断し、利用しているデータセットのバージョンを特定することができます。データのバージョン付けが適切であれば、利用者は新しいバージョンのデータセットが利用可能かどうかを把握できます。明示的なバージョン付けは、研究における再現性を可能にし、比較を可能にし、混同を防止します。標準化されたアプローチに従った一意のバージョン番号を用いることで、バージョンの違いに関する利用者の期待値を設定することもできます。
人間とソフトウェア・エージェントは、利用しているデータセットのバージョンを容易に判断できます。
バージョン付け情報を提供するための最良の方法は、状況によって異なりますが、下記のような、従うことができる基本的なガイドラインがあります。
ウェブ・オントロジー言語[OWL2-QUICK-REFERENCE]と、来歴、オーサリングおよびバージョン付けオントロジー[PAV]は、バージョン情報のためのアノテーション・プロパティーをいくつか提供しています。
データセット／配信のメタデータが、一意のバージョン番号や日付を人間が読める形式で提供しているかを確認してください。
コンピュータ・アプリケーションが、データセットや配信の一意のバージョン番号または日付を自動的に検出／発見し、処理できるかを確認してください。
関連要件: R-DataVersion
ベスト・プラクティス8: バージョン履歴を提供する。
各バージョンに行われた変更について記述した完全なバージョン履歴を提供してください。
データを利用するアプリケーションを作成する場合、時間の経過に伴うデータの変動性を理解していることは有益でありえます。データの解釈は、その変遷を理解することでも深まります。相違点の要約が提供されていなければ、異なるバージョンのデータセットがお互いにどのように異なっていかを判断することは通常、非常に困難です。
人間とソフトウェア・エージェントは、一般的にデータセットがバージョンごとにどのように変化するのか、2つの特定のバージョンがどのように異なるのかを理解できます。
公開されているバージョンのリストと、以前のバージョンとの違いをバージョンごとに説明した記述を提供してください。APIは、全履歴の中から最新バージョンを取得する1つの専用のURLでバージョン履歴を公開できます。
公開されたバージョンの一覧が利用可能であることと、各バージョンが前のバージョンとどのように異なるかを正確に記述した変更履歴があることを確認してください。
関連要件: R-DataVersion
識別子は多くの形式を取り、あらゆる情報システムで広く利用されています。ウェブ上でのデータの発見、利用、引用は、HTTP(またはHTTPS)のURI(インターネットを介して逆参照することによって参照できるグローバルに一意な識別子[RFC3986])の利用に根本的に依存します。現在の状況において、URIに関するいくつかのキーポイントを強調することはおそらく価値があるでしょう。
ベスト・プラクティス9: 永続的URIをデータセットの識別子として用いる。
慎重に選択した永続的なURIで各データセットを識別してください。
共通的な識別体系を採用することで、あらゆるステークホルダーが、信頼性の高い方法で基本的なデータの識別と比較プロセスを行うことが可能となります。これらは適切なデータ管理と再利用の前提条件です。
開発者はURIをコードに組み込むことができるため、そのURIが永続的で、時間が経過しても人間が介在する必要なく同じ資源に逆参照できることが重要です。
データセットのステータス、可用性や形式に関係なく、データセットやデータセットに関する情報を長年にわたって発見でき、引用できるでしょう。
永続的であるためには、URIをそのように設計しなければなりません。このトピックに関する著述は多く、例えば、欧州委員会の永続的URIに関する研究[PURI]を参照してください。他の多くの資源へのリンクが含まれています。
データの公開者が、永続性のためにURI空間を直接管理できない、または管理したくない場合は、ウェブの永久的識別子やpurl.orgなどのリダイレクト・サービスを利用する方法もあります。これらは、必要に応じてリダイレクト可能な永続的なURIを提供するため、最終的なロケーションは一時的なものであっても構いません。そのようなサービスの背後にあるソフトウェアは、自由に利用できるため、必要に応じてローカルにインストールして運用することができます。
デジタルオブジェクト識別子(DOI)は同様の代替手段を提供します。この識別子は、いかなるウェブ技術とも関係なく定義されますが、「URIスタブ」に追加することができます。DOIは、研究データや図書館にとって重要なデジタル基盤要素です。
各データセットが、永続性を目的として設計されたURIで識別されていることを確認してください。理想的には、公開者が自身でURI空間を維持できなくなった場合に備えて、関連するウェブ・サイトに、設計スキームの記述と永続性に関する信頼できる誓約を含むのが良いでしょう。
関連要件: R-UniqueIdentifier、R-Citable
ベスト・プラクティス10: 永続的URIをデータセット内の識別子として用いる。
可能であれば、他の人のURIをデータセット内の識別子として再利用してください。
ウェブのパワーは、ネットワーク効果にあります。最初の電話は、2番目の電話が、電話すべき相手が存在するということを意味したときに初めて有用となりました。3番目の電話はそれらの両方をさらに有用にしました。データは、同じもの、同じ場所、同じ概念、同じ出来事、同じ人などに関する他の人のデータを参照すると、その価値がより高まります。これは、データセット全体で同じ識別子を用い、識別子が他のデータセットによって参照できることを確認することを意味します。この識別子がHTTP URIであれば、検索可能であり、より多くのデータを発見できます。
これらの考えは、1つのデータ・ポイントが別のデータ・ポイントにリンクされる5つ星リンクト・データや、リンクが、何らかの方法でデータに作用したり関連したりする可能性があるデータやサービスにさらにリンクされうるハイパーメディアの中心をなすものです。
これがデータのウェブです。
データ項目は、ウェブ上で関連付けられ、人間と機関が同じようにアクセスできるグローバルな情報空間を作成します。
これは単なる話の種であり、このような一般的なドキュメントには、表面的な詳細しか含めることができません。
開発者は、彼らが解決しようとしている問題は、他の人々によって解決済みであることが非常に多いだろうということを知っています。同じように、国、通貨、主題、種、たんぱく質、都市と地域、ノーベル賞受賞者、製品などのなどの明白な物の識別子を探しているなら – すでに誰かがそれを行っています。既存の語彙を発見するために記述された手順[LD-BP]であれば、容易に適合させることができます。
ニーズを満たす既存の識別子が見つからない場合は、他の人があなたのデータにリンクして価値を追加するように、URIの永続性のパターンに従って自分で作成する必要があります。
データセット内で、国、地域、組織や人などの、変わらないものやゆっくりと変わるものへの参照が、URIやURIスタブに追加できる短い識別子で参照されることを確認してください。理想的には、URIは解決すべきですが、解決するかどうかに関わらず、URIはグローバルな範囲の変数として価値があります。
関連要件: R-UniqueIdentifier
ベスト・プラクティス11: データセットのバージョンとシリーズにURIを割り当てる。
全体のシリーズのみでなくデータセットの個々のバージョンにもURIを割り当ててください。
ドキュメントと同様に、多くのデータセットは自然なシリーズまたはグループに分類されます。例えば次のとおりです。
様々な状況において、現在の状況(現在のバス停、現在選出されている職員など)を参照することが適切でしょう。他方で、特定時期に存在していた状況を参照するのが適切な場合もあります。
人間とソフトウェア・エージェントは、特定のバージョンのデータセットや、「データセット・シリーズ」や「最新バージョン」などの概念を参照することができます。
W3Cは、これを行う方法の良い例を提供しています。このドキュメントの(永続的な)URIは、https://www.w3.org/TR/2016/PR-dwbp-20161215/です。この識別子は、ドキュメントを公開した日の不変的なナップショットを指し示します。このドキュメントの「最新バージョン」のURIは、時間の経過とともに変わる可能性がある密接に関連する一連のドキュメントの識別子であるhttps://www.w3.org/TR/dwbp/です。公開時には、これらの2つのURIの解決先は両方ともこのドキュメントです。しかし、このドキュメントの次のバージョンが公開されると、「最新バージョン」のURIはそれを指し示すように変更されますが、日付が付いたURIは変更されないままとなります。
データセットの各バージョンに独自のURIがあり、「最新のバージョン」のURIもあることを確認してください。
関連要件: R-UniqueIdentifier、R-Citable
データが利用者に利用可能となる形式は、そのデータを利用できるようにする際の重要な側面です。世界で最も優れた、最も柔軟性のあるアクセス・メカニズムであっても、利用および再利用を可能にする形式でデータを提供しないと意味がありません。下記では、ファイルと個々のフィールドの両方のレベルで、データの形式を選択する際のベスト・プラクティスについて詳しく説明しています。W3Cは、できる限り広い対象者が利用し、コンピューティング・システムが最も容易に処理できる形式の利用を推奨します。最終的な公開形式を生成するために用いられるデータベース・ダンプやスプレッドシートなどの情報源形式は範囲外です。このドキュメントは、公開するデータを生成するために用いる内部システムではなく、実際に公開するデータに関するものです。
ベスト・プラクティス12: 機械可読な標準化されたデータ形式を用いる。
意図する利用や潜在的な利用に適した、機械可読な標準化されたデータ形式でデータを利用できるようにしてください。
データがよりユビキタスになり、データセットがより大きくより複雑になるにつれ、コンピュータによる処理がますます重要になります。機械可読ではない形式でデータを掲載すると、データの継続的な有用性に大きな制限が課されます。データは、処理されて情報に変換された時に役立ちます。人間がコンピュータを用いて読んだり編集したりできる形式と、機械可読な形式との間には大きな違いがあることに注意してください。後者の用語は、データがコンピュータによって容易に抽出、変換、処理されることを意味します。
標準ではないデータ形式を用いると、コストがかかり、非効率的であり、データの変換時に意味が失われる可能性があります。対照的に、標準化されたデータ形式は、相互運用性に加え、その多くをデータが最初に公開された時には予期できなかったリミックスや視覚化などの将来の利用を可能にします。また、機械可読な標準化された形式のほとんどはロケールに依存しない(locale-neutral)ことに注意することも重要です。
機械は、ウェブ上で公開されたデータを容易に読んで処理することができ、人間は、関連するドメインで通常利用できるコンピュータ処理ツールを用いてデータを処理できます。
CSV、XML、HDF5、JSON、およびR、DF/XML、JSON-LD、TurtleなどのRDFシリアル化構文を含むがこれらに限定されない、容易に解析できる機械可読な標準化されたデータ形式でデータを利用できるようにしてください。
データ形式が、既知の機械可読なデータ形式仕様に準拠しているかを確認してください。
ベスト・プラクティス13: ロケールに依存しないデータ表現を用いる。
ロケールに依存しないデータ構造と値を用いるか、それが可能でない場合は、 データ値で用いるロケールに関するメタデータを提供してください。
機械可読で、特定の言語や文化に特化していないデータ値は、多様な文化的表現の1つを用いた値よりも耐久性があり、誤解されにくいです。日付、通貨、数などは同じように見えるかもしれませんが、異なるロケールでは意味が異なります。例えば、4/7という「日付」は、データが作成された場所によって、4月7日と読まれたり7月4日と読まれたりする可能性があります。同様に、€2,000は、2000ユーロか、2ユーロの厳密な表現かのどちらかです。ロケールに依存しない形式を用いることにより、システムが、ユーザの言語や場所によって異なる特定の交換規則を設定する必要性がなくなります。データがすでにロケール固有の形式である場合、ロケール・パラメータを提供してロケールと言語を明示することにより、ユーザは、どれくらい容易にデータを処理できるかや、自動翻訳サービスを有効とすることができるかを判断できます。
人間とソフトウェア・エージェントは、日付、時刻、通貨、数などを表す文字列の意味を正確に解釈することができます。
最も一般的なデータのシリアル化形式はロケールに依存しません。例えば、xsd:integerやxsd:dateなどのXMLスキーマの型は、ロケールに依存しないデータ交換を目的としています。ロケールに依存しない表現を用いることにより、複雑な解析や誤解なしにデータ値を正確に処理できるようになり、任意のロケールのデータの利用者にとって最も快適な形式でデータを表示できるようにもなります。例えば、「€2000,000」を文字列として格納するのではなく、下記のようにデータ構造を交換することが強く望まれます。
…
"price" {
"value": 2000.00,
"currency": "EUR"
}
…
一部のデータセットには、ロケールに依存しない形式で表示されなかったり、表示できなかったりする値が含まれています。これは特に自然言語のテキストの値に当てはまります。ロケールの影響を受けたテキストや自然言語のテキストを含むことができる個々のデータ・フィールドには、データの言語とロケールを示すために用いる関連する言語タグがあるべきです。このロケール情報は、データの解析や、利用者による値の適切な提示と処理を確保するために利用できます。BCP47[BCP47]は、言語とロケールの識別のための標準を提供します。また、参考情報として、CLDR[CLDR]は、特定のローカライズされた形式を表す場合と、特定のロケール・データ値に対する参照として表す場合の両方のための情報源です。
ロケールに依存する(locale-sensitive)データ値がロケールに依存しない形式で表されていることを確認してください。それが不可能な場合は、関連するロケール・メタデータが提供されているかを確認してください。
関連要件: R-FormatLocalize、R-MetadataAvailable、R-GeographicalContext、R-FormatMachineRead
ベスト・プラクティス14: 複数の形式でデータを提供する。
意図されている利用や潜在的な利用に複数の形式が適している場合、データを複数の形式で利用できるようにしてください。
複数の形式でデータを提供すると、データ変換で発生するコストが削減されます。これにより、変換プロセスでエラーが発生する可能性も最小限に抑えられます。多くのユーザがデータを特定のデータ形式に変換する必要がある場合は、最初からその形式でデータを公開すると、時間と費用が節約され、エラーが何度も防止されます。最終的には、データを処理できるツールとアプリケーションの数が増えます。
できる限り多くのユーザが、自身にとって望ましい形式に変換する必要なく、データを利用できるようになるでしょう。
将来的に必要とされる可能性が最も高いデータ形式と、有用となる可能性が高い選択肢を検討してください。データの公開者は、多くの形式でデータを利用できるようにするために必要な努力と、そのためのコストとのバランスを取らなければなりませんが、少なくとも1つの選択肢を提供すると、データの使いやすさは大きく向上するでしょう。複数の形式でデータを提供するためには、複数の形式で利用できるデータを提供するために内容交渉を用いるというベスト・プラクティスで説明しているとおり、内容交渉を利用できます。
忠告: URIのフラグメント識別子として公開される可能性があるデータセット内のローカル識別子は、様々な形式にまたがって一貫性がなければなりません。
完全なデータセットが複数のデータ形式で利用できるかを確認してください。
関連要件: R-FormatMultiple
語彙は、関心領域を記述し表現するために用いられる概念および関係(「用語」や「属性」とも呼ばれる)を定義します。これらは、特定のアプリケーションで利用できる用語を分類し、可能な関係の特性を示し、それらの用語を利用する際の制約を定義するために用いられます。オントロジー、統制語彙、シソーラス、タクソノミー、コード一覧、セマンティック・ネットワークなど、「語彙」に対していくつかの同義語が作り出されています。
これらの名前で参照されるアーティファクトの間に厳密な区別はありません。しかし、「オントロジー」は、(リンクされた)データセットの資源の記述を構造化するクラスとプロパティーの語彙を示す傾向があります。リレーショナル・データベースでは、これらは表とカラムの名前に対応しており、XMLでは、これらはXMLスキーマで定義される要素に対応しています。オントロジーは、セマンティック・ウェブにおける推論技術の重要な構成要素です。オントロジーを作成するためにW3Cが提供している最初の手段は、RDFスキーマ[RDF-SCHEMA]言語です。ウェブ・オントロジー言語[OWL2-OVERVIEW]のような言語を用いて公理を追加し、より表現力のあるオントロジーを定義することができます。
一方で、「統制語彙」、「概念スキーム」、「知識組織化体系」は、前者の種類の語彙、つまり、(リンクされた)データセットの資源の記述を構造化する語彙で作られた記述に使用できる資源を列挙し、定義します。シソーラスの概念、例えば「アーキテクチャ」は、書籍について記述するために主題フィールドなどで用いられます(書籍に対する「主題」がオントロジーで定義されている場合)。ほとんどの場合、これらの語彙で用語を定義する場合は、複雑な形式は必要ではありません。したがって、それらを表現し交換するために、ISO 25964データ・モデル[ISO-25964]やW3CのSKOS(Simple Knowledge Organization System)[SKOS-PRIMER]などのよりシンプルなモデルが提案されています。
ベスト・プラクティス15: 語彙を再利用する(標準化されたものが望ましい)。
共通語彙(標準化された語彙が望ましい)を用いてデータとメタデータをエンコードしてください。
他の人がすでに利用している語彙を利用すると、コミュニティにおけるコンセンサスの獲得と促進が行われます。これにより、相互運用性が高まり、冗長性が低減し、自身のデータの再利用が促進されます。とりわけ、メタデータ(特に、構造、来歴、品質、バージョン付けメタデータ)に共通語彙を用いることは、データとメタデータの両方の比較と自動処理に役立ちます。さらに、標準に基づくコードと用語を参照すると、類似する要素や値の曖昧さや衝突を避けるのに役立ちます。
データの公開者と利用者の間の相互運用性とコンセンサスが強化されるでしょう。
リンクト・データ公開のためのW3Cベスト・プラクティス[LD-BP]の語彙の項では、既存の語彙の発見、評価、選択に関する指針を提供しています。
Open Geospatial Consortium(OGC)、ISO、W3C、WMO、図書館、研究データ・サービスなどの組織は、誰でも利用できるコード、用語、リンクト・データ語彙のリストを提供しています。重要なのは、データの利用者が値の標準化された意味を検索して利用できるように、データセットまたはそのドキュメントが十分な(人間と機械が読める)コンテキストを提供していることを確認することです。ウェブ環境では、標準化された語彙資源に明白なウェブ・ベースの識別子(URI)を用いることは、これを行うための効果的な方法ですが、より大きな、国境を越える相互運用性のために同じURIに多言語ラベルを付与できることを指摘しておきます。欧州連合の多言語シソーラスであるEurovocが典型的な例です。
リンクト・オープン語彙のリポジトリのような語彙リポジトリや、リンクト・データ公開のためのベスト・プラクティス[LD-BP]やRDFaおよびJSON-LDのコア初期コンテキストなどの技術に特化したベスト・プラクティスで記述されているサービスのリストを用いて、データセットを表現するために用いるクラス、プロパティー、用語、要素、属性が、他のデータセットで用いられている語彙で定義されているものを複製していないことを確認してください。
利用する語彙の用語やコードが、IETF、OGC、W3Cなどの標準開発機関で定義されているか、政府機関などの適切な機関によって公開されているかを確認してください。
関連要件: R-MetadataStandardized、R-MetadataDocum、R-QualityComparable、R-VocabOpen、R-VocabReference
ベスト・プラクティス16: 適切な形式化レベルを選択する。
データと最も可能性の高いアプリケーションの両方に適合する形式セマンティクスのレベルを選択してください。
アルバート・アインシュタインが言ったかどうかは定かではありませんが、何事もできる限りシンプルにしなければなりませんが、シンプルすぎてはいけません。
形式セマンティクスは、詳細な意味を伝える正確な仕様を確立するのに役立ち、複雑な語彙(オントロジー)の利用は、自動推論などのタスクの基礎となりえます。一方で、そのような複雑な語彙を作成し理解するためにはより努力が必要で、それを利用したデータセットの再利用、比較、リンク付けを妨げる可能性があります。
データが詳細な研究課題(A、B、Cが真であり、Dが真でないという事実により、結論Eが導かれる)をサポートするのに十分に豊かであれば、OWLプロファイルのようなものが明らかに適切でしょう[OWL2-PROFILES]。
しかし、バス停のリストに関しては何も複雑なことはありません。
非常にシンプルな語彙を選択することは常に魅力的ですが、危険性もあります。シンプルさを目指すことにより、バス停の地理的な位置が地図に表示されなくなるなど、重要な情報を提供する一部のデータを公開者が除外してしまうことになる可能性があります。したがって、目標は単にデータを共有することではなく、他の人がそれを再利用することであることを念頭に置いてバランスを取らなければなりません。
最も可能性の高いアプリケーションのケースは、必要以上の複雑さなくサポートされるでしょう。
仲間がすでに何を行っているかに目を向けてください。現在のニーズと一致する、またはほぼ一致する、一般的に用いられている語彙が存在している可能性が高いです。おそらく、それが利用すべきものです。
利用したい語彙を見つけることができたとしても、自分のケースには当てはまらない定義域や値域の制限など、利用を難しくするセマンティックな制約に気づきます。そのような状況では、語彙の公開者に連絡し、それに関して話をする価値があることが多いです。おそらく、彼らはその制限を取り除き、語彙をより広く利用する方法についてさらなる指針を提供してくれるでしょう。
W3Cは、語彙の利用と開発に関する課題を議論できるメーリング・リストをpublic-vocabs@w3.org[アーカイブ]で運営しています。
独自の語彙を作成する場合には、他の人が再利用できる可能性を高めるために、セマンティックな制限を自分に有効な範囲で最低限に留めてください。例として、(非常に広く用いられている)SKOSオントロジーの設計者自身は、そのクラスとプロパティにー対して提案されたすべての形式的な公理に関して質問を投げかけ、そのオントロジーの関与を最小限に抑えました。それを利用することは、多くのアプリケーションにとって有益でしたが、その他のアプリケーションのデータでは形式的な矛盾が生じ、SKOSをまったく利用できなくなってしまったため、しばしば拒絶されたのです。例としてskos:broaderというプロパティーは、多くのシソーラス[SKOS-DESIGN]にとって概念間の階層リンクを作成する方法として適していたにも関わらず、推移的なプロパティーとして定義されませんでした。語彙を選択する時には、その種の「幅広い利用のための設計」の根拠を探してください。
この「幅広い利用のための設計」の別の例は、schema.orgにあります。2011年6月に開始されたschema.orgは、プロパティーを利用できるオブジェクトの型を定義するための、規範的ではなく参考情報的なアプローチであるという理由などにより、非常に短期間に大規模に採用されました。例えば、authorというプロパティーの値は、OrganizationかPersonの型に属していると「予想」されるだけです。authorは、CreativeWorkという型に「利用できます」が、これは厳しい制約ではありません。再び、この設計方法によって、schema.orgは、共有するデータをエンコードする際に用いる語彙として適した選択肢となります。
これは、たいてい客観的な検証方法がない、主観的な判断の問題です。一般的なガイドラインとしては、次のものがあります。
ウェブ上のデータに容易にアクセスできるようにすることで、人間と機械の両方が、ウェブ・インフラストラクチャーを用いてデータを共有するメリットを活用できます。デフォルトでは、ウェブは、ハイパーテキスト転送プロトコル(HTTP)というメソッドを用いてアクセスを提供します。これにより、アトミックなトランザクション・レベルでデータへのアクセスが提供されます。これは、ファイルのシンプルな一括ダウンロードによるか、データが複数のファイルに分散されていたり、より高度な検索方法が必要な場合にはAPIによります。一括ダウンロードとAPIという2つの基本的な方法は、互いに排他的ではありません。
一括ダウンロードのアプローチでは、データは一般的にサーバー側で予め処理されており、複数のファイルまたはファイルのディレクトリ・ツリーが、1つのダウンロード可能なファイルとして提供されます。データの公開者は、非ファイル・システム・ソリューションから一括データを検索する場合、データのユーザ・コミュニティに応じて、1つのトランザクションに相当する一連の検索作業をサポートするためにAPIを提供できます。
リアルタイムまたはほぼリアルタイムで作成されるデータの場合、データの公開者は、緊急情報、天気予報データ、システム監視基準などの時間的制約のあるデータに即座にアクセスできるように、自動システムを用いるべきです。一般的に、第三者がそのようなデータを自動的に検索して取得できるようにするためには、APIが利用可能であるべきです。
APIは、リアルタイムのデータ経路の自動化に役立つことに加えて、ウェブのあらゆる種類のデータに適しています。一般的に、それにはダウンロード用ファイルを掲載する以上の作業が必要ですが、明確にドキュメント化された標準に基づく安定したAPIを提供することは価値があるということに気づく公開者が増えています。
一部のデータ公開者にとっては、誰がデータをダウンロードしたのか、どのようにそれを利用したのかを知ることが重要です。この情報を収集するには2つの方法がありえます。まず、公開者は、ユーザに情報提供を要請できます。ユーザがそれを行う動機は、データの継続的な公開の奨励と、自身の取り組みの促進です。次のあまりユーザ・フレンドリーではない方法は、データにアクセスする前に登録を要求することです。いずれの場合も、データセット利用語彙[VOCAB-DUV]は、そのような情報を表すための構造を提供します。ユーザからデータを収集する場合には、公開者は、ユーザから収集した情報を利用する理由と方法(明示的または暗黙的のいずれかの方法で)を説明すべきです。明確な方針がないと、ユーザは情報を提供することを恐れ、そのため、データセットの価値が低下するかもしれません。
ベスト・プラクティス17: 一括ダウンロードを提供する。
利用者が1つのリクエストで完全なデータセットを検索できるようにしてください。
ウェブのデータが多くのURIに分散されているけれども、論理的に1つのコンテナとして編成できる時には、データに一括してアクセスできると便利です。一括アクセスは、データを1つのデータセットとして扱うための一貫性のある手段を提供します。多数の検索で個々のデータにアクセスすることは面倒でありえ、完全なデータセットを再構成するために用いると、データの処理方法に一貫性がなくなる可能性があります。
典型的なユーザが妥当と考えるよりも時間を要する大きなファイルの転送は、専門のファイル転送プロトコルで行えます。
データと利用者ニーズの性質に応じて、可能なアプローチには下記のものがあります。
一括ダウンロードには、データセットについて説明しているメタデータが含まれているべきです。発見メタデータ[VOCAB-DCAT]は、一括ダウンロードの外部でも利用できるべきです。
1回のリクエストで完全なデータセットを取得できるかを確認してください。
関連要件: R-AccessBulk
ベスト・プラクティス18: 大きなデータセットにはサブセットを提供する。
データセットが大きい場合は、ユーザとアプリケーションがデータの有用なサブセットを容易に処理できるようにしてください。
大きなデータセットは、場所を移動させるのが難しいことがあります。ユーザにとって大きなデータセットを保存または解析することが不便なこともあります。ユーザがデータセットのサブセットのみを必要とする場合は、完全なデータセットをダウンロードする必要はありません。さらに、大きいデータセットを利用するウェブ・アプリケーションは、開発者が「遅延読み込み」(lazy loading)を利用し、全体のうちの小さな部分を処理し、必要な時に新しい部分のみを取り込むことができれば、よりうまく機能します。データのサブセットを処理する機能により、オフライン処理もより効率的に機能します。リアルタイム・アプリケーションは、より迅速に更新できるため、特に恩恵を受けます。
人間とアプリケーションは、全てではなく、最も多くのユーザにとって不必要よりも必要なデータである割合が高いデータセットのサブセットにアクセスできます。ドメイン内のユーザが大き過ぎると考える静的なデータセットは、より小さな部分としてダウンロードできるでしょう。APIは、データのスライスまたはフィルタリングされたサブセットを利用できるようにし、その粒度はドメインのニーズとウェブ・アプリケーションの性能要求に依存します。
データセットの予想されるユースケースを考慮し、どの種類のサブセットが最も有用そうであるかを判断してください。APIは通常、転送するデータをカスタマイズできるため、データのサブセットを提供するための最も柔軟なアプローチであり、利用できるサブセットによって必要なデータが提供される可能性と、特定の状況では、– 不必要なデータ – が提供される可能性をより高めます。粒度は、ウェブ・アプリケーションのアクセス速度に適しているべきです。(APIの呼び出しが1秒以内に返されると、アプリケーションは自然な感じのインタラクティブ性を提供できるようになります。データの配信に10秒以上かかれば、ユーザは失敗を疑う可能性があるでしょう。)
データセットをサブセット化する別の方法は、単純にそれをより小さな単位に分割し、それらの単位を個別にダウンロードまたは表示できるようにすることです。
また、データの個々のセクションを別々に(または、予想されるユースケースで保証されている場合には、より小さな部分に)処理できるようにデータセットをマークアップすることも役立つ可能性があります。これを行うための方法の1つは、RDFデータ・キューブ語彙で「スライス」を示すことです。
より小さな単位を検索する複数のリクエストを行うことで、データセット全体を復元できることを確認してください。
関連要件: R-Citable、R-GranularityLevels、R-UniqueIdentifier、R-AccessRealTime
ベスト・プラクティス19: 複数の形式で利用できるデータを提供するために内容交渉を用いる。
複数の形式で利用できるデータを提供するために、ファイル拡張子に加え、内容交渉を利用してください。
例えば、RDFaを用いて、人間が読めるデータと機械可読なデータが混在するHTMLページでデータを提供できます。しかし、ウェブ・アーキテクチャ[WEBARCH]とDCAT[VOCAB-DCATT]が明らかにしているように、データセットなどの資源は多くの表現を持つことができます。同じデータをJSON、XML、RDF、CSV、HTMLで利用できるかもしれません。これらの複数の表現はAPIで提供できますが、適切な表現(DCATで配信と呼ばれるもの)を返すために、内容交渉を用いて同じURLから利用できるようにすべきです。特定のURIを用いて、内容交渉を避け、データの個々の表現を直接識別することができます。
内容交渉により、クライアントが行ったリクエストに応じて、同じ資源の異なる資源または異なる表現を提供できるようになります。
可能な実装アプローチは、リクエストされた資源の内容交渉を扱うようにウェブ・サーバーを設定することです。
特定の形式の資源の表現には、URIまたはHTTPリクエストのContent-typeによってアクセスできます。
利用可能な資源の表現を確認し、HTTPリクエスト・ヘッダで受け入れ可能なコンテンツを指定して取得することを試みてください。
ベスト・プラクティス20: リアルタイム・アクセスを提供する。
データがリアルタイムで作成される場合は、ウェブ上でリアルタイムまたはほぼリアルタイムで利用できるようにしてください。
ウェブ上にリアルタイムのデータが存在していれば、重要な時間的制約のあるデータへのアクセスが可能となり、リアルタイムのウェブ・アプリケーションの開発が促進されます。リアルタイム・アクセスは、データの公開者にデータを容易に利用できるようにするリアルタイム・データの公開者に依存します。特定のアプリケーションにリアルタイム・アクセスを提供する必要性は、リフレッシュ速度、データ後処理ステップで導入される待ち時間、インフラストラクチャーの可用性、利用者が必要とするデータを考慮して、個別に評価する必要があります。データにアクセスできるようにすることに加え、データの公開者は、データ・ギャップ、データのエラーおよび異常、公開遅延について記述した追加情報を提供できます。
アプリケーションは、時間が極めて重要なデータに、リアルタイムまたはほぼリアルタイムでアクセスできるでしょう。その場合、リアルタイムとは、データ作成後のミリ秒から数秒後までの範囲を意味します。
可能な実装アプローチは、公開者がウェブ・サービスを設定し、そのウェブ・サービスでリアルタイムのデータを受け取るような通信を提供することで、ポーリングやストリーミングによって利用者が即座に利用できるようになります。
利用者がデータをチェックする頻度が低い場合は、リアルタイムのデータは、利用者がAPIで最新のデータをリクエストした時にポーリングされます。データの公開者は、これらの読み取り専用リクエストが容易になるようにAPIを提供します。
利用者がデータをチェックする頻繁が高い場合は、ストリーミング・データの実装の方が適切でありえ、その場合、データはAPIによりプッシュされます。ストリーミング技術はこのベスト・プラクティスの対象外ですが、サーバーから自動更新を受け取るクライアントに利用できる標準的なプロトコルと技術は多く存在しています(例えば、Server-sent Events、WebSocket、EventSourceAPI)。
関連要件: R-AccessRealTime
ベスト・プラクティス21: 最新のデータを提供する。
データを最新の方法で利用できるようにし、更新頻度を明示してください。
ウェブ上のデータの可用性は、おそらくデータが処理または変更された後の、データの作成または収集時間と密接に一致しているべきです。データの公開を更新頻度と丁寧に同期させることで、利用者の信頼とデータの再利用が促進されます。
一般的に、オンラインで利用可能な最新データが、他のルートでリリースされた最新データを反映できるように、ウェブ上のデータはタイムリーに更新されるでしょう。新しいデータが利用可能になると、その後可能な限り早くウェブ上に公開されるでしょう。
データのバージョン付けのベスト・プラクティスに従って、新しいバージョンのデータセットを定期的にウェブに掲載できます。ウェブへの掲載は、新しいバージョンのデータのリリース過程の一部として行うことができます。その過程でウェブの公開物を配信可能なものにし、個人をその作業の責任者として割り当てることは、データが古くなるを防ぐのに役立つ可能性があります。今後の更新に対する利用者の期待値を設定するために、予想される公開頻度を示した人間が読めるテキストを含むことができ、頻度を示す機械可読なメタデータを提供することもできます。
更新頻度が提示されており、ウェブ上に最近公開されたコピーが、提示している更新頻度で予告されている日よりも古くないことを確認してください。
関連要件: R-AccessUptodate
利用できないデータについては、データへのアクセス方法と、誰がアクセスできるかに関する説明を提供してください。
利用できないデータに関するオンライン・ドキュメントを公開することは、公開者が知識ギャップを明示的に識別する手段を提供します。これは、利用者コミュニティへの状況説明となるため、利用可能であるデータの利用が促進されます。
利用者は、現在のデータセットの参照先のデータが利用できないこと、または、異なる条件の下でのみ利用できることが分かるでしょう。
機械か人間かの状況に応じて、データが利用できないことを示す様々な方法があります。データの公開者は、データが利用できないことを人間が読める形で説明したHTMLドキュメントを公開できます。機械アプリケーション・インターフェースの観点から、人間が読めるメッセージをカスタマイズした適切なHTTPステータス・コードを使用できます。ステータス・コードの例には、303(他を参照)、410(永久的に削除)、503（*データを提供する*サービス利用不可）などが含まれます。
利用可能できなくなった、またはすべてのユーザに利用可能であるわけではないデータへの参照がデータセットに含まれている場合は、何が欠落しているかの説明と、アクセスを得るための手順(可能な場合は)が提示されているかを確認してください。利用できないデータを取得しようとした時に、400または500の範囲の正当なhttp応答コードが返されるかを確認してください。
ベスト・プラクティス23: APIでデータを利用できるようにする。
該当する資源を持っている場合、APIを提供してデータを提供してください。
APIによって、データの利用者に最大限の柔軟性と処理可能性が提供されます。これにより、リアルタイムのデータ利用、リクエストに応じたフィルタリング、原子レベルでのデータ処理性能が可能となります。データセットが大きくて頻繁に更新される場合や非常に複雑である場合は、APIはデータを公開するための最良の選択肢になる可能性が高いです。
開発者は、自身のアプリケーションで利用するためにプログラムでデータにアクセスし、利用者側の努力を必要とせずにデータを更新できます。ウェブ・アプリケーションは、プログラム・インターフェースにクエリを行うことで、特定のデータを取得できます。
APIの作成は、ダウンロード用にデータを掲載するよりも少し複雑です。それには、ウェブ・アプリケーションの構築方法に関する理解が必要です。しかし、ゼロから構築する必要は必ずしもありません。CKANなどのデータ管理プラットフォームを利用している場合は、既存のAPIを有効化することができるでしょう。多くのウェブ開発フレームワークにはAPIのサポートが含まれており、カスタムのAPIを構築するための専用のフレームワークもあります。
Rails(Ruby)、Django(Python)、Express(NodeJS)は、API構築に対する支援を行っているウェブ開発フレームワークの例です。APIフレームワークの例には、Swagger、Apigility、Restify、Restletが含まれます。
検証クライアントが呼び出しをシミュレートでき、APIが予期する応答を返すかを確認してください。
ベスト・プラクティス24: APIの基礎としてウェブ標準を用いる。
APIを設計する時には、ウェブ自体の技術に基づくアーキテクチャ・スタイルを用いてください。
ウェブ標準に基づいて構築されたAPIは、ウェブの強みを活用できます。例えば、HTTP動詞をメソッドとして用い、個々の資源に直接マッピングするURIを用いると、リクエストと応答との密結合を避けるのに役立ち、維持しやすく、多くの開発者が容易に理解して利用できるAPIに役立ちます。ウェブのステートレス性は、迅速なスケーリングを可能にする時に強みとなりえ、ハイパーメディアを用いるとAPIとの豊かな相互作用が可能となります。
RESTなどのウェブ標準に基づくAPIの経験がある開発者は、APIの使い方に関する初期理解を有しています。APIは維持も簡単です。
REST(REpresentational State Transfer)[Fielding][Richardson]は、ウェブAPIでの利用において、ウェブ自体のアーキテクチャを利用するアーキテクチャ・スタイルです。RESTfulなAPIの構築方法に関する本格的な議論は、このドキュメントの範囲を越えていますが、始動時に役に立つ資源や強力なコミュニティが数多く存在しています。利用できるRESTfulな開発フレームワークも数多く存在しています。REST APIの構築をサポートするウェブ開発フレームワークをすでに利用していれば、それを利用することを検討してください。そうでない場合は、RESTを用いたAPIのみのフレームワークを検討してください。
検討すべき実装の別の側面は、データのみでなくリンクでも応答するハイパーメディアAPIを作成することです。リンクは、ウェブをウェブたらしめるものであり、データAPIは、リンクを応答に含めることで、より有益で使えるものになります。リンクは、追加の資源、ドキュメント、ナビゲーションを提供できます。RESTのすべての制約を満たしてはいないAPIであったとしても、応答でリンクを返すことは、豊かな自動ドキュメント化型のサービスに役立ちます。
サービスがカスタム・メソッドの呼び出しに対するトンネルとしてhttpを用いていないことと、URIにメソッド名が含まれていないことを確認してください。
ベスト・プラクティス25: APIに完全なドキュメントを提供する。
APIに関する完全な情報をウェブで提供してください。機能を追加したり変更を行ったりした場合にはドキュメントを更新してください。
開発者はAPIの主な利用者であり、ドキュメントはその品質と有用性に関する最初の手掛かりです。APIのドキュメントが完全で理解しやすければ、開発者はおそらくそれを利用し続ける気になるでしょう。包括的なドキュメントを1か所で提供することにより、開発者は効率的にコードを作成できます。変更点を強調することにより、ユーザが必要に応じて新しい機能を利用し、コードを適用できるようになります。
開発者は、必要なパラメータや何が返されるのか、つまり、APIに関連する全情報を含む、APIの個々の呼び出しに関する詳細情報を取得できるでしょう。一連の値 — 利用方法、更新情報の通知、連絡先情報など — が記述されており、ウェブで容易に閲覧可能であるべきです。また、開発者がAPIクライアント・ソフトウェアを構築するのに役立つように、機械がAPIのドキュメントにアクセスできるようにもなるでしょう。
典型的なAPI参照は、APIが処理できる呼び出しの包括的なリストを提供し、それぞれの目的を説明し、それが認めるパラメータおよび何が返されるかを詳細に示し、1つ以上の利用例を提示します。APIのドキュメントに関する良い傾向の1つは、開発者が検証用に特定の呼び出しを入力すると、自身のユースケースに対してAPIが何を返すかを確認できるようなフォームを提供することです。現在、Swagger、io-docs、OpenApisなど、この種のドキュメントをすばやく作成するために利用できるツールが存在しています。呼び出しによってエラーや用法に関する役立つ情報が返されるように、APIの自動ドキュメント化も行うべきだと述べておくことは重要です。APIのユーザは、問題、提案、バグ・レポートについて管理者に連絡できるべきです。
ドキュメントの品質は、用法や開発者からのフィードバックにも関連しています。ドキュメントに関するユーザからのフィードバックを絶えず得るようにしてください。
APIで可能なすべての呼び出しに関してドキュメントに記載されていることを確認してください。どのパラメータが必須なのかオプションなのか そして個々の呼び出しによって何が返されるのかの詳細が提供されているかを確認してください。
最初に成功した呼び出しまでの時間(Time To First Successful Call)を確認してください(つまり、数分以内にAPIへのリクエストが成功すれば、開発者がそのAPIから離れない可能性が増します)。
関連要件: R-APIDocumented
ベスト・プラクティス26: 互換性のないAPIの変更を避ける。
クライアント・コードを破綻させるAPIの変更を避け、大きな変更が生じる場合には、APIの変更について開発者に伝えてください。
開発者がAPI用のクライアントを実装する際には、スキーマや応答形式など、組み込まれている独自の特性に依存する可能性があります。互換性のないAPIの変更を避けることで、クライアント・コードの破綻は最小限に抑えられます。変更が発生した時にそれを伝えることで、開発者は新しい機能を利用でき、互換性のない変更が稀なケースであれば、対策を講じることができます。
開発者のコードが機能し続けます。開発者は、改善について知り、それを利用することができます。互換性のないAPIの変更は稀であり、それが発生した場合、開発者は自身のコードを適応させるのに十分な時間と情報を獲得できるでしょう。それにより、破綻が回避され、信頼を高めることがでるでしょう。APIの変更は、APIのドキュメト・サイトで発表されるでしょう。
APIを改善する時には、既存の呼び出しの仕組みを変更するのではなく、新しい呼び出しや新しいオプションを追加することに重点を置いてください。既存のクライアントはそのような変更を無視して機能し続けることができます。
完全にRESTfulなスタイルを用いる場合は、資源URIを一定に保ち、ユーザが直接コード化しない要素のみを変更することで、開発者に影響を与える変更を避けることができるべきです。最初に設計した拡張ポイントと互換性のない方法でデータを変更する必要がある場合は、まったく新しい設計が求められ、これはクライアント・コードの互換性のない変更を意味します。その場合は、異なる資源URIを用いて、新しいREST APIとして変更を実装するのが一番です。
クライアント・コードを破綻させないと適度に重要な変更を加えることができないアーキテクチャ・スタイルを用いている場合は、バージョン付けを用いてください。応答ヘッダでバージョンを示してください。バージョン番号は、URIまたはリクエストの「受け入れ」(accept)ヘッダに(内容交渉を用いて)反映されるべきです。URI内でバージョン付けを行う場合は、できる限りバージョン番号を左側に含めてください。コードをまだ新しいバージョンに適合させていない開発者のために、以前のバージョンを利用できるようにし続けてください。
ユーザに変更を直接通知するためには、メーリング・リストを作成し、開発者に参加を働き掛けるのが良いでしょう。それにより、そこで変更を発表でき、フィードバックに適したメカニズムとなります。また、ユーザは互いに助け合うこともできます。
製品バージョンに変更を適用する前に、最初にAPIの検証バージョンにリリースを行ってください。検証バージョンでアプリケーションを検証してフィードバックを提供するように開発者に依頼してください。
ワーキンググループは、ウェブ上のすべてのデータが必要に応じて無期限にいつでも利用可能であると想定することは非現実的であると認識しています。データの公開者は、様々な理由で、生のウェブからデータを削除したくなったり、削除しなければならなくなったりする可能性があり、その時点で、それは現在の作業範囲から外れ、データ保存担当者の領域へと移行します。しかし、ここで取り上げているのは、何が残っているかということ、つまり、公開者が、データが削除されたことまたはアーカイブされたことを示すためにどのようなステップを取るべきなのかということです。単純にウェブから資源を削除してしまうのは悪い習慣です。そのような状況では、URIを逆参照すると、資源が存在不明(not found)であることのみをユーザに知らせる404のHTTP応答コードが示されます。下記のベスト・プラクティスは、より生産的なアプローチを提供します。
ベスト・プラクティス27: 識別子を保持する。
ウェブからデータを削除する際には、識別子を保持し、アーカイブされた資源に関する情報を提供してください。
URIの逆参照は、ウェブ上のデータの主要なインターフェースです。URIの逆参照により、悪名高い404応答コード(存在不明)になった場合、ユーザは、可用性の欠如が永久的なのか、一時的なのか、計画的なのか偶発的なのかを知ることができません。公開者または第三者がデータをアーカイブしていても、元のURIが事実上壊れていれば、そのアーカイブされたコピーが見つかる可能性はかなり低いです。
資源のURIは、常に資源を逆参照するか、それに関する情報にリダイレクトするでしょう。
検討すべきシナリオが2つあります。
このうちの最初のケースでは、410(消滅)のHTTP応答コードで応答するようにサーバーを設定すべきです。仕様は次のようになっています。
410の応答は、その資源は意図的に利用できないこと、また、サーバーの所有者はその資源への遠隔リンクを削除することを望んでいることを受信者に通知することで、ウェブの管理作業を支援することを主に目指しています。
データがアーカイブされている2番目のケースでは、リクエストをウェブ・ページにリダイレクトして、データを保持しているアーカイブや、潜在的なユーザがそれにアクセスできる方法に関する情報を提供する方がより適切です。
どちらの場合も、たとえデータを直接利用できなくなっても、元のURIは資源を識別し続け、有用な情報に導きます。
利用できなくなったデータセットのURIを逆参照すると、必要に応じて410または303の応答コードを用いて、現在のステータスと可用性に関する情報が返されることを確認してください。
ベスト・プラクティス28: データセットの対象範囲を評価する。
保存する前にデータセットの対象範囲を評価してください。
あるまとまりのウェブ・データは、定義上、グローバルなグラフの残りの部分に依存しています。このグローバルな状況は、データセットに含まれている資源の記述の意味に影響します。理想的には、特定のデータセットの保存には、そのすべて背景の保存が必要でしょう。それは、データのウェブ全体です。
アーカイブする時点で、すでに保存されている資源へのデータセット・ダンプのリンクや、使用されている語彙の評価を行う必要があります。使用されている語彙やリンク先の資源のほとんどが、まだどこにも保存されていないデータセットは、危険にさらされているとフラグ付けされるべきです。
ユーザは、アーカイブされたデータを将来も十分に活用できるようになるでしょう。
用いられているすべての資源がすでにどこかで保存されているか、または保存を検討しているデータセットと一緒に提供する必要があるかを確認してください。
例えば、50年後に何が利用できるかを判断することは不可能です。しかし、アーカイブされているデータセットが、広く用いられている外部資源と語彙にのみ依存しているかを確認できます。唯一または使用頻度の低い依存関係がアーカイブの一部として保存されていることを確認してください。
関連要件: R-VocabReference
ウェブ上で公開することにより、様々なレベルの専門知識を持つ幅広い対象者に大規模なデータ共有が可能となります。データの公開者は、公開されたデータがデータの利用者ニーズを満たしていることを確実にしたいと考え、この目的のために、ユーザからのフィードバックは重要です。フィードバックは、公開者と利用者の両方にとって有益であり、データの公開者が公開されたデータの完全性を高めるのに役立ち、新しいデータの公開を促進させます。フィードバックにより、 データの利用者は利用経験(例えば、データを利用しているアプリケーション)、好み、ニーズに関する発言権を持つことができます。可能な場合には、フィードバックは、他のデータ利用者も検討できるように公開すべきです。フィードバックを公に利用できるようにすることで、ユーザは他のデータの利用者に気づくことができ、共同作業環境がサポートされ、現在対処されている懸念や問題のユーザ・コミュニティ体験が可能となります。
ユーザ・インターフェースの観点から見ると、データの利用者からフィードバックを収集する方法には、サイト登録、連絡フォーム、品質格付けの選択、調査、ブログのコメント・ボックスを含む様々なものがあります。機械の観点から見ると、データの公開者は、テータ利用に関する測定基準やデータを用いる特定のアプリケーションに関する情報を記録することもできます。このようなフィードバックにより、データの公開者とデータの利用者との通信経路が確立されます。公開されるフィードバックは、人間が読める形式で表示されるべきです。
この項では、利用者がフィードバックを提供できるようにするためにデータの公開者が従うべきベスト・プラクティスをいくつか示します。このフィードバックは、人間または機械に対するものでありえます。
ベスト・プラクティス29: データの利用者からフィードバックを収集する。
利用者がフィードバックを提供するための容易に発見できる手段を提供してください。
フィードバックの取得は、公開者がデータの利用者のニーズを理解するのに役立ち、それを公開するデータ品質の向上に役立てることができます。公開者がニーズへの対応に気を配っていることを利用者に示すことで、信頼も高まります。明確なフィードバック・メカニズムを規定すると、フィードバックを提供する方法を探さなければならないという障壁が取り払われます。
データの利用者は、データセットと配信に関するフィードバックと格付けを提供できるようになるでしょう。
データの利用者に、連絡フォーム、ポイント&クリック方式のデータ品質格付けボタン、コメント・ボックスを含む(が、これに限定されない)1つ以上のフィードバック・メカニズムを提供してください。利用者から受け取ったフィードバックを最大限に活用するためには、データベース内の各アイテムを取得する追跡システムでフィードバックを収集し、定量化と分析ができるようにするのが良いでしょう。各アイテムをデータセット利用語彙[VOCAB-DUV]で表現できるように、フィードバックの各アイテムの種類、つまり、その動機(編集、分類[格付け]、コメント、質問)を取得するのも良いでしょう。
少なくとも1つのフィードバック・メカニズムが提供されており、データの利用者が容易に発見できることを確認してください。
ベスト・プラクティス30: フィードバックを利用できるようにする。
データセットと配信に関する利用者のフィードバックを公的に利用できるようにしてください。
公開者は、利用者とフィードバックを共有することで、懸念に対処していることをユーザに示すことができ、重複したバグ・レポートの提出を回避できます。フィードバックの共有は、利用者が、データの可用性に影響があるかもしれない問題を理解するのにも役立ち、コミュニティ内の共同体意識を育むことができます。
利用者は、データセットに影響を与えるエラーの種類を評価し、それに関する他のユーザの経験をレビューし、必要に応じて公開者が積極的に問題に対処していることを再確認できます。利用者は、すでに他のユーザが同様のフィードバックを提供しているかどうかを判断することもでき、不要なバグ・レポートを提出する手間が省かれ、管理者は重複を処理する必要がなくなります。
フィードバックは、HTMLのウェブ・ページの一部として利用できますが、データセット利用語彙[VOCAB-DUV]を用いて機械可読形式で提供することもできます。
特定のデータセットや配信に関してデータの利用者から得られたフィードバックが公開されていることを確認してください。
データの拡充とは、未処理のデータまたは以前に処理されたデータを強化、改良、または違った形で改善するために利用できる一連のプロセスです。この考えやその他の同様の概念は、ほとんどの現代のビジネスや企業にとってデータを貴重な資産にすることに貢献します。これは、これ自体が多岐にわたるトピックであり、詳細は現在のドキュメントの範囲を越えています。しかし、倫理上の懸念が生じる可能性があるため、これらの技術の一部には慎重な姿勢で臨むべきであることは特筆に値します。科学研究においては、結果や統計上の成果を歪めるような拡充を回避するように注意を払わなければなりません。個人に関するデータの場合、データセットを結合したときにプライバシー問題が生じる可能性があります。つまり、あるデータセットを別のデータセットで拡充することで、どちらにも個人を識別するために十分な情報が含まれていなくても、結合したデータセットはプライバシーを損なうものになる可能性があります。さらに、これらの技術は大規模に実行できるため、注意の必要性が浮き彫りになります。
この項では、データを拡充するためにデータの公開者が従うべきベスト・プラクティスをいくつか示します。
ベスト・プラクティス31: 新しいデータを作成してデータを拡充する。
データの価値の向上が見込まれる場合は、新しいデータを生成してデータを拡充してください。
拡充は、特に非構造化データの処理可能性を大幅に向上させることができます。状況によっては、欠落している値を埋めることができ、既存の未処理のデータから新しい属性や測度を追加できます。データセットは、元のデータと同じ方式で結果を追加収集したり、元のデータを他のデータセットと組み合わせたりすることでも拡充できます。適切かつ倫理的に行われた場合、より完全なデータセットを公開することで、信頼性を向上させることができます。一般用途の付加価値を引き出すことにより、ユーザの時間が節約され、より多くの種類の再利用が促進されます。データを拡充するために利用できる多くの知的な手法が存在しており、データセットをいっそう貴重な資産にします。
欠落している値があるデータセットは、その値を埋めることで強化できます。関連する測度や属性を追加する場合は、追加によって分析結果、意義、統計力に歪みが生じない場合にのみ、骨組みが与えられ、有用性が強化されます。
データ拡充の技術は複雑で、このドキュメントの範囲をはるかに越えるため、その可能性を明らかにすることしかできません。
機械学習は、データの拡充に容易に適用できます。その方法には、データ分類、明確化、エンティティー認識、センチメント分析、トピフィケーション(topification)などに焦点を当てたものが含まれます。新しいデータ値は、既存のカラム全体で数学的計算を実行すると同じくらい簡単に導き出すことができます。他の例には、空間データの特徴を識別するための目視検査と、人口統計情報のための外部データベースとの相互参照が含まれます。最後に、新しいデータの作成は、欠落している値を直接的な方法で算出する、または別の方法で決定する、要求駆動型でありえます。
推論に基づく技術で作成した値は、そのようにラベル付けをすべきで、拡充によって置き換えられた元の値を取り出すことが可能であるべきです。
ライセンスで認められている場合は常に、データを拡充させるために用いたコードをデータセットと一緒に利用できるようにすべきです。そのようなコードの共有は、科学的なデータにとって特に重要です。
拡充作業の優先度付けは、それに要する労力のみでなくデータの利用者にとっての価値に基づくべきです。利用者にとっての価値は、需要を測定すること(例えば、調査または直接的な需要の追跡)で評価できます。需要の測定方法をドキュメント化することで、価値の増加を実証できるようになります。
他の人のデータを拡充する場合は、その拡充を元の公開者に提供すると良いでしょう。
データセットに、容易に提供できる、欠落している値がないか、他に追加フィールドが必要でないかを確認してください。推論拡充技術によって追加されたデータがそういうものとして識別され、置き換えられたデータがまだ利用可能であることを確認してください。
ベスト・プラクティス32: 補完的な提示方法を提供する。
視覚化、表、ウェブ・アプリケーション、要約などの補完的ですぐに参考になる方法でデータを提示し、拡充してください。
オンラインで公開されているデータは、その主題を他人に知らせることを意図しています。しかし、ダウンロードやAPIアクセス用のデータセットを掲載するだけでは、その解釈のために利用者に負担がかかります。ウェブは、ユーザが独自のツールを作成する必要なく、学習し探索できるようデータを提示する比類のない機会を提供します。
容易に理解できるようにデータを提示することで、補完的なデータの提示により、人間の利用者がデータを即座に把握できるようになります。
即座に把握してもらうための非常に簡単な方法の1つは、HTMLページで分析的な要約を公開することです。グラフまたは表に総括的なデータを含めると、ユーザが要約にざっと目を通したり、データの意味をすぐに理解したりするのに役立ちます。
データを用いたインタラクティブな視覚化やウェブ・アプリケーションを作成する方法があれば、データの利用者がそれを理解してパターンを発見する力を高めることができるでしょう。これらのアプローチは、処理に対する適合性も示し、再利用を促進します。
データセットに、データをダウンロードしたり、APIを呼び出したりせずに理解できる追加の解説コンテンツが付いていることを確認してください。
関連要件: R-DataEnrichment
データの再利用は、データ公開の別の手段です。これは単に再公開するだけです。既存のデータと他のデータセットとを組み合わせたり、ウェブ・アプリケーションや視覚化を作成したり、データを翻訳などの新しい形に再パッケージ化するという形を取ることができます。データの再公開者には、その形のウェブ上の公開に特有な何らかの責任があります。この項では、データを再公開する時に従うべきアドバイスを示します。
ベスト・プラクティス33: 元の公開者にフィードバックを提供する。
データを再利用する時に、元の公開者にそのことを知らせてください。エラーを見つけた時や、提案または称賛の気持ちがある場合は、彼らにそれを知らせてください。
一般的に、公開者は自身が公開したデータが有用なのかどうかを知りたがります。さらに、彼らは、データ公開業務に資源を割り当てるために利用統計の報告を求められるかもしれません。利用状況の報告は、データのリリースに向けた労力を正当化するのに役立ちます。フィードバックの提供は、公開者が将来のユーザのためにデータセットを改善するのに直接役立つため、公開者の労力に報いることになります。
コミュニケーションが改善すると、元の公開者は、掲載したデータがどのように利用されているかを判断しやすくなり、データの公開を正当化するのに役に立ちます。公開者は、データ改善のために取ることができる手順を認識することもできるでしょう。これによって、誰とってもより多くの優れたよりデータがもたらされます。
新しい製品のデータセットを利用し始める時には、公開者の連絡先情報、利用したデータセットのURI、連絡した日付をメモしてください。これは、データセットが用いられているコード内のコメントで行うことができます。公開者が望むルートに従ってフィードバックを提供してください。ルートが提供されていなければ、データを提供しているウェブ・サイトの連絡先情報を探してください。
あなたがデータを利用したことを公開者に知らせる通信記録を少なくとも1つは所有していることを確認してください。
ベスト・プラクティス34: ライセンス条件に従う。
データセットの元の公開者のライセンス要件を見つけて従ってください。
ライセンス処理は、他人の著作物を利用するための法的枠組みを提供します。元の公開者の要件を遵守することで、公開者との友好的な関係を維持することができます。意向に従っていれば、元の公開者からの訴訟ついて心配する必要はありません。元のライセンスについて理解していると、再利用のためにどのようなライセンスを選択すべきかを判断するのに役立つでしょう。
データの公開者は、自身のライセンス要件に従って著作物が再利用されていると信じることができ、そのため、データ公開を継続しやすくなるでしょう。データの再利用者自身も、二次的著作物のライセンス処理を適切に行うことができるでしょう。
元のライセンスを読んでその要件に従ってください。そのライセンスで二次的著作物に関して特定のライセンス処理が求められている場合は、その要件に合うライセンスを選択してください。ライセンスが提示されていない場合は、元の公開者に連絡し、どのようなライセンスなのかを尋ねてください。
元のライセンスを通読し、データの利用がどの条件にも違反していないことを確認してください。
ベスト・プラクティス35: 元の公開物を引用する。
メタデータでデータの情報源に対する謝辞を示してください。ユーザ・インターフェースを提供する場合は、インターフェースで目に見える形で引用を含めてください。
データは、信頼できる場合にのみ有益です。情報源の識別は、2つの方法で信頼性の主な指標です。まず、ユーザは情報源の評判からデータの信頼性を判断でき、次に、情報源の引用は、その人自身が再公開者として信頼できることを示唆します。引用は、エンドユーザへの情報提供に加え、公開者が自身の著作物の信頼性を高めるのに役立ちます。ウェブ上でデータを利用できるようにする公開者は、謝辞に値し、彼らが信頼されていることに気付けば、データを共有し続ける可能性が高くなります。また、引用は来歴を保全し、他の人がデータを処理するのにも役に立ちます。
エンドユーザは、閲覧したデータの信頼性を評価し、元の公開者の努力が認められるでしょう。ウェブ上のデータの来歴の連鎖は、その元の公開者にまで遡ることができるでしょう。
書誌的な情報と生きているリンクを提供して、元の情報源への引用をユーザ・インターフェースで示すことができます。
再利用されたデータの元の情報源が、提供されているメタデータで引用されていることを確認してください。人間が読める引用がどのユーザ・インターフェースでも容易に表示されることを確認してください。
関連要件: R-Citable、R-ProvAvailable、R-MetadataAvailable、R-TrackDataUsage
この項は非規範的です。
引用は直接的かつ明示的(雑誌記事の参考文献リストのように)、間接的(例えば、同じトピックに関する同じ研究グループによる最近の論文への引用)、または暗黙的(例えば、芸術的な引用やパロディ、または盗作の場合のように)でありえます。
データ・アーカイビングは、長年にわたるデジタル資料の状態の保存と監視に関する活動です。
このタスクは、Long-Term Archive Service(LTA)と称されることもあるTrusted Digital Repository(TDR)の責務です。しばしば、このようなサービスは、データの受入、監視、再利用の観点で保存プロセスを定義しているOAIS(Open Archival Information System)[OAIS]に従っています。
このWGの目的上、データの利用者は、データにアクセスし、利用し、後処理ステップを実行する可能性のある人またはグループです。
出典: Strong, Diane M., Yang W. Lee, and Richard Y. Wang. "Data quality in context." Communications of the ACM 40.5 (1997): 103-110.
「データ表現のための特定の規定、すなわち、コンピュータ・システムで用いるために情報がコード化され、保存される方法。形式的なデータ型や標準によって制約されている可能性がある」と定義されているデータ形式。
データの保存は、Alliance for Permanent Access Networkにより、「長期にわたってオブジェクトの技術的および知的な存続を保証するプロセスと操作」と定義されています。これは、保存計画とメタデータに焦点を当てたデータ管理計画の一部です。保存の取り組みに価値があるかどうかは、データの(将来)の価値、利用可能な資源、ステークホルダーの指定コミュニティの意見に依存します。
データの作成者は、データの作成と維持に責任がある人またはグループです。
出典: Strong, Diane M., Yang W. Lee, and Richard Y. Wang. "Data quality in context." Communications of the ACM 40.5 (1997): 103-110.
来歴(Provenance)は、「provenir」(～から来る)というフランスの用語に由来しており、芸術が所有者から所有者へと渡される時の芸術作品のキュレーション・プロセスを説明するために用いられます。同様に、データの来歴は、データ提供者がデータの履歴に関する詳細をデータのユーザに渡すことを可能にするメタデータです。
データの品質は、一般的に、特定のアプリケーションまたはユースケースに対する「利用適合性」と定義されています。
データセットは、1つのエージェントによって公開またはキュレートされ、1つ以上の形式でアクセスまたはダウンロードできるデータの集合と定義されています。データセットは、ダウンロード可能なファイルとして利用可能である必要はありません。
配信は、データセットの特定の利用可能な形式を表します。各データセットは、異なる形式で利用できることがあり、これらの形式は、データセットの異なる形式や、異なるエンドポイントを表す可能性があります。配信の例には、ダウンロード可能なCSVファイル、API、RSSフィードが含まれます。
フィードバック・フォームは、利用者が特定のトピックに関して投稿したメッセージを収集するために用いられます。メッセージには、他の利用者への返答を含めることができます。日時スタンプは各メッセージと関連付けられ、メッセージは、ある人物と関連付けることも、匿名で投稿することもできます。
出典: Semantically-Interlinked Online Communities (SIOC) and the Annotation Model [Annotation-Model]
アノテーションが作成された理由をより理解するために、SKOS概念体系[SKOS-PRIMER]を用いて、シンプルなクラス／サブクラス・ツリーよりも有意義な区別を用いて、コミュニティ間の相互に関連付けられたアノテーションを表示します。
ファイル形式は、コンピュータ・ファイルに格納するために情報をコード化する標準的な方法です。これは、デジタル記憶媒体内の情報をコード化するために、どのようにビットが用いられるかを規定します。ファイル形式は、プロプライエタリまたはフリーのいずれかでありえ、非公開または公開のいずれかでありえます。
ファイル形式の例には、プレーン・テキスト(特定の文字エンコーディングで、理想的にはUTF-8)、CSV[RFC4180]、PDF[PDF]、XML、JSON[RFC4627]、Turtle[Turtle]とHDF5が含まれます。
ライセンスは、関連付けられているデータを用いて何かを行うために公式な許可を与える法的なドキュメントです。
国際的なプレファレンスの集合で、一般的に、(あるカテゴリーの)ユーザが必要とする言語および地理的な領域と関連しています。これらは、通常、文化的な影響を受けた行動を得るために、環境から様々なプロセスに渡される、言語タグなどの省略形の識別子やトークンで識別されます。
出典: Language Tags and Locale Identifiers for the World Wide Web [LTLI].
機械可読なデータは、コンピューティング・システムが自動的に読んで処理できる標準形式のデータです。伝統的なワードプロ・ドキュメントやPDF(portable document format)ファイルは、人間は容易に読むことができますが、一般的に、機械が解釈して操作するのは困難です。XML、JSON、HDF5、RDF、CSVなどの形式は、機械可読なデータ形式です。
Wikipediaより。
電気通信およびコンピューティングにおける「ほぼリアルタイム」(near real-time)または「ほとんどリアルタイム」(nearly real-time)(NRT)という用語は、出来事の発生と、表示またはフィードバックおよび制御を目的として処理が行われたデータの利用との間に、自動データ処理またはネットワーク伝送によって導入される時間遅延を指します。例えば、ほぼリアルタイムの表示は、出来事または状況が、生の出来事が実際に発生している時間とほぼ同じ、現在から処理時間を差し引いた時間に存在していたかのように表します。
出典: Wikipedia
敏感なデータ(訳注：文脈により、機密性のある、依存した、制約のあるなどと訳している)は、限定的な方法で用いられる、および／または、限定された対象者を対象としている指定されたデータまたはメタデータです。敏感なデータには、個人のデータ、企業または政府のデータが含まれているかもしれず、公開された敏感なデータを誤って扱うと、個人や組織に損害を与える可能性があります。
技術標準は、技術システムに関する確立された規範または要件です。これは、通常、統一的な工学的または技術的な基準、方法、プロセス、実務を確立する正式なドキュメントです。対照的に、一般に受け入れられて優勢になる、慣習、規定、企業製品、企業標準などは、デファクト・スタンダードと呼ばれることが多いです。
出典: Wikipedia
構造化データとは、固定スキーマに準拠したデータを指します。リレーショナル・データベースとスプレッドシートは、構造化データの例です。
語彙は、特定の目的のための「用語」の集合です。語彙は、広く用いられているRDFスキーマ[RDF-SCHEMA]、FOAF[FOAF]、ダブリン・コア[DCTERMS]などのシンプルなものから、症状、病気、治療について記述するために医療で用いられるような数千の用語が含まれている複雑な語彙にまで及ぶ可能性があります。語彙は、特にデータ統合を支援するために、リンクト・データにおいて非常に重要な役割を果たします。この用語の使用は、オントロジーと重複しています。
この項は非規範的です。
次の図は、ウェブ上でデータを公開または利用する際に直面する主な課題の一部を要約したものです。これらの課題は、DWBPユースケースおよび要件[DWBP-UCR]から特定され、図で示しているように、1つ以上のベスト・プラクティスで取り組まれています。
この項は非規範的です。
下記の一覧では、DWBPを適用する主なメリットを記述しています。個々のメリットは、ウェブ上でデータセットを利用できる方法の改善点を表しています。
下表は、ベスト・プラクティスとメリットを関連付けたものです。
下の図は、ベスト・プラクティスの適用によってデータの公開者が得ると思われるメリットを示しています。
再利用
全ベスト・プラクティス
アクセス
発見可能性
処理可能性
信頼
相互運用性
リンク可能性
この項は非規範的です。
編集者は、ワーキンググループの全メンバーによるこのドキュメントに対する貢献に謝意を表します。特にAnnette Greinerの偉大な努力と、Antoine Isaac、Eric Stephan、Phil Archerからいただいた貢献に対して謝意を表します。
このドキュメントは、Spatial Data on the Web Working Groupの多くのメンバーからのアドバイスの恩恵を受けました。Andrea Perego、Dan Brickley、Linda van den Brink、Jeremy Tandyに特に感謝をせねばなりません。
編集者は、Addison Phillips、Adriano Machado、Adriano Veloso、Andreas Kuckartz、Augusto Herrmann、Bart van Leeuwen、Christophe Gueret、Erik Wilde、Giancarlo Guizzardi、Gisele Pappa、Gregg Kellogg、Herbert Van de Sompel、Ivan Herman、Leigh Dodds、Lewis John McGibbney、Makx Dekkers、Manuel Tomas Carrasco-Benitez、Maurino Andrea、Michel Dumontier、Nandana Mihindukulasooriya、Nathalia Sautchuk Patricio、Peter Winstanley、Renato Iannella、Steven Adler、Vagner Diniz、Wagner Meiraから受け取ったコメントにも感謝したいと思います。
編集者は、このワーキンググループの議長であるDeirdre Lee、Hadley Beeman、Yaso CordovaおよびスタッフのPhil Archerにも謝意を表します。
前バージョン以後の変更: