Data構想RDFは、曖昧性が少なく、機械可読性の高いデータを記述する枠組みです。実際に記述したいデータをどのようにRDF化すれば、表現したい内容が記述できるのか、また、その後の利用の観点からより良いものになるのか、という指針は提供されていません。このことが、データベースをRDF化する際に、特に初心者にとって高いハードルとなっています。様々な議論がなされ、知見も蓄積されてきました。このコミュニティでデータをRDF化する際に指針となるようなガイドラインを作る時期にきたと思います。本ガイドラインが目指すのは、それを参照することで、RDF化作業の負担が減り、また他のデータと適切に統合して利用できるようなRDFを作成できるようにすることです。則ったデータ作成が推奨されます。他のURIへのリンクを含めるようにすることで、さらなる情報を辿れるようにするという4つの原則が提唱されています。Identifierの略称です。RDFは、ウェブにおいてURIで指し示されるリソースの情報を表現するための一つの枠組み(規格)であり、特定のファイル形式を指すものではありません。JSON-LDなど複数ありますが、Turtle形式は機械だけでなく人から見ても可読性が高く、SPARQLクエリの表記方法と共通点が多いことから、本ガイドラインではTurtle形式に従った表記をします。データベースコンテンツをRDF化する際のガイドライン以下、これまで蓄積してきた知見から、データベースをRDF化する際に推奨される指針を挙げます。いう文書が公開されています。URIリソースに関する情報を記述します。始まるURIを利用することを推奨し、原則3で、URIリソースに関する情報を、当該URIにアクセスすることでRDFなどの標準を用いて得られることを推奨しています。参照できたURIが、何らかの理由で違うURIに変わってしまう場合や消滅してしまった場合は、RDFデータの価値は著しく下がります。理由で、組織のURIが変更になることは珍しくありません。このため、組織のドメイン名を用いたURIでRDFデータを記述していると、運良くデータベースが新しい組織で運営されることになっても、RDFデータからはそのURIが参照できなくなります。このような事態を回避するため、下記の2つの方法を検討することが推奨されます。独自ドメインを取得するよくあるケースとして、uniprot.orgのように「データベース名.org」のような独自ドメインを取得する方法があります。これにより、データベースを運用する実体が変わっても、同じURIを持続して利用することができます。欠点は、独自ドメインを維持するのに費用がかかることや、誰がそのドメインを維持するのか、といった別の永続性問題が発生することです。(PURL)を利用してデータを記述する方法があります。RDFはPURLのURIを用いて記述し、PURLからデータを運用する実体のURLに転送(リダイレクト)することで、実体が移転した場合にもRDFデータの変更を伴わずに同じURIを持続して利用することができます。サービスを提供しています。PURLサービスで転送を管理することにより、常にそのとき参照できる最新のURIを指し示すことができます。リソースを示すURIはそれを識別するためのIDをURIの末尾に記述する永続性の高いドメイン部分に続く、URIのパス部分については、モノやコトを表す記述対象のリソースを識別するIDがURIの最後に来るようにし、その直前にスラッシュ(/)を用いることが推奨されます。いうURIを割り当てています。Dataの原則3で示される、「URIにアクセスした時にRDFやSPARQLなどの標準に沿って有用な情報を提供する」サービスの構築が技術的に実現し易くなります。オントロジーのURIでは、そのオントロジーを構成する概念を示すIDごとに個別のページを作る場合は、上記と同じようにIDの直前にスラッシュ(/)を、オントロジー全体が1つのページで提供される場合は、IDの直前をスラッシュの代わりにハッシュ(#)としておくのが良いでしょう。ようにハッシュ(#)が使用されています。RDFを作成する際のガイドラインURI、空白ノード、リテラルの使い分けを適切に行うRDFはURI、空白ノード、リテラルの組み合わせで構成されますが、これからRDF化を行うデータをどのようにこれらに当てはめると、より有用なRDFになるか検討します。主語にはURIもしくは空白ノード述語にはURI目的語にはURI、空白ノード、もしくはリテラルが使えます。各トリプルでは、主語と目的語が述語で示される関係性で結ばれることを表します。空白ノードは単に特定のRDFトリプル同士をグループ化して結びつけるためなど、グローバルに識別することが必要ではない場合に用います。いうURIが割り当てられています。文字列や観測値などの数値データは識別子(IDのこと)ではなく値そのものを表しますので、リテラルで表現します。この際、値に対して単位などデータの型を付けることで、より明確に値の意味(データのセマンティクス)を記述することができます。文字列リテラルでは、言語タグを使うことにより"protein"@enや"タンパク質"@jaなど英語や日本語といった言語を明示することができますし、数値リテラルの123が整数であることを示すには"123"^^xsd:integerのようにデータ型URIをつけることができます(ここでxsd:integerは<http://www.w3.org/2001/XMLSchema#integer>の短縮表記です)。数値の単位などを指定したリテラルの記述方法については、本ガイドラインの「単位のついた値の記述方法」セクションを参考にしてください。URIリソースにはrdf:typeでオントロジーのクラスをタイプ指定するURIで示されるリソースが何を意味しているのか、ということを明確かつ簡潔に表現するのに、オントロジーのクラスがrdf:typeで指定されていることは重要です。主たるリソースには、オントロジーに基づいてクラスを指定することが推奨されます。あることが分かります。指定することで効率的なデータ探索を行うことができます。オントロジーの定義がURIにアクセスすることで参照できると理想的ですが、そうなっていることは義務ではありません。自然言語では利用される文脈が異なると違った意味を持つことが普通に起こります。URIの参照先にデータ作成者が意図した定義を記述することは、データ利用者の誤解を避ける上で有効な手段になります。これは科学データを記述する場合には、大きなメリットといえます。ここで問題になるのは、「では、自らのリソースに、どのクラスをタイプ指定するばいいのか?」ということです。既存のオントロジーに適当なクラスが見つかればそれを利用すればいいですが、見つからない場合も多いと思われます。その場合は、自らのデータ用に、簡単なオントロジーを作成する必要があります。RDFも、必要なクラスをそれぞれ定義してデータとともに提供しています。ex:Myclass)それぞれ表します。あるURIをクラスであると同時にインスタンスとすることはデータの意味的な処理が複雑になるので避けることが推奨されます。インスタンスでもある、ことになるURIリソースにはrdfs:labelでラベルをつけるURIで示されるリソースが何なのか、ということを人間が容易に理解するためには、ラベルがrdfs:labelにより自然言語で記述されていることは重要です。主たるリソースには簡潔なラベルを記述することが推奨されます。このことは、機械可読性を高めることとは関係ありませんが、人間可読性を高めるので、アプリケーションをつくる際や、SPARQL検索の結果を読みやすく表示する際に便利になります。.また、この例の様に言語タグを付けることは、特に多言語化の際に有用です。英語ネイティブ以外であれば、母国語でもラベルを付けたい場合やコメントを追記したい場合があります。言語タグを付けることで、明示的に複数の言語で記述することができますし、アプリケーションで利用する際に英語ラベルだけを利用する、というようなことも簡単に行えます。.ある言語によるラベルは一つだけにしておいたほうが、利用する際に悩まないで済むので便利だと思います。異なるラベルを付けたい場合には、rdfs:labelの代わりにskos:altLabelが利用できます。rdfs:labelやskos:altLabelなどによって複数のラベルが存在する場合に、そのうちの一つを代表ラベルとして明示したい場合は、skos:prefLabelが利用できます。.URIリソースにはdcterms:identifierでIDを記述するURIはそれ自体がグローバルなIDとして機能しています。URIは記号的ですし文字列として長いので、SPARQL結果を表示する際に人間が見るのには向いていません。URIの末尾にデータベース固有の(ローカルな)IDが含まれているような場合は、URIの最後の/以下を切り出すことで文字列としてのIDを得ることができますが、このためにはSPARQLで文字列処理を適用するなど余計な手間が発生します。そこで、主なリソースのID文字列については、dcterms:identifierで記述することが推奨されます。Data)が実現されます。クロスリファレンス先がデータベースエントリの場合は、参照するDBエントリーが実際に閲覧できるURLへリンクを張ることが一般的です。URLと呼んでいます。URIではない(CGI引数をとって動的に生成されるページなどIDとしてふさわしくない)場合があること等があります。個々のデータベースが同じモノを指すのに異なるURIを利用したRDFを提供すると、統合的な検索が出来なくなるという問題もあります。URIを利用することが考えられます。Identifiers.orgはPURLに似ていますが、データベースのURIに特化したサービスで、転送先が複数ある場合には選択することも可能なほか、データベースのメタデータをRDFで提供してくれるなどの利点があります。Identifiers.orgはライフサイエンスのコミュニティによって維持されており、参照したいデータベースが登録されていない場合もリクエストすることで追加することができます。URLとIdentifiers.orgのURIの両方に参照リンクを貼ることで、外部のリソースと繋がりやすいRDFを作成することができます。データに来歴情報をつけるデータをセマンティック・ウェブ化する利点の一つは、メタデータを必要なだけ付与できることです。RDFのデータセットにメタデータを付与することで、作成された日、作成した人、データソース、データのカテゴリ、ライセンス等を明示することができます。各トリプルのこと)についても、その文の来歴(provenance)を付与することができます。科学のデータの場合、各文がファクトを表明することが多いため、その文を記述するにいたった来歴は重要です。この来歴には、論文や本などに記載された情報、機械的な手法(BLASTによる相同性検索等)で得られた情報から、個人の推測まで、様々な可能性があり得ます。来歴が明示的に記述されていることで、(論文で言及された情報だけ使う等)各トリプルをどのように利用するべきか、ユーザが選択することができるようになります。オントロジーを利用・構築する際のガイドライン広く利用されているオントロジーや語彙を利用する情報をRDFとして記述する場合、主語のクラスや述語のプロパティ等に、どのオントロジーを利用すればいいのかということは、しばしば自明ではなく、難しい問題です。少なくとも、次にあげるような広く利用されているオントロジーや語彙に適当なものがある場合はそれを利用することが推奨されます。(LOV)で広く一般に使われている語彙を見つけることができます。上記のように一般的な概念を扱ったオントロジーや語彙以外に、生命科学情報を記述する際に、利用しやすいオントロジーもあります。BioPortalでは、生命科学における適切なオントロジーや語彙を検索することができます。639-2が利用できます。SPARQLやTurtleで既存のオントロジーや語彙のURIを利用する際には、しばしば名前空間を短縮形で表記します。nameという表記方法に従って書かれており、一つのデータセット内において短縮名と実際の表記の対応が矛盾無く宣言されていればどのような短縮名を利用しても問題ないのですが、主要なオントロジーに対しては広く使われている短縮名があり、それを使うことで人に対する可読性が上がります。一般的な短縮名を探すためのサービスとしてprefix.ccを利用することができます。新規にオントロジーを構築するデータや知識をRDF化する際に、しばしば、オントロジーが必要になることがあります。主語リソースと目的語リソースの関係を記述する述語が必要な場合などです。データ統合の観点からは、既存のオントロジーを利用する方が望ましいですが、既存のものの中に適当なものが見つからない場合は、新規に構築するしかありません。セマンティックウェブでは、一般的にOWLというオントロジー記述言語を利用してオントロジーを定義していきます。OWL自体もRDFで記述します。OWLは(RDFも)テキストエディタで記述できますが、専用のオントロジーエディタを利用した方が効率よく作業することができます。階層構造などを試行錯誤しながらオントロジーを構築する場合には、GUIで作業が行えるオントロジーエディタが不可欠です。OWLオントロジーを記述できるエディタとして次のようなものがあります。predicate)には、rdfs:domainおよびrdfs:rangeを定義することができます。これによりプロパティの意味がより明示的になります。プロパティでの例です。classifiedWithという文字列から、人間は「何かで主語を分類するのだな」といったような一定の意味を汲み取ることができますが、機械にはそれができません。.という文も、uniprot:P51028とgo:2000044の間に関係がある、という以上の意味を持ちません。オントロジーにドメインとレンジが定義されることで、このプロパティcore:classifiedWIthはcore:Proteinタイプ以外のリソースを主語にとらないこと、core:Concept以外の値を持つことができないことを、機械が情報処理に利用することができるようになります。現状、多くのデータベースは、RDF化する場合、すでに別の形式(リレーショナル・データベース等)で構築・提供しているデータベースから変換していると思います。いった場合、公開サービスとして提供しているデータと、RDF化したデータとの間で、内容についての同期の問題が発生します。できるだけ、プライマリに提供しているデータと、RDF化したデータとの間との違いが大きくならないように、定期的なRDF化が望まれます。そのために、既存の形式からRDF化への変換はできるだけ自動化するようにし、その過程からは、マニュアル作業が必要な工程をできるだけ排除して下さい。RDF化の過程に大量のマニュアル作業が発生すると、定期的なRDF化は著しく困難になります。マニュアル作業(アノテーション、オントロジーマッピング等)はプライマリのデータベース構築作業の方に含めるようにして下さい。プライマリなデータベースのフォーマットがRDFの場合はこの限りではありません。RDF化の際に、適切なバージョン番号を付与することが必要となります。(オントロジーの場合)が利用できます。dcterms:hasVersionowl:versionInfoライセンス情報をつけるライセンスが明示的に書かれていることで、ユーザが安心してRDFデータを利用することができます。データの利用しやすさの観点からは、クリエイティブ・コモンズの適切なライセンスを利用すること等が推奨されます。オントロジーについてはそもそも著作物であるか否かで議論の余地があるところですが、著作物である場合を想定し、そして、一部を再利用することの容易性からCC0が良いと言われています。この議論は論文化にむけて取りまとめが進められていますが、現状ではまだ完成しておらず追記可能です。単位のついた値を記述する場合、次に示すように、ブランクノードを利用し値と単位を指定する方法があります。)および単位を表すクラス(exunits:kilograms)として、具体的に何を使えばよいのか書かれていません。