RDF 化ガイドラインの提案
川島 秀一, 片山 俊明, 山本泰智
ライフサイエンス統合データベースセンター

ライフサイエンス統合データベースセンターでは、RDF化された様々な生命科学データベースを統合して利用するための基盤技術開発を行っている。RDF は、Internationalized Resource Identifier (IRI)の関係を用いて、情報を表現する方法である。RDF は計算機可読性が高く、また、物事を表すのに、世界的にユニークなID として扱うことができるIRI を利用していることから、データの曖昧性を減らすことができる。従って、RDFは、独立して開発された複数のデータを、機械的に統合して利用するという目的に適したデータ記述方法であると考えられている。しかし、単純にRDF 形式を採用しただけで、データ統合に適したデータを記述することができるわけではなく、データ開発者の間で、記述に関する一定の取り決めを行うことが、第三者的に再利用性の高いRDF データを作成する上で必須である。このような観点から、データベースRDF 化のガイドラインを作成してきた。本ガイドラインを参照してRDF を構築することで、同様にガイドラインに従ったRDF データの間での相互運用性が非常に高くなると考えている。

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

概要
特にRDF化に馴染みのない人にとって、RDFの仕様のみを参考にして、データをRDF化することは非常に困難である。

URIを設計する際のガイドライン
永続性の高いURIを利用する

URIリソースにはdcterms:identifierでIDを記述する
文献情報へのリンクはPubMed IDかDOIを利用する
データにメタ情報・来歴情報をつける

SPAQRLthon や 国際版および国内版BioHackathon で得られた知見を取RDFデータは、 URIリソースに関する情報を記述するため、もともとアクデータをセマンティック・ウェブ化する利点の一つは、メタデータを必り入れて、生命科学系データをRDF化する際に参照できるガイドライセスできたURIが、何らかの理由で違うURIに変わってしまう場合や消滅要なだけ付与できることである。メタデータにより、作成された日、作ンを構築した。

してしまった場合（しばしば起こりえる）は、RDFデータの価値は著し成した人、データソース、データのカテゴリ、ライセンス等を明示する

ガイドラインに準拠してRDF化を行うことでく下がる。このような事態を回避するため、次の２つ方法を検討するこことができる。とが推奨される。

また、RDFで記述された1つ1つの文(statement)について、その文の来歴■ 独自ドメインを取得する(provenance)を付与することができる。特に科学のデータの場合、各文■ PURL を利用する（purl.jp 等）がファクトを表明することが多いため、その文を記述するにいたった来開発者の負担が減る
統合して利用しやすいRDFが作成できるという効果が得られる

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

リソースを示すURIはそれを識別するためのIDをURIの末尾に記述する

歴は重要であり、それにより各トリプルをどのように利用するべきか、ユーザが選択することができるようになる。RDFで来歴情報を記述するための語彙には DC terms、PROV-O、PAVなどがある。また、来歴を記述するRDFモデルとしては、RDF Statement を使う方法や、nano publication

年一度の国際版BioHackahton、国内版BioHackathon および 毎月開催

RDFを作成する際のガイドラインによるものなどが推奨される。

されるSPARQLthon での経験や議論を中心に、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を名前に使用することでユーザがそれについて調べられるようにする
3. When someone looks up a URI, provide useful information, using thestandards (RDF*, SPARQL)→ URIにアクセスした時にRDFやSPARQLなどの標準に沿って有用な情報を提供する
4. Include links to other URIs. so that they can discover more things.
→ 他のURIへのリンクを含めて、さらなる情報を辿れるようにするという4つの原則が提唱されている。

URI、空白ノード、リテラルの使い分けを適切に行う
主語(Subject)にはURI もしくは空白ノード、述語(Predicate)にはURI、目的語(Object)にはURI、空白ノード、もしくはリテラル を使う、という基本原則を必ず守ること。

Subject

PredicateObject

URI

URI/空白ノード

URI/空白ノード/リテラル

特に、空白ノードについては、単に特定のRDFトリプル同士をグループ化して結びつけるためなど、グローバルに識別することが必要ではない場合にのみ使う方がよい。

