SPARQLthon19/MBGD

提供：TogoWiki

移動： 案内, 検索

SPARQLthon19

目次

SPINに関する調査・考察

http://spinrdf.org [1]


以下の3つポイントについて提案をしたことが重要だとおもう。

関数の定義

SPARQLでは、よく使う部品のようなコードが見えてきたとしても、うまくカプセル化して利用するような方法がない。

よく使うコード断片に名前を付けて、それを関数としてSPARQLの中で呼び出せるようなったら、すごくうれしい。

SPINでは、SELECT形式（あるいはASK）のクエリに対して名前をつけて、関数として定義できる。

URI形式の関数名をグローバルに利用して、リモートで呼び出せたりしたら、さらにいいかもしれない。

推論ルールの記述

SPARQLのCONSTRUCT形式を用いれば、既存のデータに存在するトリプルパターンに基づいて、新しいトリプルを生成できる。すなわち推論ルールを記述できる。

OWLによる記述よりも直感的で、SPARQLに慣れていれば手軽に記述できるだろうし、しかもできることの範囲がかなり広がりそう。

こうして記述した推論ルールを利用して、動的に推論検索できるようになったら、これはすごい。

SPINでは、クラス定義とセットで、そのクラスに関する推論ルールを記述するよう提案しているが、必ずしもクラスごとに記述する必要もない気がする。

制約の記述

SPARQLで条件を記述すれば、ある制約を満たさない箇所を検索することができる。

結果は、ASKを使ってbooleanで出力してもいいし、CONSTRUCTで問題個所をトリプルにしてレポートしてもいい。

これはたしかに、データ管理の自動化に役立つかもしれない。ただいかんせん上記２つのインパクトがでかすぎる気が。

そしてこれも、かならずしもクラス定義とセットで記述しなくてもいいような気がする。


上記3つのポイントについて、もしW3Cによる標準化 [2] [3] 、そして各RDFストアによる実装 [4] [5] へと進んだら、かなりうれしいことになると思う [6] 。

一方で、かなり頑張って定義したとみられる以下の点については、今のところあまりメリットが感じられない。

SPARQLクエリのRDF表現

SPARQLクエリをRDF形式に変換するため、トリプルパターンの並びをリストとして扱い、さらにSPOをばらしてreificationのようなことをやったりしている。

しかしながら、SPARQLクエリはもとの文字列のままで機械処理可能であって、RDF形式にしたところで可読性が失われるだけとおもえる。

このRDF表現を読み書きするライブラリのようなものが充実・普及したりしたら、また風向きは変わるのか。しかしここまで読みにくいのは素直に問題だと思う。

実際、提案したRDF表現はかなり不評だったようで [7] [8] 、2013/1 に仕様が変更され、SPARQLクエリを文字列として持つだけでもよくなったようだ。 [9]


活用事例

比較

データセットに対するメタデータ（VoID等）の整理

以前、EBI RDFにおける用語の使われ方を調査した[10]。これを再度整理して、これらのうちどういった用語が使えるか検討した。


作者

日付

  • dc:created "2009-10-28T00:00:00.0"^^xsd:dateTime .
  • pav:createdOn "2009-10-28T00:00:00.0"^^xsd:dateTime
  • dc:issued "2013-07-19T20:16:03.0"^^xsd:dateTime
  • dc:modified "2013-08-29T00:00:00.0"^^xsd:dateTime
  • pav:lastUpdateOn "2013-08-29T00:00:00.0"^^xsd:dateTime
  • pav:importedOn "2013-07-19T20:16:03.0"^^xsd:dateTime

由来

他

  • pav:version "26"^^xsd:string
  • rdf:type void:Dataset
  • rdf:type owl:NamedIndividual .
  • void:sparqlEndpoint
  • void:vocabulary
  • void:exampleResource
  • void:dataDump
  • dc:subject

参考

「/mw/SPARQLthon19/MBGD」より作成