SPARQL Amazon Neptune 中的標準合規 - Amazon Neptune
SPARQL 適用標準預設命名空間前置詞預設和具名圖表Neptune XPath 建構器查詢IRI的基礎xsd：dateTime特殊浮點值任意長度值等於行為Out-of-Range 文學

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

SPARQL Amazon Neptune 中的標準合規

列出適用SPARQL標準後，以下各節提供 Neptune SPARQL實作如何延伸或偏離這些標準的具體詳細資訊。

Amazon Neptune 在實作SPARQL圖形查詢語言時符合下列標準。

適用的標準 SPARQL

Neptune 中的預設命名空間字首 SPARQL

Neptune 預設會定義下列字首，以便在SPARQL查詢中使用。如需詳細資訊，請參閱 SPARQL規格中的字首名稱。

  • 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 會將每個三元組與一個具名圖形建立關聯。預設圖形是定義成所有具名圖形的聯集。

查詢的預設圖形

如果您提交SPARQL查詢時未透過GRAPH關鍵字或建構明確指定圖形，例如 FROM NAMED，Neptune 一律會考慮資料庫執行個體中的所有三倍。例如，下列查詢會從 Neptune SPARQL端點傳回所有三倍：

SELECT * WHERE { ?s ?p ?o }

顯現於多個圖形中的三元組將僅傳回一次。

如需預設圖形規格的相關資訊，請參閱 1.1 Query Language SPARQL 規格的RDF資料集一節。

指定具名圖形以進行載入、插入或更新

如果您在載入、插入或更新三元時未指定具名圖表，Neptune URI 會使用 定義的具名圖表。 http://aws.amazon.com/neptune/vocab/v01/DefaultNamedGraph

當您使用三元組類型的格式發出 Neptune Load 請求時，可使用 parserConfiguration: namedGraphUri 參數指定具名圖形以用於所有三元組。如需 Load 命令語法的相關資訊，請參閱 Neptune 載入器命令。

重要

如果您不使用此參數，且未指定具名圖形，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 的預設具名圖形。

SPARQL XPath Neptune 支援的建構器函數

此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可能會導致非預期的結果IRIs。

自引擎版本 1.2.1.0 起，IRI如果明確基礎IRI不屬於請求的一部分，Neptune 會使用 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 Values

基於效能原因，Neptune 一律將日期/時間值儲存為國際標準時間 （UTC）。這能讓直接比較很有效率。

這也表示如果您輸入指定特定時區dateTime的值，Neptune 會將該值轉譯為 ，UTC並捨棄該時區資訊。然後，當您稍後擷取該dateTime值時，它會以 表示UTC，而不是原始時區的時間，而且您無法再知道原始時區是什麼。

特殊浮點值的 Neptune 處理

Neptune 會處理 中的特殊浮點值SPARQL，如下所示。

SPARQL Neptune 中的 NaN 處理

在 Neptune 中， SPARQL可接受查詢NaN中的 值。signalling 和 quiet NaN 值之間沒有任何區別。Neptune 會將所有 NaN 值視為 quiet。

在語意上，不可能進行 NaN 的比較，因為沒有任何值大於、小於或等於 NaN。這表示理論上，比較一端的 NaN 值和另一端的「任何內容」永遠不相符。

不過，XSD規格確實將兩個 xsd:double 或 xsd:floatNaN值視為相等。對於 IN 篩選條件、篩選條件表達式的等於運算子，以及完全相符語義 (在三重模式的物件位置中具有 NaN)，Neptune 皆遵循此原則。

SPARQL Neptune 中的無限價值處理

在 Neptune 中， SPARQL可接受查詢-INF中 INF或 的值。 INF會比較為大於任何其他數值，而 會-INF比較為小於任何其他數值。

兩個具有相符符號INF的值會相互比較為等於，無論其類型為何 （例如，浮點數會-INF比較為等於雙 -INF）。

當然，因為沒有任何值大於、小於或等於 NaN，所以不可能和 NaN 比較。

SPARQL Neptune 中的負零處理

Neptune 會將負零值標準化為不帶正負號的零。負零值可用於查詢中，但不會原樣記錄在資料庫中，而且不等於不帶正負號的零。

Neptune 任意長度值的限制

Neptune 會將XSD整數、浮點和小數值的儲存大小限制SPARQL為 64 位元。使用較大的值會導致 InvalidNumericDataException 錯誤。

Neptune 擴展 中的相等比較 SPARQL

SPARQL 標準會定義值表達式的三元邏輯，其中值表達式可以評估為 true、 false或 error。1SPARQL.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 SPARQL 1.0.2.1 版之前使用的預設語義，兩個查詢都會傳回空白結果。原因是 ?o = "127.0.0.2"^^<http://example.com/IPAddress> 在評估 ?o := "127.0.0.1"^^<http://example.com/IPAddress> 時會產生 error，而不是 false，因為沒有為自訂資料類型 <http://example.com/IPAddress> 指定明確的比較規則。因此，第二個查詢中的否定版本也會產生 error。在這兩個查詢中，error 會導致篩選出候選解決方案。

從 1.0.2.1 版開始，Neptune 已根據規格擴充SPARQL不等式運算子。請參閱SPARQL運算子擴充性 的 1.1 章節，這可讓引擎定義其他規則，以了解如何在使用者定義和無法比較的內建資料類型之間進行比較。

使用此選項，如果常值和資料類型在語法上相等，則 Neptune 會立即將在運算子對應表中未明確定義的任何兩個資料類型的比較視同評估為 true，否則為 false。任何情況下都不會發生 error。

使用這些新的語意，第二個查詢就會傳回 "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值，而不會四捨五入或截斷該值。但因為指定的類型不能代表此值，所以不會保存為數值。

也就是說，即使 "999"^^xsd:byte 是已定義之 xsd:byte 值範圍外的值，Neptune 也會接受它。但是，在資料庫中保存該值之後，此值只能用於三重模式物件位置的完全相符語義。無法執行範圍篩選條件，因為 out-of-range常值不會被視為數值。

1.1 SPARQL 規格以 numeric-operator-numeric、string-operator-string、literal-operator-literal 等格式定義範圍運算子。Neptune 無法執行如 invalid-literal-operator-numeric-value 之類的範圍比較運算子。