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

Amazon Neptune での SPARQL 標準コンプライアンス

該当する SPARQL 標準を一覧表示した後、以下のセクションでは、Neptune の SPARQL 実装がそれらの標準を拡張または逸脱する方法に関する具体的な詳細を提供します。

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

SPARQL に適用される標準

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

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

SPARQL のデフォルトグラフと名前付きグラフ

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

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

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

SELECT * WHERE { ?s ?p ?o }

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

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

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

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

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

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

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

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

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

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

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

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

次のリクエストでは、基本 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 の特殊な浮動小数点値を次のように処理します。

Neptune での SPARQL NaN 処理

Neptune では、SPARQL はクエリNaNで の値を受け入れることができます。シグナルおよびクワイエットの NaN 値は区別されません。Neptune は、すべての NaN 値をクワイエットとして扱います。

NaN より大きい、より小さい、または等しいものは何もないため、NaN の比較はできません。つまり、比較の一方の NaN の値は、比較の他方のいずれの値とも一致しません。

ただし、XSD 仕様では、2 つの xsd:doubleまたは xsd:floatNaNの値は等しいものとして扱われます。Neptune は、IN フィルター、フィルター式の等号演算子、完全一致セマンティクス (トリプルパターンのオブジェクト位置の NaN にある) についてはこれに従います。

Neptune でのSPARQLの無限値処理

Neptune では、SPARQL はクエリ-INFで INFまたは の値を受け入れることができます。 は他の任意の数値よりも大きい値INFとして比較し、 は他の任意の数値よりも小さい値として-INF比較します。

符号が一致する 2 つの INF 値は、その型に関係なく互いに等しく比較されます (例えば、浮動小数点は二重 と等しく-INF比較されます-INF）。

NaN より大きい、より小さい、等しいものは何もないため、当然ながら NaN の比較はできません。

Neptune でのSPARQLの負のゼロ処理

Neptune は、負のゼロ値を符号なしゼロに正規化します。負のゼロ値はクエリで使用できますが、データベースにはそのように記録されず、符号なしゼロと等しいと見なされます。

Neptune での任意長の値の制限

Neptune は、XSD 整数、浮動小数点、および Word の SPARQL0 進値のストレージサイズを 64 ビットに制限します。より大きい値を使用すると、InvalidNumericDataException エラーが発生します。

Neptune がSPARQLで等価比較を拡張

SPARQL 標準は、値式が 、、falseまたは に評価できる値式の 3 true項ロジックを定義します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 Out-of-Range でのSPARQLリテラルの処理

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

タイプの値空間の外部にリテラル値を割り当てる場合 (たとえば、 xsd:byteをリテラル値 999 に設定しようとする場合）、Neptune は out-of-range 値を丸めたり切り捨てたりすることなくそのまま受け入れます。しかし、与えられた型はそれを表すことができないので、数値として持続しません。

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

SPARQL 1.1 仕様では、範囲演算子を numeric-operator-numeric、string-operatorstring-、literal-operator-literal などの形式で定義しています。Neptune はinvalid-literal-operator-numeric-valueなどの範囲比較演算子を実行できません。