翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # Amazon Neptune の SPARQL 標準準拠 適用可能な SPARQL 標準を列挙したあと、以下のセクションでは、Neptune の SPARQL 実装がそれらの標準からどのように拡張し、または異なるかについて具体的な詳細を説明します。 **Topics** + [SPARQL に適用される標準](#feature-sparql-applicable-standards) + [Neptune SPARQL のデフォルトの名前空間プレフィックス](#sparql-default-prefixes) + [SPARQL デフォルトグラフと名前が付いたグラフ](#sparql-default-graph) + [Neptune でサポートされている SPARQL XPath コンストラクタ関数](#access-graph-sparql-xpath-constructors) + [クエリと更新のためのデフォルトベース IRI](#opencypher-compliance-default-iri) + [Neptune での xsd:dateTime の値](#access-graph-sparql-xsd-date-time) + [Neptune による特殊な浮動小数点値の処理](#feature-overview-special-values-comparisons) + [Neptune での任意長の値の制限](#feature-overview-arbitrary-length-values) + [Neptune で拡張される SPARQL の不等比較](#feature-overview-sparql-not-equal) + [Neptune SPARQL での範囲外リテラルの処理](#feature-overview-sparql-out-of-range) Amazon Neptune は、SPARQL グラフクエリ言語を実装する際に次の標準に準拠しています。 ## SPARQL に適用される標準 + SPARQL は、2013 年 3 月 21 日の W3C [SPARQL 1.1 クエリ言語](https://www.w3.org/TR/sparql11-query/)勧告に基づいて定義されています。 + SPARQL 更新プロトコルとクエリ言語は、W3C [SPARQL 1.1 更新](https://www.w3.org/TR/sparql11-update/)仕様で定義されています。 + 数値形式の場合、SPARQL は [W3C XML スキーマ定義言語 (XSD) 1.1 パート 2: データ型](https://www.w3.org/TR/xmlschema11-2/)仕様に従っています。この仕様は IEEE 754 仕様を準拠しています ([IEEE 754-2019 - IEEE Standard for Floating-Point Arithmetic](https://standards.ieee.org/content/ieee-standards/en/standard/754-2019.html)/[Wikipedia IEEE 754 ページも参照](https://en.wikipedia.org/wiki/IEEE_754)してください)。ただし、`IEEE 754-1985` バージョン以降に導入された機能は、仕様には含まれません。 ## Neptune SPARQL のデフォルトの名前空間プレフィックス Neptune は、SPARQL クエリで使用するためにデフォルトで以下のプレフィックスを定義します。詳細については、SPARQL 仕様の「[接頭辞付き名](https://www.w3.org/TR/sparql11-query/#prefNames)」を参照してください。 + `rdf`  – `http://www.w3.org/1999/02/22-rdf-syntax-ns#` + `rdfs` – `http://www.w3.org/2000/01/rdf-schema#` + `owl`  – `http://www.w3.org/2002/07/owl#` + `xsd`  – `http://www.w3.org/2001/XMLSchema#` ## SPARQL デフォルトグラフと名前が付いたグラフ 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)」セクションを参照してください。 **ロード、挿入や更新用に名前付きのグラフを指定する** トリプルのロード、挿入あるいは更新時に名前が付いたグラフを指定しない場合、Neptune は URI `http://aws.amazon.com/neptune/vocab/v01/DefaultNamedGraph` が定義するフォールバックの名前付きグラフを使用します。 Neptune がトリプルベースの形式を使用して `Load` リクエストを発行する場合、`parserConfiguration: namedGraphUri` パラメータを使用して、すべてのトリプルを使用するように名前付きのグラフを指定できます。`Load` コマンド構文の詳細については、「[Neptune ローダーコマンド](load-api-reference-load.md)」を参照してください。 **重要** このパラメータを使用せず、名前付きのグラフを指定しない場合、フォールバック URI が使用されます。`http://aws.amazon.com/neptune/vocab/v01/DefaultNamedGraph`。 このフォールバックの名前付きグラフは、名前付きグラフターゲットを明示的に提供しないで、`SPARQL UPDATE` を介してトリプルをロードする場合にも使用されます。 クワッドベース形式の N-Quads を使用して、データベースの各トリプルに名前付きグラフを指定できます。 **注記** N-Quads では名前付きグラフを空にできます。この場合、`http://aws.amazon.com/neptune/vocab/v01/DefaultNamedGraph` が使用されます。 `namedGraphUri` パーサー設定オプションを使用して、N-Quads のデフォルトの名前付きグラフを上書きできます。 ## Neptune でサポートされている SPARQL XPath コンストラクタ関数 SPARQL 標準により、SPARQL エンジンは一連の拡張可能な XPath コンストラクタ関数をサポートできます。Neptune は現在、以下のコンストラクター関数をサポートしています。ここで `xsd` プレフィックスは `http://www.w3.org/2001/XMLSchema#` と定義されます。 + `xsd:boolean` + `xsd:integer` + `xsd:double` + `xsd:float` + `xsd:decimal` + `xsd:long` + `xsd:unsignedLong` ## クエリと更新のためのデフォルトベース IRI Neptune クラスターには複数の異なるエンドポイントがあるため、クエリまたは更新のリクエスト URL をベース IRI として使用すると、相対 IRI を解決する際に予期しない結果が生じる可能性があります。 [エンジンリリース 1.2.1.0](engine-releases-1.2.1.0.md) では、明示的なベース IRI がリクエストに含まれていない場合、Neptune は `http://aws.amazon.com/neptune/default/` をベース IRI として使用します。 次のリクエストでは、ベース IRI はリクエストの一部です。 ``` BASE INSERT DATA { "n1" } BASE SELECT * { ?p ?o } ``` 結果は次のようになります。 ``` ?p ?o http://example.org/default/id n1 ``` ただし、このリクエストにはベース IRI は含まれていません。 ``` INSERT DATA { "n1" } SELECT * { ?p ?o } ``` その場合、結果は以下のようになります。 ``` ?p ?o http://aws.amazon.com/neptune/default/id n1 ``` ## Neptune での xsd:dateTime の値 パフォーマンス上の理由から、Neptune は 常に協定世界時 (UTC) として日付/時刻値を保存します。これにより、直接比較が非常に効率的になります。 つまり、特定のタイムゾーンを指定する `dateTime` 値を入力すると、Neptune は値を UTC に変換し、そのタイムゾーン情報を破棄します。その後、後で `dateTime` 値を取得すると、元のタイムゾーンの時間ではなく UTC で表され、元のタイムゾーンが何であったかを知ることができなくなります。 ## Neptune による特殊な浮動小数点値の処理 Neptune は、SPARQL の特殊な浮動小数点値を次のように処理します。 ### SPARQL NaN Neptune での処理 Neptune では、SPARQL はクエリで値として `NaN` を使用できます。シグナルおよびクワイエットの `NaN` 値は区別されません。Neptune は、すべての `NaN` 値をクワイエットとして扱います。 `NaN` より大きい、より小さい、または等しいものは何もないため、`NaN` の比較はできません。つまり、比較の一方の `NaN` の値は、比較の他方の*いずれの値*とも一致しません。 しかし、[XSD仕様](https://www.w3.org/TR/xmlschema-2/#double)は 2 つの`xsd:double`または`xsd:float` `NaN`等しいものとして扱います。Neptune は、`IN` フィルター、フィルター式の等号演算子、完全一致セマンティクス (トリプルパターンのオブジェクト位置の `NaN` にある) についてはこれに従います。 ### Neptune での SPARQL 無限値の処理 Neptune では、SPARQL はクエリで `INF` または`-INF` の値を使用できます。`INF` は他のどの数値よりも大きい値、`-INF` は他のどの数値よりも小さい値と見なされます。 符号が一致する 2 つの INF 値は、型に関係なく互いに等しいと比較されます (たとえば、float `-INF` は double `-INF` と等しいと比較されます)。 `NaN` より大きい、より小さい、等しいものは何もないため、当然ながら `NaN` の比較はできません。 ### Neptune での SPARQL 負のゼロ処理 Neptune は、負のゼロ値を符号なしゼロに正規化します。負のゼロ値はクエリで使用できますが、データベースにはそのように記録されず、符号なしゼロと等しいと見なされます。 ## Neptune での任意長の値の制限 Neptune は、SPARQL の XSD 整数、浮動小数点、10 進値のストレージサイズを 64 ビットに制限します。より大きい値を使用すると、`InvalidNumericDataException` エラーが発生します。 ## Neptune で拡張される SPARQL の不等比較 SPARQL 標準は、値式の 3 項ロジックを定義します。値式は、`true`、`false`、または `error` のいずれかに評価されます。[SPARQL 1.1 仕様](https://www.w3.org/TR/sparql11-query/#func-RDFterm-equal) で定義される項等価のデフォルトのセマンティクスは、`FILTER` 条件で `=` および `!=` の比較に当てはまり、仕様で[演算子テーブル](https://www.w3.org/TR/sparql11-query/#OperatorMapping)において明示的に比較できないデータ型を比較する場合に、`error` を生成します。 この動作は、次の例のように、直感的でない結果につながる可能性があります。 データ: ``` "127.0.0.1"^^ ``` クエリ 1: ``` SELECT * WHERE { ?o . FILTER(?o = "127.0.0.2"^^) } ``` クエリ 2: ``` SELECT * WHERE { ?o . FILTER(?o != "127.0.0.2"^^) } ``` Neptune でリリース 1.0.2.1 より前に使用していたデフォルトの SPARQL セマンティクスでは、どちらのクエリからも空の結果が返されます。その理由として、`?o = "127.0.0.2"^^` は、`?o := "127.0.0.1"^^` に評価された場合に、`false` ではなく `error` を生成するためです。これは、カスタムデータ型 `` に対して明示的に指定された比較ルールが存在しないことが原因です。その結果、2 番目のクエリの否定バージョンも `error` を生成します。どちらのクエリでも、`error` により、候補ソリューションが除外されます。 リリース 1.0.2.1 以降では、Neptune は仕様どおりに SPARQL の非等値演算子を拡張しています。[演算子の拡張性に関する SPARQL 1.1 セクション](https://www.w3.org/TR/sparql11-query/#operatorExtensibility)を参照してください。この拡張により、エンジンは、ユーザー定義や比較不可能な組み込みデータ型を比較する方法に関する追加のルールを定義できます。 このオプションを利用することで、Neptune は、演算子マッピングテーブルで明示的に定義されていない任意の 2 つのデータ型を比較した場合に、リテラル値とデータ型が構文的に等しいときは `true` として、そうでないときは false として評価するようになります。いずれの場合も、`error` は生成されません。 これらの新しいセマンティクスを使用すると、上の 2 番目のクエリからは空の結果の代わりに `"127.0.0.1"^^` が返されます。 ## Neptune SPARQL での範囲外リテラルの処理 XSD セマンティクスは、`integer` および `decimal` を除く各数値型を値空間で定義します。これらの定義は、各型を値の範囲に制限します。たとえば、`xsd:byte` 範囲の範囲は -128 から \$1127 までです。この範囲外の値は無効とみなされます。 型の値空間の外にリテラル値を割り当てようとした場合 (たとえば、`xsd:byte` をリテラル値 999 に設定しようとした場合) は、 は範囲外の値を切り上げたり切り捨てたりすることなく、そのままの範囲外の値を受け入れます。しかし、与えられた型はそれを表すことができないので、数値として持続しません。 つまり、定義された `xsd:byte` 値の範囲外の値であっても Neptune は `"999"^^xsd:byte` を受け入れます。ただし、値がデータベースで永続化されると、3 重パターンのオブジェクト位置で、完全一致セマンティクスでのみ使用できます。範囲外のリテラルは数値として扱われないため、範囲フィルターは実行できません。 SPARQL 1.1 仕様では、`numeric`*-operator-*`numeric`、`string`*-operator-*`string`、`literal`*-operator-*`literal`などのフォームで[範囲演算子](https://www.w3.org/TR/sparql11-query/#OperatorMapping)を定義します。Neptune は`invalid-literal`*-operator-*`numeric-value`などの範囲比較演算子を実行できません。