本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
SPARQL Amazon Neptune 中的標準合規
列出適用SPARQL標準之後,以下各節提供 Neptune SPARQL實作如何延伸或偏離這些標準的具體詳細資訊。
主題
Amazon Neptune 在實作SPARQL圖形查詢語言時符合下列標準。
適用的標準 SPARQL
SPARQL 是由 2013 年 3 月 21 日 W3C SPARQL 1.1 查詢語言
建議所定義。 SPARQL 更新通訊協定和查詢語言由 W3C SPARQL 1.1 更新
規格定義。 對於數字格式,SPARQL請遵循 W3C XML 結構描述定義語言 (XSD) 1.1 第 2 部分:資料類型
規格,其與 IEEE 754 規格一致 (IEEE 754-2019 - Floating-Point Arithmetic IEEE標準 。 如需詳細資訊,另請參閱 Wikipedia IEEE 754 第 頁 )。不過,此規格不包含於 IEEE 754-1985
版本後引入的功能。
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 值
基於效能原因,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:float
NaN
值視為相等。對於 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 1.0.2.1 版之前使用的預設SPARQL語義,兩個查詢都會傳回空白結果。原因是 ?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
等格式定義範圍運算invalid-literal
-operator-numeric-value
之類的範圍比較運算子。