BH14.14/RDFingDatabaseGuideline

提供:TogoWiki

2015年4月28日 (火) 03:24時点におけるYayamamo (トーク | 投稿記録)による版
移動: 案内, 検索

Comment: タイトルはより一般的なRDFizingとするのが良いのではないでしょうか。

今後のスケジュール:

  • 4月 ガイドラインドラフト、NBDC からポータルサイト発注の手続き確認
  • 5月 ガイドラインを SPARQLthon でレビュー、永野さんとの意識合わせ
  • 6月〜7月 ポータルサイトの構築
  • 7〜9月 ガイドラインにもとづいた TPP データのリバイスとポータルへの収録、可視化
  • 10月 統合の日

http://www.infocom.co.jp/das/loddiary/linked_data/ ここに書かれている内容は参考文献として貴重 (山本)

https://github.com/dbcls/bh14/wiki/Ten-simple-rules-for-publishing-Linked-Data-for-the-Life-Sciences とできるだけ揃える

目次

データベースのRDF化ガイドライン

RDFは、曖昧性が少なく、機械可読性の高いデータを記述する枠組みです。しかし、実際に記述したいデータをどのようにRDF化すれば、表現したい内容が記述できるのか、また、その後の利用の観点からより良いものになるのか、という指針は提供されていません。このことが、データベースをRDF化する際に、特に初心者にとって高いハードルとなっています。幸い、これまで BioHackathon や SPARQLthon などでも、様々な議論がなされ、知見も蓄積されてきました。そろそろこのコミュニティでデータをRDF化する際に指針となるようなガイドラインを作る時期にきたと思います。本ガイドラインが目指すのは、それを参照することで、RDF化作業の負担が減り、また他のデータと適切に統合して利用できるようなRDFを作成できるようにすることです。

基本精神として、Tim Berners-Leeによる、 Linked Data構想 に則ったデータ作成が推奨されます。Linked Data構想では、

  1. Use URIs as names for things → モノやコトにURIを使って名前をつける
  2. Use HTTP URIs so that people can look up those names. → 広く一般に普及しているソフトウェアでアクセスできる、http:// から始まるURIを名前に使用することでユーザがそれについて調べられるようにする(広く普及しているソフトウェアではアクセスできないURIもあるため)
  3. When someone looks up a URI, provide useful information, using the standards (RDF*, SPARQL) → URIにアクセスした時にRDFやSPARQL標準に沿って有用な情報を提供する
  4. Include links to other URIs. so that they can discover more things. → 他のURIへのリンクを含めるようにすることで、さらなる情報を辿れるようにする

という4つの原則が提唱されています。

データベースコンテンツをRDF化する際のガイドライン

以下、ガイドラインに盛り込むべき、これまで蓄積してきた知見をあげます。

RDFを作成する際のガイドライン

URIリソースには、rdf:typeでオントロジーのクラスをタイプ指定する

URIで示されるリソースが何を意味しているのか、ということを明確にかつ簡潔に表現するのに、オントロジーのクラスがrdf:typeで指定されていることは重要です。特に、主たるリソースには、オントロジーに基づいてクラスを指定することが推奨されます。

例) uniprot:Q6GZX3 rdf:type core:Protein .

上の例では、UniProt のQ6GZX3エントリーが、core:Protein であることが分かります。リソースの指し示すものが明確になる上に、SPARQL検索の際にも、rdf:type を指定することで効率的なデータ探索を行うことができます。オントロジーの定義がURIにアクセスすることで参照できると理想的ですが、そうなっていることは義務ではありません。ただし、自然言語では利用される文脈が異なると違った意味を持つことが普通に起こります。URIの参照先にデータ作成者が意図した定義を記述することは、データ利用者の誤解を避ける上で有効な手段になります。これは科学データを記述する場合には、大きなメリットといえます。

  • To be fixed:この件で、問題になるのは、「では、自らのリソースに、どのクラスをタイプ指定するばいいのか?」ということです。ベストプラクティスは何か?

URIリソースには、rdfs:labelでラベルをつける

URIで示されるリソースが何なのか、ということを人間が容易に理解するためには、ラベルがrdfs:labelにより自然言語で記述されていることは重要です。特に、主たるリソースには簡潔なラベルを記述することが推奨されます。このことは、機械可読性を高めることとは関係ありませんが、人間可読性を高めるので、アプリケーションをつくる際や、SPARQL検索の結果を読みやすく表示する際に便利になります。

例)uniprot:P51028 rdfs:label “wnt8a”@en .

また、この例の様に言語タグを付けることは、特に多言語化の際に有用です。英語ネイティブ以外であれば、母国語でもラベルを付けたい場合やコメントを追記したい場合があります。言語タグを付けることで、明示的に複数の言語で記述することができますし、アプリケーションで利用する際に英語ラベルだけを利用する、というようなことも簡単に行えます。

