提供：TogoWiki

2015年5月14日 (木) 04:39時点における最新版

Comment: タイトルはより一般的なRDFizingとするのが良いのではないでしょうか。→ このページの最新版を [RDFizingDatabaseGuideline] にしました。

今後のスケジュール：

• 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とはResource Description Frameworkの略称で、その名の通り、ウェブにおいて情報を表現するための一つの枠組みであり、具体的なファイル形式ではありません。 そしてRDFを用いた情報を具体的に表記する方法はRDF/XMLやJSON-LDなど、複数ありますが、人に対する可読性においてTurtle形式が優れているとともに、SPARQLクエリの表記方法との共通点が多いことから、本ガイドラインではこの形式に従った表記をします。

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

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

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

モノやコトを表すURIはそれを識別するIDをスラッシュに続いて最後に記述する

適切なURIの構成方法として、ドメイン部分については後に示す通り、永続的であることが推奨されますが、パスの部分については、記述対象のリソースを識別するIDが最後に来るようにし、その直前にスラッシュ(/)を用いることが推奨されます。 例えばUniProtではQ6GZX3で識別されるたんぱく質について http://purl.uniprot.org/uniprot/Q6GZX3 というURIを割り当てています。 このようにURIを構成することで、Linked Dataの原則3で示される、「URIにアクセスした時にRDFやSPARQL標準に沿って有用な情報を提供する」への対応が実現し易くなります。

