BH11.11/EasyLOD

提供：TogoWiki

2011年11月25日 (金) 06:24時点におけるAkinjo (トーク | 投稿記録)による版
(差分) ←前の版 | 最新版 (差分) | 次の版→ (差分)
移動： 案内, 検索

目次

趣旨

これまでの（わずかな）経験から作りやすくて使いやすい Linked Data の作り方について（勝手に）考えたことのメモ。

まとめ

結局、http://www.w3.org/DesignIssues/LinkedData.html で言われていることに尽きる。

  1. Use URIs as names for things
  2. Use HTTP URIs so that people can look up those names.
  3. When someone looks up a URI, provide useful information, using the standards (RDF*, SPARQL)
  4. Include links to other URIs. so that they can discover more things.

もう少し噛み砕いて言い直すと、

  1. データにURLを割り当てる。
  2. 実際にURLにアクセスしたときにRDFを返すようにする。
  3. 他の(RDF)データに適当な述語を用いてリンクする。

最低限これだけやれば Linked Data が活用できる。

詳細なオントロジーなどは実際に使いながら考えていけば良い。たとえば、

  • データAとデータBはまとめて検索できるといいなぁ
    • -> それぞれのデータのクラスとそれらのスーパークラスを定義する。
  • データAからリンクしているリソースをまとめて取得したいなぁ
    • -> リンクに使っている述語（群）のスーパープロパティを定義する。
  • 他のオントロジーのクラスBが自分のデータのクラスAと関係するなぁ。
    • -> たとえば AをBのサブクラスにする。

貧乏人あるいはモノグサのための LOD：ユースケース

  1. あるURLを指定してRDFを取得する。
    • →したがってURLで実際にRDFを取得できることが必須。
  2. 必要なトリプルをフィルタする。
    • →述語や主語、目的語のクラスが分かりやすい形で定義されていることが必要。
  3. リンクされているデータを取ってくる。
    • → いろいろなリソースへのリンクが張られていることが必要。
  4. 以上を繰り返す。
    • → いろいろなプロバイダが以上のようなデータを提供してくれることが必要。

これで、最初のデータと関連するデータを集めてくる。

RDFの公開について

  • URLは実際にデータを取得できるものにする。
  • いろいろなリソースへのリンクが重要。

オントロジーについて

  • 結局のところ、オントロジーは人間に理解しやすい形が良いと思う。
    • でないと、どれが自分の欲しいトリプルかが述語やクラスから判別できない。
    • あるいは、まともにSPARQLクエリも書けない。
  • プロパティやクラスでフィルタするためには、結局はそれらを「手で」打ち込まないといけない。そのためにも単純で覚えやすいオントロジーが望まれる。
  • 最低限必要なのは、ユニークな述語。 これさえあれば、何とか使える。
    • RDFS/OWL で定義する必要すらない…

リンクについて

  • リンクは、できるだけオリジナルのサイトへ直接張るのが望ましい。
    • UniProt のようにpURLで自身のサイトへのリンクを張ってそれを転送するのはあとあとデータがつながらなくなる原因となる。
      • 例：purl.uniprot.org/prosite/... は実際にはbio2rdf.org/prosite:... へ転送されるが、それらの関係はどこにも記述されていないため、グラフが断絶する。(下記参照（SPARQL))

SPARQL endpoint について

  • SPARQL は使えたら良いけど、使わなくても何とかなるのが LOD の良いところだと思う。
    • データ自身がリンクされているので、とにかくリンクを辿ればいつかは欲しいデータに至ることが重要。
  • むずかしい設定とか運用とかはDBCLSに任せる！

具体例

  • PDB entry -> UniProt -> PROSITE (Bio2RDF) -> PDB
    • 与えられたPDB エントリに対応するUniProtエントリからPROSITEモチーフを抜き出してそれを持つ他のPDBエントリを求める。

これをするには、ひとつのPDBエントリ（例えば、http://pdbj.org/rdf/1ATP） からスタートして、以下の(s,p,o) のパターンを持つトリプルを、それらの作るグラフのサイズが収束するまで集め続ければ良い。

spo
_<http://pdbj.org/schema/pdbx-v40.owl#has_struct_refCategory>_
_<http://pdbj.org/schema/pdbx-v40.owl#has_struct_ref>_
_<http://pdbj.org/schema/pdbx-v40.owl#reference_to_entity>_
_<http://pdbj.org/schema/pdbx-v40.owl#entity.pdbx_description>_
_<http://pdbj.org/schema/pdbx-v40.owl#link_to_uniprot>_
_<http://bio2rdf.org/bio2rdf_resource:xPDB>_
_<http://purl.uniprot.org/core/database><http://purl.uniprot.org/database/PROSITE>

注意点 

<http://purl.uniprot.org/uniprot/P05132> rdfs:seeAlso <http://purl.uniprot.org/prosite/PS51285> .

となって述語が非常に一般的な rdfs:seeAlso であるために、述語だけではPROSITEをフィルタできないから。このトリプルの述語が UP:xPROSITE 等とPROSITEのみを目的語としてとるものなっていれば、それだけでフィルタできるし、そもそも、 

<http://purl.uniprot.org/prosite/PS51285> <http://purl.uniprot.org/core/database> <http://purl.uniprot.org/database/PROSITE> .

というトリプルは不要になる（RDFのサイズも小さくできる）。

SPARQL との対応

もし、適当なトリプルストアがあれば、以下のSPARQLクエリでもできそうに見える： 

PREFIX PDBo: <http://pdbj.org/schema/pdbx-v40.owl#> 
PREFIX PDBr: <http://pdbj.org/rdf/> 
PREFIX UP: <http://purl.uniprot.org/core/> 
PREFIX B2: <http://bio2rdf.org/bio2rdf_resource:>

SELECT DISTINCT ?up ?ps ?pdb2
WHERE { 
PDBr:1ATP PDBo:has_struct_refCategory ?o1 .
?o1 PDBo:has_struct_ref ?o2 .
?o2 PDBo:link_to_uniprot ?up .
?o2 PDBo:reference_to_entity ?ent .
?ent PDBo:entity.pdbx_description ?desc .
?up ?upprosite ?ps .
?ps UP:database <http://purl.uniprot.org/database/PROSITE> .
?ps B2:xPDB ?pdb2
 }

ところが！UniProtからPROSITEへのリンクは http://purl.uniprot.org/prosite/PS50011 となっているが、実際にはBio2RDFに転送されて、http://bio2rdf.org/prosite:PS50011 のページに飛ぶ。すると、http://purl.uniprot.org/prosite/PS50011 sameAs http://bio2rdf.org/prosite:PS50011 というトリプルがどこにもないので、上のSPARQLは答えを何も返せない。

Member

  • 金城玲

付録

LOD crawler のソースファイル（のPDF) 興味があれば金城まで。

「/mw/BH11.11/EasyLOD」より作成