例)  mpo:MPO_03001 rdfs:label "Thermophilic"@en , "高熱性"@ja .

ある言語によるラベルは一つだけにしておいたほうが、利用する際に悩まないで済むので便利だと思います。異なるラベルを付けたい場合には、rdfs:labelの代わりにskos:altLabelが利用できます。また、rdfs:labelやskos:altLabelなどによって複数のラベルが存在する場合に、そのうちの一つを代表ラベルとして明示したい場合は、skos:prefLabelが利用できます。

例)
chebi:CHEBI_17234 rdfs:label "D-Glucose"@en ;
                  rdfs:label "D-グルコース"@ja ;
                  skos:altLabel "Dextrose"@en ;
                  skos:altLabel "ブドウ糖"@ja ;
                  pref:Label "D-Glucose"@en .

URIリソースには、dcterms:identifierでIDを記述する

URIはそれ自体がグローバルなIDとして機能しています。しかし、URIは記号的ですし文字列として長いので、SPARQL結果を表示する際に人間が見るのには向いていません。URIの末尾にデータベース固有の(ローカルな)IDが含まれているような場合は、URIの最後の/以下を切り出すことで文字列としてのIDを得ることができますが、切り出すためにはSPARQLで文字列処理を適用するなど余計な手間が発生します。このため、主なリソースのID文字列については、dcterms:identifierで記述することが推奨されます。

例)uniprot:P51028 dcterms:identifier “P51028” .

永続性の高いURIを利用する

永続性の高いURIを使う、という指針はcool URIという運動に含まれています。これは、Tim Berners-Lee による「クールなURIは変わらない (日本語訳)」という宣言から始まっており、W3Cからも「セマンティックウェブのためのクールなURI (原文), (日本語訳)」 という文書が公開されています。

RDFデータは、URIリソースの関係で記述されます。URIが参照できる先が実在することは望ましいですが、必須なわけではありません。しかし、もともと参照できたウェブページのURIが何らかの理由で違うURIに変わってしまう場合や消滅してしまった場合は、RDFデータの価値は著しく下がります。例えば、生命科学系データベースの多くが研究機関で作られていますが、組織の改組、統合、廃止等の理由で、組織のURIが変更になることは珍しくありません。このため、組織のURIでRDFデータを記述していると、運良く、データベースが新しい組織で運営されることになっても、RDFデータからはそのURIが参照できなくなります。このような自体を回避するため、下記の2つの方法を検討することが推奨されます。

  • 独自ドメインを取得する

よくあるケースは、uniprot.orgのように「データベース名.org」のような独自ドメインを取得することで、データベースを運用する実体が変わっても、URIとしては持続させることができます。欠点は、独自ドメインを維持するのに費用がかかることや、誰がそのドメインを維持するのか、といった別の永続性問題が発生することです。

  • PURLを利用する

Persistent URL (PURL)を利用してデータ記述する方法です。PURLから、データを運用する実体のURLにリダイレクトすることで、RDFデータの変更を伴わずに、常にそのとき参照できる最新のURIを指すことができます。NBDCでは、研究機関のデータベース運用のために purl.jp サービスを提供しています。

他のデータベースへのクロスリファレンスは、polite URLとidentifiers.orgのURIを利用する

RDFでは、外部のリソースに対する参照リンクを貼ることで、データのウェブ(Linked Data)が実現されます。クロスリファレンス先がデータベースエントリの場合、参照するDBエントリーが実際に閲覧できるURLへリンクを張ることが一般的です。これをオリジナルのサイトを尊重するという意味からpolite URLと呼んでいます。しかし、オリジナルのURLを利用することの問題点として、

  • リンクしたページのURLが変更されてしまっても、一度公開してしまったRDFへはその変更が自動的に適用されないこと
  • オリジナルのURLがcool URIではない(CGI引数をとって動的に生成されるページなどIDとしてふさわしくない)こと

等があります。また、同じ項目を参照するのに複数のURLが存在する場合があり(例えばTaxonomy ID などは、NCBI, EBI, UniProt, Bio2RDF等のサイトが異なるURLを提供していて、どれも広く利用されています)、

  • 個々のデータベースがRDFで任意のURLを利用してしまうため、統合的な検索が出来なくなる

という問題もあります。

こういった問題点を避ける方法として、http://identifiers.org/ のURIを利用することが考えられます。Identifiers.orgでは、参照したいデータベースが登録されている場合であれば、適切に最新の参照先へリダイレクトしてくれますし、転送先が複数ある場合には選択することも可能です。また、参照したいデータベースが登録されていない場合もリクエストすることで追加されます。このため、

