SPARQL を使用した Neptune のベストプラクティス - Amazon Neptune
すべての名前付きグラフのクエリの実行ロードする名前付きのグラフを指定するFILTER vs.VALUES

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

SPARQL を使用した Neptune のベストプラクティス

Neptune で SPARQL クエリ言語を使用する場合は、これらのベストプラクティスに従ってください。Neptune で SPARQL を使用する方法については、を使用した Neptune グラフへのアクセス SPARQLを参照してください。

デフォルトですべての名前が付いたグラフのクエリの実行

Amazon Neptune はすべてのトリプルを名前が付いたグラフに関連付けます。デフォルトグラフはすべての名前が付いたグラフの総合として定義されます。

GRAPH キーワードや構成 (FROM NAMED など) を使用してグラフを明示的に指定せずに SPARQL クエリを送信すると、Neptune は常に DB インスタンスのすべてのトリプルを考慮します。たとえば、次のクエリはすべてのトリプルを Neptune SPARQL エンドポイントから返します。

SELECT * WHERE { ?s ?p ?o }

1 つ以上のグラフに表されるトリプルは、1 度だけ返されます。

デフォルトグラフ仕様についての詳細は、SPARQL 1.1 クエリ言語仕様の「RDF データセット」セクションを参照してください。

ロード用に名前付きのグラフを指定する

Amazon Neptune はすべてのトリプルを名前が付いたグラフに関連付けます。トリプルのロード、挿入あるいは更新時に名前が付いたグラフを指定しない場合、Neptune は URI http://aws.amazon.com/neptune/vocab/v01/DefaultNamedGraph が定義するフォールバックの名前付きグラフを使用します。

Neptune バルクローダーを使用する場合、parserConfiguration: namedGraphUri パラメータを使用して、すべてのトリプル (または 4 番目の位置に空白がある四角形) を使用するように名前付きのグラフを指定できます。Neptune ローダー Load コマンド構文についての詳細は、Neptune ローダーコマンドを参照してください。

クエリで FILTER、FILTER...IN、および VALUES を選択する

SPARQL クエリに値を挿入するには、FILTER、FILTER...IN、VALUES の 3 つの基本的な方法があります。

たとえば、単一のクエリで複数の人から友人を検索するとします。FILTER を使用して、クエリを次のように構築します。

  PREFIX ex: <https://www.example.com/>
  PREFIX foaf : <http://xmlns.com/foaf/0.1/>

  SELECT ?s ?o
  WHERE {?s foaf:knows ?o. FILTER (?s = ex:person1 || ?s = ex:person2)}

これにより、ex:person1 または ex:person2 への ?s バウンドがあり、foaf:knows というラベル付きの出ていく辺があるグラフにあるすべてのトリプルを返します。

また、同等の結果を返す FILTER...IN を使用してクエリを作成することができます。

  PREFIX ex: <https://www.example.com/>
  PREFIX foaf : <http://xmlns.com/foaf/0.1/>

  SELECT ?s ?o
  WHERE {?s foaf:knows ?o. FILTER (?s IN (ex:person1, ex:person2))}

この場合は同等の結果を返す VALUES を使用してクエリを作成することもできます。

  PREFIX ex: <https://www.example.com/>
  PREFIX foaf : <http://xmlns.com/foaf/0.1/>

  SELECT ?s ?o
  WHERE {?s foaf:knows ?o. VALUES ?s {ex:person1 ex:person2}}

多くの場合、これらのクエリは意味的に同等ですが、2 つの FILTER バリアントが VALUES バリエーションと異なる場合があります。

  • 最初のケースは、同じ個人を 2 回挿入するなど、重複した値を挿入する場合です。この場合、VALUES クエリには、結果の重複内容が含まれています。このような重複は、SELECT 句に DISTINCT を追加して、明示的に排除することができます。しかし、重複した値の挿入に対して、クエリ結果での重複が必要になるような状況が発生する可能性があります。

    ただし、FILTER バージョンと FILTER...IN バージョンでは、同じ値が繰り返し現れるとき、1 回だけ値を抽出します。

  • 2 番目のケースは VALUES が常に完全一致を実行する一方で、FILTER ではタイププロモーションが適用され、あいまい一致を実行する場合があることに関係しています。

    たとえば、"2.0"^^xsd:float などのリテラルを値に含める場合、VALUES クエリは、リテラル値とデータ型を含め、このリテラルに正確に一致します。

    対照的に、FILTER では、これらの数値リテラルに対してあいまい一致が出されます。一致には、同じ値で、xsd:double など、数値データ型が異なるリテラルを含めることができます。

    注記

    FILTER と VALUES の動作に、文字列リテラルまたは URI を列挙する際の違いはありません。

FILTER と VALUES の違いは、最適化と生成されるクエリ評価戦略に影響を与える可能性があります。ユースケースであいまい一致を必要としない限り、VALUES を使用することをお勧めします。これにより、型キャストに関連する特殊なケースを確認するのを避けることができます。その結果、VALUES では、高速で動作し、低コストの効率的なクエリを作成できることがよくあります。