タイトルはより一般的なRDFizingとするのが良いのではないでしょうか。RDF化の際に参考になるサイトデータベースのRDF化ガイドラインRDFは、曖昧性が少なく、機械可読性の高いデータを記述する枠組みです。実際に記述したいデータをどのようにRDF化すれば、表現したい内容が記述できるのか、また、その後の利用の観点からより良いものになるのか、という指針は提供されていません。このことが、データベースをRDF化する際に、特に初心者にとって高いハードルとなっています。様々な議論がなされ、知見も蓄積されてきました。このコミュニティでデータをRDF化する際に指針となるようなガイドラインを作る時期にきたと思います。本ガイドラインが目指すのは、それを参照することで、RDF化作業の負担が減り、また他のデータと適切に統合して利用できるようなRDFを作成できるようにすることです。則ったデータ作成が推奨されます。他のURIへのリンクを含めるようにすることで、さらなる情報を辿れるようにするという4つの原則が提唱されています。Frameworkの略であり、その名の通り、ウェブにおいて情報を表現するための一つの枠組みであり、具体的なファイル形式ではありません。RDFを用いた情報を具体的に表記する方法はRDF/XMLやJSON-LDなど、複数ありますが、人に対する可読性においてTurtle形式が優れているとともに、SPARQLクエリの表記方法との共通点が多いことから、本ガイドラインではこの形式に従った表記をします。データベースコンテンツをRDF化する際のガイドライン以下、ガイドラインに盛り込むべき、これまで蓄積してきた知見をあげます。RDFを作成する際のガイドラインモノやコトを表すURIはそれを識別するIDをスラッシュに続いて最後に記述する適切なURIの構成方法として、ドメイン部分については後に示す通り、永続的であることが推奨されますが、パスの部分については、記述対象のリソースを識別するIDが最後に来るようにし、その直前にスラッシュ(/)を用いることが推奨されます。いうURIを割り当てています。Dataの原則3で示される、「URIにアクセスした時にRDFやSPARQL標準に沿って有用な情報を提供する」への対応が実現し易くなります。オントロジーの場合は、そのオントロジーを構成する概念を示すIDの直前がスラッシュの代わりにハッシュ(#)としておくのが良いでしょう。URI、リテラル、空白ノードの使い分けを適切に行うRDFは全てがURI、リテラル、空白ノードで構成されますが、これからRDF化を行うデータをどのようにこれらに当てはめると、より有用なRDFデータになるか検討します。三つ組み(RDFトリプル)であり、主語にはURIもしくは空白ノード、述語にはURI、目的語にはURI、空白ノード、もしくはリテラルが使えます。いう名が示す通り、主語と目的語が述語で示される関係性で結ばれることを表します。ここで、URIはそれが示すモノやコトをウェブの世界でグローバルに識別することが適切である際に用いる一方、空白ノードは単に特定のRDFトリプル同士を結びつけるためなど、グローバルに識別することが必要ではない場合に用います。先ほどのUniProtの例ではQ6GZX3で識別されるたんぱく質はグローバルに識別されることが必要ですから、URIが割り当てられています。リテラルはURIとは異なり、識別子ではなく、ある特定の値そのものを表しますから、観測値などの数値データや観測時間などの時刻データは、その型(整数値や日時など)と共にリテラルで表現するのが推奨されます。このように単位のついた値のリテラルを用いた記述方法については、後で詳細が記述されていますので参考にしてください。クラスとインスタンスを別々に扱うあるURIをクラスであると同時にインスタンスとすることはデータの意味的な処理が複雑になるので避けることが推奨されます。目的語とするとき、その主語はクラスであることを表します。目的語とするとき、その主語はインスタンスであることを表します。URIリソースには、rdf:typeでオントロジーのクラスをタイプ指定するURIで示されるリソースが何を意味しているのか、ということを明確にかつ簡潔に表現するのに、オントロジーのクラスがrdf:typeで指定されていることは重要です。主たるリソースには、オントロジーに基づいてクラスを指定することが推奨されます。あることが分かります。指定することで効率的なデータ探索を行うことができます。オントロジーの定義がURIにアクセスすることで参照できると理想的ですが、そうなっていることは義務ではありません。自然言語では利用される文脈が異なると違った意味を持つことが普通に起こります。URIの参照先にデータ作成者が意図した定義を記述することは、データ利用者の誤解を避ける上で有効な手段になります。これは科学データを記述する場合には、大きなメリットといえます。fixed:この件で、問題になるのは、「では、自らのリソースに、どのクラスをタイプ指定するばいいのか?」ということです。ベストプラクティスは何か?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で記述することが推奨されます。URIという運動に含まれています。いう文書が公開されています。RDFデータは、URIリソースの関係で記述されます。URIが参照できる先が実在することは望ましいですが、必須なわけではありません。参照できたウェブページのURIが何らかの理由で違うURIに変わってしまう場合や消滅してしまった場合は、RDFデータの価値は著しく下がります。理由で、組織のURIが変更になることは珍しくありません。このため、組織のURIでRDFデータを記述していると、運良く、データベースが新しい組織で運営されることになっても、RDFデータからはそのURIが参照できなくなります。このような自体を回避するため、下記の2つの方法を検討することが推奨されます。独自ドメインを取得するよくあるケースは、uniprot.orgのように「データベース名.org」のような独自ドメインを取得することで、データベースを運用する実体が変わっても、URIとしては持続させることができます。欠点は、独自ドメインを維持するのに費用がかかることや、誰がそのドメインを維持するのか、といった別の永続性問題が発生することです。(PURL)を利用してデータ記述する方法です。PURLから、データを運用する実体のURLにリダイレクトすることで、RDFデータの変更を伴わずに、常にそのとき参照できる最新のURIを指すことができます。サービスを提供しています。Data)が実現されます。クロスリファレンス先がデータベースエントリの場合、参照するDBエントリーが実際に閲覧できるURLへリンクを張ることが一般的です。URLと呼んでいます。URIではない(CGI引数をとって動的に生成されるページなどIDとしてふさわしくない)こと等があります。個々のデータベースがRDFで任意のURLを利用してしまうため、統合的な検索が出来なくなるという問題もあります。URIを利用することが考えられます。Identifiers.orgでは、参照したいデータベースが登録されている場合であれば、適切に最新の参照先へリダイレクトしてくれますし、転送先が複数ある場合には選択することも可能です。参照したいデータベースが登録されていない場合もリクエストすることで追加されます。URLとIdentifiers.orgのURIの両方にクロスリファレンスすることで、外部のリソースと繋がりやすいRDFを作成することができます。データに来歴(provenance)情報をつけるデータをセマンティック・ウェブ化する利点の一つは、メタデータを必要なだけ付与できることです。RDFのデータセットにメタデータを付与することで、作成された日、作成した人、データソース、データのカテゴリ、ライセンス等を明示することができます。各トリプルのこと)についても、その文の来歴を付与することができます。科学のデータの場合、各文がファクトを表明することが多いため、その文を記述するにいたった来歴は重要です。この来歴には、論文や本などに記載された情報、機械的な手法(BLASTによる相同性検索等)で得られた情報から、個人の推測まで、様々な可能性があり得ます。来歴が明示的に記述されていることで、(論文で言及された情報だけ使う、等)各トリプルをどのように利用するべきか、ユーザが選択することができます。Reification、NanoPub、PROV-O、OvoPub)で来歴情報をつけるか。ライセンス情報をつけるライセンスが明示的に書かれていることで、ユーザが安心してRDFデータを利用することができます。データの利用しやすさの観点からは、クリエイティブ・コモンズの適切なライセンスを利用すること等が推奨されます。オントロジーについてはそもそも著作物であるか否かで議論の余地があるところですが、著作物である場合を想定し、そして、一部を再利用することの容易性からCC0が良いのではと言われています。リソースや、述語のプロパティ等に、何を利用すればいいのかということは、しばしば自明ではなく、難しい問題です。少なくとも次にあげるような広く利用されているオントロジーや語彙に、適当なものがある場合はそれを利用することが推奨されます。(LOV)で広く一般に使われている語彙を見つけることができます。検索することで、適切なオントロジーや語彙を発見することができることもあります。上記のように一般的な概念を扱ったオントロジーや語彙以外に、生命科学情報を記述する際に、利用しやすいオントロジーもあります。639-2が利用できます。既存のオントロジーや語彙のURIを利用する際には、しばしば名前空間を短縮系で表記します。nameという表記則に従って書かれており、一つのデータセット内においては短縮系と実際の表記の対応が矛盾無く宣言されていればどのような表記でも問題ないのですが、広く使われている短縮系があり、それを使うことで人に対する可読性が上がります。これを探すためのサービスとしてprefix.ccがあるので、利用すると良いでしょう。新規にオントロジーを定義するデータや知識をRDF化する際に、しばしば、オントロジーが必要になることがあります。主語リソースと目的語リソースの関係を記述する述語が必要な場合などです。データ統合の観点からは、既存のオントロジーを利用する方が望ましいですが、既存のものの中に適当なものが見つからない場合は、新規に構築するしかありません。セマンティックウェブでは、一般的にOWLというオントロジー記述言語を利用してオントロジーを定義していきます。OWL自体もRDFで記述します。OWLは(RDFも)テキストエディタで記述できますが、専用のオントロジーエディタを利用した方が効率よく作業することができます。階層構造などを試行錯誤しながらオントロジーを構築する場合には、GUIで作業が行えるオントロジーエディタが不可欠です。OWLオントロジーを記述できるエディタとして次のようなものがあります。定義することができます。これによりプロパティの意味がより明示的になります。プロパティでの例です。いう文字列から、人間は「何かで主語を分類するのだな」といったような、一定の意味を汲み取ることができますが、機械にはそれができません。間に関係がある、事以上の意味を持ちません。以外の値を持つことができないことを情報処理に利用することができるようになります。