例
ex:111 rdfs:seeAlso <http://pfam.xfam.org/family/PF01590> .
ex:111 rdfs:seeAlso <http://identifiers.org/pfam/PF01590> .

のようにpolite URLとIdentifiers.orgのURIの両方にクロスリファレンスすることで、外部のリソースと繋がりやすいRDFを作成することができます。

データに来歴(provenance)情報をつける

データをセマンティック・ウェブ化する利点の一つは、メタデータを必要なだけ付与できることです。RDFのデータセットにメタデータを付与することで、作成された日、作成した人、データソース、データのカテゴリ、ライセンス等を明示することができます。また、RDFで記述された1つ1つの文(statement; 各トリプルのこと)についても、その文の来歴を付与することができます。特に科学のデータの場合、各文がファクトを表明することが多いため、その文を記述するにいたった来歴は重要です。この来歴には、論文や本などに記載された情報、機械的な手法(BLASTによる相同性検索等)で得られた情報から、個人の推測まで、様々な可能性があり得ます。来歴が明示的に記述されていることで、(論文で言及された情報だけ使う、等)各トリプルをどのように利用するべきか、ユーザが選択することができます。

RDFで来歴情報をつける方法はいくつか提案されており、BioHackathon 2014 でも議論されました Standardization of RDF data and development of tools/ontologies (8ページ目)。

To be fixed: どの方法(RDF ReificationNanoPubPROV-OOvoPub)で来歴情報をつけるか。

ライセンス情報をつける

ライセンスが明示的に書かれていることで、ユーザが安心してRDFデータを利用することができます。データの利用しやすさの観点からは、クリエイティブ・コモンズの適切なライセンスを利用すること等が推奨されます。 また、オントロジーについてはそもそも著作物であるか否かで議論の余地があるところですが、著作物である場合を想定し、そして、一部を再利用することの容易性からCC0が良いのではと言われています。

 <a RDF data> dcterms:lisence <http://creativecommons.org/licenses/by-sa/4.0/> .
 <http://creativecommons.org/licenses/by-sa/4.0/> a <http://purl.org/dc/terms/LicenseDocument> .

To be fixed: 独自ライセンスの場合にどのように記載したら良いかを追記する

オントロジーを利用・構築する際のガイドライン

広く利用されているオントロジーを利用する

情報をRDFとして記述する場合、目的語のリソースや、述語のプロパティ等、何を利用すればいいのか、ということは難しい問題です。少なくとも次にあげるような広く利用されているオントロジーに、適当な語彙がある場合はそれを利用することが推奨されます。

一般的な語彙の一覧
語彙 名前空間 参考リンク
RDF 1.0 http://www.w3.org/1999/02/22-rdf-syntax-ns# 概念および抽象構文 [英語] [日本語], RDF入門 [英語] [日本語], RDF/XML構文仕様 [英語] [日本語]
RDF 1.1 http://www.w3.org/1999/02/22-rdf-syntax-ns# 概念および抽象構文 [英語], RDF入門 [英語], RDF/XML構文仕様 [英語], turtle構文仕様 [英語]
RDFS 1.0 http://www.w3.org/2000/01/rdf-schema# 仕様 [英語] [日本語]
RDFS 1.1 http://www.w3.org/2000/01/rdf-schema# 仕様 [英語]
OWL 1 http://www.w3.org/2002/07/owl 概要 [英語] [日本語]
OWL 2 http://www.w3.org/2002/07/owl 概要 [英語]
DC http://purl.org/dc/elements/1.1/ 仕様 [英語]
DC term http://purl.org/dc/terms/ 仕様 [英語]
SKOS http://www.w3.org/2004/02/skos/core 概要 [英語] [日本語], SKOS入門 [英語] [日本語]
FOAF http://xmlns.com/foaf/0.1/ 仕様 [英語]

そのほか、Linked Open Vocabularies (LOV)で広く一般に使われている語彙を見つけることができます。 また、BioPortal を検索することで、適切な語彙やオントロジーを発見することができることもあります。上記のように一般的な概念を扱ったオントロジー以外に、生命科学情報を記述する際に、利用しやすいオントロジーもあります。

