数年前から、Linked Data の量は急速に増加しています。RDF を使用して公開されたさまざまなグラフがあります。すべてのグラフには、独自の接頭辞と語彙構造があります。
では、このグラフを使用して特定のエンティティと関連データをクエリするにはどうすればよいでしょうか?
各グラフの個々の構造を調べて、システム ロジックに実装する必要がありますか?
または、構造を知らなくても SPARQL でデータをクエリする良い方法はありますか?
数年前から、Linked Data の量は急速に増加しています。RDF を使用して公開されたさまざまなグラフがあります。すべてのグラフには、独自の接頭辞と語彙構造があります。
では、このグラフを使用して特定のエンティティと関連データをクエリするにはどうすればよいでしょうか?
各グラフの個々の構造を調べて、システム ロジックに実装する必要がありますか?
または、構造を知らなくても SPARQL でデータをクエリする良い方法はありますか?
いいえ、そうではありません。やみくもにデータベースにクエリを実行することはできません。興味のあるデータのスライスを取得するための賢明なクエリを考え出すには、その内容について何かを知る必要があります。
ただし、データセットに関する知識がなくても、いくつかの非常に一般的なクエリを実行して、ナビゲーションのビルディング ブロックの作成を開始できます。
select distinct ?p where { ?s ?p ?o }
これにより、データベースで使用されるすべての述語が返されます。大まかにすべてのクラスを取得するには:
select distinct ?t where { ?s a ?t }
または、これらを組み合わせて、各クラスで使用されるすべての述語を取得できます
select distinct ?p ?t where { ?s a ?t . ?s ?p ?o }
このようなクエリを発行することで、データベースの内容を把握し始めることができます。しかし、これらは実際には、データの基礎となるスキーマが何であるかを概算 (推測) しようとしているだけです。そのため、データに関連付けられている RDF スキーマまたは OWL オントロジーを確認したほうがよいでしょう (存在すると仮定)。さらに、これらのクエリは、その一般性を考えると、データベースによって提供される最適化に応じて、データベース上で実行するのは自明ではありません。したがって、それらをランダムなエンドポイントに送信する前に、それを検討することをお勧めします。
LoD クラウドの一部のデータセットは、上記のクエリまたはスキーマの大まかな概要から得られるものの一部を概説するようなvoid 記述を提供する場合があり、作業を進めるのに十分です。
一般に、グラフのトラバースを開始するだけではなく、グラフの構造について学習し、アプリケーションで最も関心のあるデータのサブセットを取得する正確なクエリを考え出すことをお勧めします。LoD クラウドの良い点の 1 つは、多くのデータセットが使用する語彙である程度重複していることです。FOAF や Dublin Core などの一般的な語彙の知識があれば、探索からいくらかのマイレージを得ることができます。次に、これをクラウドの一部で使用される語彙と組み合わせると、アプリケーションで機能するクエリの作成を開始できます。
最初の質問に答えるために、今までに明確でない場合は、はい、グラフ内の特定のエンティティを照会できます。知っておく必要があるのは、その URI だけです。実際、それを知ったら:
describe <uri_of_the_interesting_entity>
そのエンティティに関連するグラフのサブセットを取得します。describe クエリで何が返されるかは、データベースが使用するアルゴリズムによって異なりますが、一般的には、少なくとも対象となるすべてのトリプルが含まれます。
SPARQL 仕様に慣れていない場合は、時間をかけて確認してください。幸運を。