なお、オントロジーの場合は、そのオントロジーを構成する概念を示すIDの直前がスラッシュの代わりにハッシュ(#)としておくのが良いでしょう。

URI、リテラル、空白ノードの使い分けを適切に行う

RDFは全てがURI、リテラル、空白ノードで構成されますが、これからRDF化を行うデータをどのようにこれらに当てはめると、より有用なRDFデータになるか検討します。

まず確認ですが、RDFはその最小単位が主語、述語、目的語の三つ組み（RDFトリプル）であり、主語にはURIもしくは空白ノード、述語にはURI、目的語にはURI、空白ノード、もしくはリテラルが使えます。 そして主語、述語、目的語、という名が示す通り、主語と目的語が述語で示される関係性で結ばれることを表します。 ここで、URIはそれが示すモノやコトをウェブの世界でグローバルに識別することが適切である際に用いる一方、空白ノードは単に特定のRDFトリプル同士を結びつけるためなど、グローバルに識別することが必要ではない場合に用います。 先ほどのUniProtの例ではQ6GZX3で識別されるたんぱく質はグローバルに識別されることが必要ですから、URIが割り当てられています。

また、リテラルはURIとは異なり、識別子ではなく、ある特定の値そのものを表しますから、観測値などの数値データや観測時間などの時刻データは、その型（整数値や日時など）と共にリテラルで表現するのが推奨されます。 このように単位のついた値のリテラルを用いた記述方法については、後で詳細が記述されていますので参考にしてください。

クラスとインスタンスを別々に扱う

あるURIをクラスであると同時にインスタンスとすることはデータの意味的な処理が複雑になるので避けることが推奨されます。 因みに、rdfs:Class を rdf:type の目的語とするとき、その主語はクラスであることを表します。 そして、あるクラスを rdf:type の目的語とするとき、その主語はインスタンスであることを表します。

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

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

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

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

この件で、問題になるのは、「では、自らのリソースに、どのクラスをタイプ指定するばいいのか？」ということです。既存のオントロジーに適当なクラスが見つかればそれを利用すればいいですが、見つからない場合も多いと思われます。その場合は、自らのデータ用に、簡単なオントロジーを作成する必要があります。UniProt や EBI RDF も、必要なクラスをそれぞれ定義してデータとともに提供しています。

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で来歴情報をつける方法はいくつか提案されており(RDF Reification、NanoPub、PROV-O、OvoPub、VoAG 等)、BioHackathon 2014 でも議論されました Standardization of RDF data and development of tools/ontologies (8ページ目)。

ライセンス情報をつける

ライセンスが明示的に書かれていることで、ユーザが安心して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として記述する場合、主語、目的語のリソースや、述語のプロパティ等に、何を利用すればいいのかということは、しばしば自明ではなく、難しい問題です。少なくとも次にあげるような広く利用されているオントロジーや語彙に、適当なものがある場合はそれを利用することが推奨されます。

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

また、言語名に関する語彙として、米国国会図書館の提供しているISO 639-1やISO 639-2が利用できます。

既存のオントロジーや語彙のURIを利用する際には、しばしば名前空間を短縮系で表記します。例えば、上記のrdf:typeというURIは <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> の短縮表記です。 この短縮系はTurtleのprefixed nameという表記則に従って書かれており、一つのデータセット内においては短縮系と実際の表記の対応が矛盾無く宣言されていればどのような表記でも問題ないのですが、広く使われている短縮系があり、それを使うことで人に対する可読性が上がります。 これを探すためのサービスとしてprefix.ccがあるので、利用すると良いでしょう。

新規にオントロジーを定義する

データや知識をRDF化する際に、しばしば、オントロジーが必要になることがあります。典型的な例は、

• リソースが所属するクラスを明示する場合
• 何らかの情報をリテラルとして記述しているが、概念化できそうな場合
• 主語リソースと目的語リソースの関係を記述する述語が必要な場合

などです。 データ統合の観点からは、既存のオントロジーを利用する方が望ましいですが、既存のものの中に適当なものが見つからない場合は、新規に構築するしかありません。セマンティックウェブでは、一般的にOWLというオントロジー記述言語を利用してオントロジーを定義していきます。OWL自体もRDFで記述します。OWLは（RDFも）テキストエディタで記述できますが、専用のオントロジーエディタを利用した方が効率よく作業することができます。特に、階層構造などを試行錯誤しながらオントロジーを構築する場合には、GUIで作業が行えるオントロジーエディタが不可欠です。OWLオントロジーを記述できるエディタとして次のようなものがあります。

• Protege オープンソースのオントロジーエディタ
• WebProtege クラウド版のProtege
• TopBraid 商用のオントロジーエディタ

プロパティには、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のルール

• BioHackathon 2014 でも、Linked Data 公開のルールについて議論されました( 10 simple rules for publishing Linked Data for the Life Sciences )。いまでも追記可能です。

定期的なリリースとバージョン情報

• 現状、多くのデータベースは、RDF化する場合、すでに別の形式（リレーショナル・データベース等）で構築・提供しているデータベースから変換していると思います。こういった場合、公開サービスとして提供しているデータと、RDF化したデータとの間で、内容についての同期の問題が発生します。できるだけ、プライマリに提供しているデータと、RDF化したデータとの間との違いが大きくならないように、定期的なRDF化が望まれます。そのために、既存の形式からRDF化への変換はできるだけ自動化するようにし、その過程からは、マニュアル作業が必要な工程をできるだけ排除して下さい。RDF化の過程に大量のマニュアル作業が発生すると、定期的なRDF化は著しく困難になります。マニュアル作業（アノテーション、オントロジーマッピング等）はプライマリのデータベース構築作業の方に含めるようにして下さい。もちろん、プライマリなデータベースのフォーマットがRDFの場合はこの限りではありません。

また、RDF化の際に、適切なバージョン番号を付与して頂くことが必要となります。バージョン付けには、dcterms:hasVersion や、owl:versionInfo が利用できます。

dcterms:hasVerion
owl:versionInfo

参考URL

RDF化を支援するツール

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

• OpenRefine with RDF extension
• TogoDB
• D2RQ
• -ontop-
• Protege
• WebProtege
• TopBraid Composer Standard Edition
• TopBraid Composer Maestro Edition
• Silk

...

RDF化の際に参考になるサイト

• HCLS Dataset descriptions