一般的な語彙の一覧
略称 オントロジー名 名前空間 参考リンク
GO Gene Ontology http://purl.obolibrary.org/obo/ Home, BioPortal,
PO Plant Ontology http://purl.obolibrary.org/obo/ Home, BioPortal
Taxonomy Taxnomy BioPortal
CL Cell Ontology http://purl.obolibrary.org/obo/ BioPortal
FMA Foundational Model of Anatomy http://purl.org/sig/ont/fma/ Home, BioPortal
SNOMED Systematized Nomenclature of Medicine - Clinical Terms http://purl.bioontology.org/ontology/SNOMEDCT/ BioPortal
SIO Semanticscience Integrated Ontology http://semanticscience.org/resource/ Home, BioPortal
EFO Experimental Factor Ontology http://www.ebi.ac.uk/efo/ Home, BioPortal
CMO Clinical Measurement Ontology http://purl.obolibrary.org/obo/ Home, BioPortal
MMO Measurement Method Ontology http://purl.obolibrary.org/obo/ Home, BioPortal
XCO Experimental Conditions Ontology http://purl.obolibrary.org/obo/ Home, BioPortal
UO Units of Measurement Ontology http://purl.obolibrary.org/obo/ Home, BioPortal
OrthO Ortholog Ontology http://purl.jp/bio/11/orth# Home, [BioPortal
PIERO PIERO Enzyme Reaction Ontology Home

クラスを定義する

To be fixed: どのような際にクラスのオントロジー定義が必要で、どのように定義したら良いかを追記する

プロパティを定義する

To be fixed: どのような際にオントロジー定義が必要で、どのようにプロパティ定義したら良いかを追記する

プロパティには、rdfs:domain と rdfs:range を定義する

プロパティ(RDFの述語、predicate)には、rdfs:domain および rdfs:range を定義することができます。これによりプロパティの意味がより明示的になります。

例)
core:classifiedWith rdfs:domain core:Protein .
core:classifiedWIth rdfs:range core:Concept .

上記の例では、UniProt のタンパクエントリーに、GOなどの機能アノテーション情報をつける core:classifiedWith プロパティでの例です。ドメインとして、core:Protein、レンジとして、core:Concept が定義されています。classifiedWith という文字列から、人間は「何かで主語を分類するのだな」といったような、一定の意味を汲み取ることができますが、機械にはそれができません。

機械には、

uniprot:P51028 core:classifiedWith go:2000044 . 

という文も、

uniprot:P51028 :fugahoge go:2000044 .

という文も、uniprot:P51028 と go:2000044 の間に関係がある、事以上の意味を持ちません。

オントロジーにドメインとレンジが定義されることで、機械も、このプロパティcore:classifiedWIthは、core:Protein タイプ以外のリソースを主語にとらないこと、core:Concept 以外の値を持つことができないことを情報処理に利用することができるようになります。

生命科学で利用しやすいRDFモデル

測定項目および測定値の記述方法

単位のついた値の記述方法

  • ブランクノードを利用する方法

例)
ex:m1 sio:SIO_000216 [             # SIO__000216 is "has measurement value"
  ref:type       cmo:CMO_0000209 ; # Blood fibrinogen level defined by Clinical Measurement Ontology
  ref:value      21.5 ;                        
  sio:SIO_000222 uo:UO_0000309     # Milligram per square meter defined by Units of Measurement Onotlogy .
] .                                # SIO__000222 is "has unit"


  • 単位の型指定をつかう方法
例)
ex:e1 sio:SIO_000216 ex:m1 .
ex:m1 rdf:type cmo:CMO_0000209 ;
      sio:SIO_000216 21.5^^<http://purl.obolibrary.org/obo/UO_0000309> .

サンプルメタデータの記述方法

トランスクリプトームの記述方法

画像へのリンク

  • 主語URIが意味する実体を表す画像へのリンクを張る際には、foaf:depition を利用する。
an-assay-db:12345 foaf:depiction an-assay-db-image:12345.jpg .
  • 逆に、画像ファイルのURIが主語で、その画像に描かれているもののリソースURIが目的語の場合、foaf:depits を利用する。
an-assay-db-image:12345.jpg foaf:depicts an-assay-db:12345 .

RDF提供の際のガイドライン

生命科学のLinked Dataを公開するときの10のルール


バージョン

  • 現状、多くのデータベースは、RDF化する場合、すでに別の形式(リレーショナル・データベース等)で提供しているデータベースから変換していると思います。こういった場合、公開サービスとして提供しているデータと、RDF化したデータとの間で、内容についての同期の問題が発生します。できるだけ、プライマリに提供しているデータと、RDF化したデータとの間との違いが大きくならないように、定期的なRDF化が望まれます。また、その際に、適切なバージョン番号も付与し頂くことが必要となります。バージョン付けには、dcterms:hasVersion や、owl:versionInfo が利用できます。
dcterms:hasVerion
owl:versionInfo

RDF化を支援するツール

ガイドラインに従って実際にRDF化を進める際に有益なツール群を紹介します。

  • OpenRefine with RDF extension
  • 統合DB
  • D2RQ
  • -ontop-
  • protege
  • TopBraid Composer
  • silk

...

参考URL

個人用ツール