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

# SPARQL を使用した Neptune のベストプラクティス
<a name="best-practices-sparql"></a>

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

**Topics**
+ [デフォルトですべての名前が付いたグラフのクエリの実行](best-practices-sparql-query.md)
+ [ロード用に名前付きのグラフを指定する](best-practices-sparql-graph.md)
+ [クエリで FILTER、FILTER...IN、および VALUES を選択する](best-practices-sparql-batch.md)

# デフォルトですべての名前が付いたグラフのクエリの実行
<a name="best-practices-sparql-query"></a>

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

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

```
SELECT * WHERE { ?s ?p ?o }
```

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

デフォルトグラフ仕様についての詳細は、SPARQL 1.1 クエリ言語仕様の「[RDF データセット](https://www.w3.org/TR/sparql11-query/#rdfDataset)」セクションを参照してください。

# ロード用に名前付きのグラフを指定する
<a name="best-practices-sparql-graph"></a>

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

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

# クエリで FILTER、FILTER...IN、および VALUES を選択する
<a name="best-practices-sparql-batch"></a>

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)}
```

これにより、`?s` または `ex:person1` への `ex:person2` バウンドがあり、`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` クエリには、結果の重複内容が含まれています。このような重複は、`DISTINCT` 句に `SELECT` を追加して、明示的に排除することができます。しかし、重複した値の挿入に対して、クエリ結果での重複が必要になるような状況が発生する可能性があります。

  ただし、`FILTER` バージョンと `FILTER...IN` バージョンでは、同じ値が繰り返し現れるとき、1 回だけ値を抽出します。
+ 2 番目のケースは `VALUES` が常に完全一致を実行する一方で、`FILTER` ではタイププロモーションが適用され、あいまい一致を実行する場合があることに関係しています。

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

  対照的に、`FILTER` では、これらの数値リテラルに対してあいまい一致が出されます。一致には、同じ値で、`xsd:double` など、数値データ型が異なるリテラルを含めることができます。
**注記**  
`FILTER` と `VALUES` の動作に、文字列リテラルまたは URI を列挙する際の違いはありません。

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