オントロジーを利用・構築する際のガイドライン
広く利用されているオントロジーや語彙を利用する
情報をRDFとして記述する場合、主語のクラスや述語のプロパティ等

URIリソースにはrdf:typeでオントロジーのクラスをに、どのオントロジーを利用すればいいのかということは、しばしばタイプ指定する

自明ではなく、難しい問題である。少なくとも、次にあげるような広く利用されているオントロジーや語彙に適当なものがある場合は、そURIで示されるリソースが何を意味しているのか、ということを明確か

RDFを提供する際のガイドライン

つ簡潔に表現するのに、オントロジーのクラスがrdf:typeで指定されていることは重要である。このことは、SPARQL検索の際の、効率的なデータ探索にも寄与する。特に、主たるリソースには、オントロジー

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

れを利用することが推奨される。
一般的な語彙：RDF、RDFS、OWL、Dublin Core、DC Terms、SKOS、FOAF、VoID、UO、QUDT、PROV-O、PAV、XSD
生 命 科 学 情 報 に 関 す る ドメ イ ン オ ン ト ロ ジ ー ： G O 、 P R O 、 S O 、に基づいてクラスを指定することが推奨される。

FALDO、PO、Taxonomy、Nucleotide、MeSH、CO、FMA、UBERON、現状、多くのデータベースは、RDF化する場合、RDFでない形式のデー(ex.) uniprot:Q6GZX3 rdf:type core:Protein .

タベースからRDF化を行っている場合、両者の間で内容の違いが生じないように、できるだけデータベースバージョンの同期が行われるよ

PIERO、GlycoRDF

URIリソースにはrdfs:labelでラベルをつける
新規にオントロジーを構築する

うにすること。また、バージョン番号を付与するために、pav:version(RDFデータ)や、owl:versionInfo (オントロジー)が利用できる。

SNOMED-CT、SIO、EFO、ECO、EDAM、CMO、MMO、XCO、OrthO、URIで示されるリソースに対して、ラベルがrdfs:labelにより自然言語で記述されていることで、人間の理解を助ける。このことは、機械可読データや知識をRDF化する際に、しばしば、オントロジーが必要にな性を高めることとは関係ないが、人間可読性を高めるので、アプリケーることがある。データ統合の観点からは、既存のオントロジーを利用ションをつくる際や、SPARQL検索の結果を読みやすく表示する際に便する方が望ましいが、既存のものの中に適当なものが見つからない場

ライセンスが明示的に書かれていることで、ユーザが安心してRDF利である。特に多言語でラベルを付ける際は、言語タグを使用し、、合は、新規に構築すること。

データを利用することができる。データの利用しやすさの観点からは、

あ た 同 一 リ ソ ース に 同 一 言 語 で 複 数 の ラ ベ ル を 付 ける 場 合 は 、クリエイティブ・コモンズの適切なライセンスを利用すること等が推

skos:altLabel や skos:prefLabel の利用を考えること。

ライセンス情報をつける

プロパティにはrdfs:domainとrdfs:rangeを定義する奨される。

SPARQLエンドポイントを公開する際はCORS対策を行う
SPARQLエンドポイントに対する検索をウェブアプリケーションからJavaScriptで行うケースを想定して、SPARQLエンドポイントとなる公開

chebi:CHEBI_17234 rdfs:label "D-Glucose"@en ;rdfs:label "D-グルコース"@ja ;skos:altLabel "Dextrose"@en ;skos:prefLabel "D-Glucose"@en ..

クラスの定義を適切に行う
オントロジーのクラスを新たに定義した場合、利用者が、そのクラスが表す概念が何なのか理解できるように、適切な説明をつけることは重要である。 プロパティとしては、skos:definition や rdfs:comment 等

ウェブサーバではどこからでもアクセス可能となるように、CORS

他のデータベースへのクロスリファレンスはpolite(Cross Origin Resource Sharing)対策をすることが強く推奨される。

URLとidentifiers.orgのURIを利用するを用いて、簡潔でいいので明確に記述すること。

具体的にはApacheやNginxなどの設定で「Access-Control-Allow-Origin:*」ヘッダを付加する。

Licensed under a Creative Commons 表示2.1日本 license (c) 2015 Shuichi Kawashima（DBCLS）