SPARQLを使い込む 補足

第5回LinkedData勉強会が先日開かれて「SPARQLを使い込む」と題した発表をさせていただきました。


ここでは発表中に口頭でのみお伝えした点やお伝えしきれなかった点について補足しておきます。
SERVICEキーワードを利用したfederated queriesではリモートのSPARQLエンドポイントに対して容易に大量のデータを返す様なクエリを発行出来てしまいます。従ってこの便利な機能を使う際には、実際にリモートに投げられるクエリを想定して行うのが良いと思います。
クエリの構造として同じスコープにある変数の場合、実際にクエリに書かれている順番にバインドされていくわけではないので、リモートに投げられる時点で、記述したクエリの変数のいずれかがバインドされていることを想定することが出来ません。従って、探索空間が非常に広くなりえることに注意が必要と思います。

SELECT * WHERE {
  ?s ?p ex:obj1213 .
  SERVICE  {
    ?s xe:pred22 ?o .
  }
}

このような場合で、仮に ex:obj1213 を目的語にもつ主語が一つしかなかったとしても、リモートに投げられるクエリには ?s に当該主語がバインドされているとは限らないので、xe:pred22 を述語にもつ全ての主語と目的語の組を探すことになり得ます。

それから、SPARQL1.1で加わった機能のうち、発表中に触れなかった主な項目としてデータベースの更新系があります。CRUDの、Create / Update / Delete が出来るようになっています (参考)。その他、クエリに関しては、以下の機能が1.1になり新たに加わっています (参考)。

このうち、まず、Aggregatesについては、数値処理の集合演算であるCOUNTSUMなどを除いて紹介していませんが、これらに加え、SQLでお馴染みのGROUP BYHAVINGが使えるようになっています。
また、一つのクエリ表現で複数の述語にマッチさせられる表記法法、Property Pathsについて全く触れておりません。これについては去年の第2回LinkedData勉強会で加藤さんがSPARQLの基礎と題して説明されていますのでご参照願います。
その他、CONSTRUCTの短縮表現についても扱っていません。これはCONSTRUCT WHEREと記述するもので、CONSTRUCTキーワード後のグラフパターンを省略出来る表現方法です。これは、WHERE直後のグラフパターンが単純であるときに使えます。つまり、FILTERキーワードや複雑なグラフパターンが含まれてなく、そのパターンがそのままトリプルとして取り出せる様なクエリであることが条件になります。詳細は上記リンク先をご確認ください。