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

Amazon Neptune の SPARQL 標準準拠

適用可能な SPARQL 標準を列挙したあと、以下のセクションでは、Neptune の SPARQL 実装がそれらの標準からどのように拡張し、または異なるかについて具体的な詳細を説明します。

Amazon Neptune は、SPARQL グラフクエリ言語を実装する際に次の標準に準拠しています。

SPARQL に適用される標準

Neptune SPARQL のデフォルトの名前空間プレフィックス

Neptune は、SPARQL クエリで使用するためにデフォルトで以下のプレフィックスを定義します。詳細については、SPARQL 仕様の「接頭辞付き名」を参照してください。

SPARQL デフォルトグラフと名前が付いたグラフ

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

クエリ用のデフォルトグラフ

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

SELECT * WHERE { ?s ?p ?o }

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

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

ロード、挿入や更新用に名前付きのグラフを指定する

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

Neptune がトリプルベースの形式を使用して Load リクエストを発行する場合、parserConfiguration: namedGraphUri パラメータを使用して、すべてのトリプルを使用するように名前付きのグラフを指定できます。Load コマンド構文の詳細については、「Neptune ローダーコマンド」を参照してください。

このフォールバックの名前付きグラフは、名前付きグラフターゲットを明示的に提供しないで、SPARQL UPDATE を介してトリプルをロードする場合にも使用されます。

クワッドベース形式の N-Quads を使用して、データベースの各トリプルに名前付きグラフを指定できます。

Neptune でサポートされている SPARQL XPath コンストラクタ関数

SPARQL 標準により、SPARQL エンジンは一連の拡張可能な XPath コンストラクタ関数をサポートできます。Neptune は現在、以下のコンストラクター関数をサポートしています。ここで xsd プレフィックスは http://www.w3.org/2001/XMLSchema# と定義されます。

クエリと更新のためのデフォルトベース IRI

Neptune クラスターには複数の異なるエンドポイントがあるため、クエリまたは更新のリクエスト URL をベース IRI として使用すると、相対 IRI を解決する際に予期しない結果が生じる可能性があります。

エンジンリリース 1.2.1.0 では、明示的なベース IRI がリクエストに含まれていない場合、Neptune は http://aws.amazon.com/neptune/default/ をベース IRI として使用します。

次のリクエストでは、ベース IRI はリクエストの一部です。

BASE <http://example.org/default/>
INSERT DATA { <node1> <id> "n1" }

BASE <http://example.org/default/>
SELECT * { <node1> ?p ?o }

結果は次のようになります。

?p                                                   ?o
http://example.org/default/id                        n1

ただし、このリクエストにはベース IRI は含まれていません。

INSERT DATA { <node1> <id> "n1" }

SELECT * { <node1> ?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仕様は 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 仕様) で定義される項等価のデフォルトのセマンティクスは、FILTER 条件で = および != の比較に当てはまり、で仕様で演算子テーブルにおいて明示的に比較できないデータ型を比較する場合、error を生成します。

この動作は、次の例のように、直感的でない結果につながる可能性があります。

データ:

<http://example.com/Server/1> <http://example.com/ip> "127.0.0.1"^^<http://example.com/datatype/IPAddress>

クエリ 1:

SELECT * WHERE {
    <http://example.com/Server/1> <http://example.com/ip> ?o .
    FILTER(?o = "127.0.0.2"^^<http://example.com/datatype/IPAddress>)
}

クエリ 2:

SELECT * WHERE {
    <http://example.com/Server/1> <http://example.com/ip> ?o .
    FILTER(?o != "127.0.0.2"^^<http://example.com/datatype/IPAddress>)
}

Neptune でリリース 1.0.2.1 より前に使用していたデフォルトの SPARQL セマンティクスでは、どちらのクエリからも空の結果が返されます。その理由として、?o = "127.0.0.2"^^<http://example.com/IPAddress> は、?o := "127.0.0.1"^^<http://example.com/IPAddress> に評価された場合に、false ではなく error を生成するためです。これは、カスタムデータ型 <http://example.com/IPAddress> に対して明示的に指定された比較ルールが存在しないことが原因です。その結果、2 番目のクエリの否定バージョンも error を生成します。どちらのクエリでも、error により、候補ソリューションが除外されます。

リリース 1.0.2.1 以降では、Neptune は仕様どおりに SPARQL の非等値演算子を拡張しています。演算子の拡張性に関する SPARQL 1.1 セクションを参照してください。この拡張により、エンジンは、ユーザー定義や比較不可能な組み込みデータ型を比較する方法に関する追加のルールを定義できます。

このオプションを利用することで、Neptune は、演算子マッピングテーブルで明示的に定義されていない任意の 2 つのデータ型を比較した場合に、リテラル値とデータ型が構文的に等しいときは true として、そうでないときは false として評価するようになります。いずれの場合も、error は生成されません。

これらの新しいセマンティクスを使用すると、上の 2 番目のクエリからは空の結果の代わりに "127.0.0.1"^^<http://example.com/IPAddress> が返されます。

Neptune SPARQL での範囲外リテラルの処理

XSD セマンティクスは、integer および decimal を除く各数値型を値空間で定義します。これらの定義は、各型を値の範囲に制限します。たとえば、xsd:byte 範囲の範囲は -128 から +127 までです。この範囲外の値は無効とみなされます。

型の値空間の外にリテラル値を割り当てようとした場合 (たとえば、xsd:byte をリテラル値 999 に設定しようとした場合) は、 は範囲外の値を切り上げたり切り捨てたりすることなく、そのままの範囲外の値を受け入れます。しかし、与えられた型はそれを表すことができないので、数値として持続しません。

つまり、定義された xsd:byte 値の範囲外の値であっても Neptune は "999"^^xsd:byte を受け入れます。ただし、値がデータベースで永続化されると、3 重パターンのオブジェクト位置で、完全一致セマンティクスでのみ使用できます。範囲外のリテラルは数値として扱われないため、範囲フィルターは実行できません。

SPARQL 1.1 仕様では、numeric-operatornumeric、string-operatorstring、literal-operatorliteralなどの範囲演算子フォームに定義します。Neptune はinvalid-literal-operator-numeric-valueなどの範囲比較演算子を実行できません。