Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Nach der Auflistung der geltenden SPARQL-Standards enthalten die folgenden Abschnitte spezifische Informationen dazu, wie die SPARQL-Implementierung von Neptune diese Standards erweitert oder von ihnen abweicht.
Themen
Amazon Neptune erfüllt bei der Implementierung der SPARQL-Diagrammabfragensprache die folgenden Standards.
Geltende Standards für SPARQL
SPARQL wird vom W3C in der Empfehlung SPARQL 1.1 Query Language
vom 21. März 2013 definiert. Das SPARQL-Update-Protokoll und die Abfragesprache werden durch die W3C SPARQL 1.1-Update
-Spezifikation definiert. Für numerische Formate folgt SPARQL den in W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes
beschriebenen Spezifikationen, die mit der IEEE 754-Spezifikation (IEEE 754-2019 – IEEE Standard for Floating-Point Arithmetic konsistent sind. (Weitere Informationen finden Sie auch auf der Wikipedia-Seite zu IEEE 754 ). Funktionen, die nach Version IEEE 754-1985eingeführt wurden, sind in der Spezifikation jedoch nicht enthalten.
Standardpräfixe für Namespaces in Neptune SPARQL
Neptune definiert standardmäßig die folgenden Präfixe für die Verwendung in SPARQL-Abfragen. Weitere Informationen finden Sie unter Präfixnamen
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-Standard-Graph und benannte Graphen
Amazon Neptune ordnet jedem Triple einen benannten Graphen zu. Der Standard-Graph ist als die Vereinigung aller benannten Graphen definiert.
Standard-Graph für Abfragen
Wenn Sie eine SPARQL-Anfrage absenden, ohne ausdrücklich einen Graphen über das GRAPH-Schlüsselwort oder Konstrukte wie FROM NAMED anzugeben, berücksichtigt Neptune stets alle Triples in Ihrer DB-Instance. Die folgende Abfrage gibt beispielsweise alle Triples von einem Neptune-SPARQL-Endpunkt zurück:
SELECT * WHERE { ?s ?p ?o }
Triples, die in mehr als einem Graphen vorhanden sind, werden nur einmal zurückgegeben.
Weitere Informationen über die Standard-Graph-Spezifikation finden Sie im RDF-Dataset
Angeben des benannten Graphen für Ladevorgänge, Einfügungen oder Updates
Wenn Sie beim Laden, Einfügen oder Aktualisieren von Triples keinen benannten Graphen angeben, verwendet Neptune den benannten Fallback-Graphen, der durch die URI http://aws.amazon.com/neptune/vocab/v01/DefaultNamedGraph definiert ist.
Wenn Sie eine Neptune-Load-Anforderung in einem Triple-basierten Format ausgeben, können Sie mit dem Parameter parserConfiguration:
namedGraphUri angeben, dass der genannte Graph für alle Triples verwendet werden soll. Weitere Informationen zur Load-Befehlssyntax finden Sie unter Neptune-Loader-Befehl.
Wichtig
Wenn Sie diesen Parameter nicht benutzen und keinen benannten Graphen angeben, wird die Fallback-URI verwendet: http://aws.amazon.com/neptune/vocab/v01/DefaultNamedGraph.
Dieser benannte Fallback-Graph wird auch verwendet, wenn Sie Triples über SPARQL
UPDATE laden, ohne ausdrücklich einen benannten Ziel-Graphen anzugeben.
Sie können das Quads-basierte Format N-Quads verwenden, um einen benannten Graphen für jedes Triple in der Datenbank anzugeben.
Anmerkung
N-Quads erlaubt es, das Feld für den benannten Graphen leer zu lassen. In diesem Fall wird http://aws.amazon.com/neptune/vocab/v01/DefaultNamedGraph verwendet.
Sie können den standardmäßigen benannten Graphen für N-Quads überschreiben, indem Sie die Parser-Konfigurationsoption namedGraphUri verwenden.
Von Neptune unterstützte XPath SPARQL-Konstruktorfunktionen
Der SPARQL-Standard ermöglicht SPARQL-Engines die Unterstützung eines erweiterbaren Satzes von Konstruktorfunktionen. XPath Neptune unterstützt zurzeit die folgenden Konstruktorfunktionen, wobei das xsd-Präfix als http://www.w3.org/2001/XMLSchema# definiert ist:
xsd:booleanxsd:integerxsd:doublexsd:floatxsd:decimalxsd:longxsd:unsignedLong
Standard-Basis-IRI für Abfragen und Updates
Da ein Neptune-Cluster über mehrere verschiedene Endpunkte verfügt, kann die Verwendung der Anforderungs-URL einer Abfrage oder eines Updates als Basis-IRI zu unerwarteten Ergebnissen bei der Auflösung relativer Daten führen. IRIs
Ab Engine-Version 1.2.1.0 verwendet Neptune http://aws.amazon.com/neptune/default/ als Basis-IRI, wenn kein expliziter Basis-IRI Teil der Anforderung ist.
In der folgenden Anforderung ist der Basis-IRI Teil der Anforderung:
BASE <http://example.org/default/> INSERT DATA { <node1> <id> "n1" } BASE <http://example.org/default/> SELECT * { <node1> ?p ?o }
Das Ergebnis wäre:
?p ?o http://example.org/default/id n1
In dieser Anforderung ist jedoch kein Basis-IRI enthalten:
INSERT DATA { <node1> <id> "n1" } SELECT * { <node1> ?p ?o }
In diesem Fall wäre das Ergebnis:
?p ?o http://aws.amazon.com/neptune/default/id n1
xsd:dateTime Werte in Neptune
Aus Performance-Gründen speichert Neptune Datums-/Uhrzeitwerte stets als Coordinated Universal Time (UTC). Dies macht direkte Vergleiche sehr effizient.
Es bedeutet auch, dass Neptune den Wert in UTC übersetzt und die Zeitzoneninformationen verwirft, wenn Sie einen dateTime-Wert eingeben, der eine bestimmte Zeitzone angibt. Wenn Sie den dateTime-Wert später abrufen, wird er in UTC ausgedrückt, nicht in der Zeit der ursprünglichen Zeitzone, und Sie können nicht mehr erkennen, was die ursprüngliche Zeitzone war.
Behandlung spezieller Gleitkommawerte in Neptune
Neptune behandelt spezielle Gleitkommawerte in SPARQL wie folgt.
SPARQL-NaN-Behandlung in Neptune
SPARQL kann in Neptune einen Wert von NaN in einer Abfrage akzeptieren. Es gibt keine Unterscheidung zwischen signalisierenden und stillen NaN-Werten. Neptune behandelt alle NaN-Werte als stille Werte.
Semantisch ist kein Vergleich mit einem NaN-Wert möglich, da nichts größer als, kleiner als oder gleich einem NaN-Wert ist. Das bedeutet, dass ein Wert von NaN auf der einen Seite eines Vergleichs theoretisch mit nichts auf der anderen Seite übereinstimmen kann.
Die XSD-Spezifikationxsd:double- oder xsd:float-NaNWerte als gleich. Neptune folgt dem für den Filter IN, für den Gleichheiteroperator in Filterausdrücken und für die exakte Übereinstimmungssemantik (mit einem NaN-Wert in der Objektposition eines Triple-Musters).
Behandlung unendlicher SPARQL-Werte in Neptune
SPARQL kann in Neptune einen Wert von -INF oder INF in einer Abfrage akzeptieren. INF ist in Vergleichen größer als jeder andere numerische Wert; -INF ist in Vergleichen kleiner als jeder andere numerische Wert.
Zwei INF-Werte mit übereinstimmenden Vorzeichen werden unabhängig vom Typ als gleich behandelt (z. B. gilt ein Float--INF als gleich einem Double--INF).
Selbstverständlich ist mit NaN kein Vergleich möglich, denn nichts ist größer, kleiner oder gleich NaN.
Behandlung einer negativen SPARQL-Null in Neptune
Neptune normalisiert einen negativen Nullwert zu einer Null ohne Vorzeichen. Sie können negative Nullwerte in einer Abfrage verwenden. Sie werden jedoch nicht als solche in der Datenbank aufgezeichnet und bei Vergleichen entsprechen sie Nullen ohne Vorzeichen.
Begrenzung von Werten beliebiger Länge in Neptune
Neptune begrenzt die Speichergröße von XSD-Ganzzahl-, Gleitkomma- und Dezimalwerten in SPARQL auf 64 Bit. Die Verwendung von größeren Werten führt zum Fehler InvalidNumericDataException.
Neptune erweitert den Equals-Vergleich in SPARQL
Der SPARQL-Standard definiert eine ternäre Logik für Wertausdrücke, wobei ein Wertausdruck als true, false oder error bewertet werden kann. Die Standardsemantik für Begriffsgleichheit (wie in der SPARQL 1.1-Spezifikation= und != in FILTER-Bedingungen gilt, erzeugt einen error beim Vergleich von Datentypen, die in der Operatoren-Tabelle
Dieses Verhalten kann zu Ergebnissen, wie im folgenden Beispiel, führen, die nicht intuitiv sind.
Daten:
<http://example.com/Server/1> <http://example.com/ip> "127.0.0.1"^^<http://example.com/datatype/IPAddress>
Abfrage 1:
SELECT * WHERE { <http://example.com/Server/1> <http://example.com/ip> ?o . FILTER(?o = "127.0.0.2"^^<http://example.com/datatype/IPAddress>) }
Abfrage 2:
SELECT * WHERE { <http://example.com/Server/1> <http://example.com/ip> ?o . FILTER(?o != "127.0.0.2"^^<http://example.com/datatype/IPAddress>) }
Mit der SPARQL-Standardsemantik, die Neptune vor Version 1.0.2.1 verwendet hat, würden beide Abfragen ein leeres Ergebnis zurückgeben. Der Grund hierfür ist, dass ?o =
"127.0.0.2"^^<http://example.com/IPAddress> bei der Auswertung für ?o :=
"127.0.0.1"^^<http://example.com/IPAddress> einen error statt false erzeugt, weil keine expliziten Vergleichsregeln für den benutzerdefinierten Datentyp <http://example.com/IPAddress> angegeben sind. Infolgedessen erzeugt die negierte Version in der zweiten Abfrage auch einen error. In beiden Abfragen bewirkt der error, dass die Kandidatenlösung herausgefiltert wird.
Ab Version 1.0.2.1 erweitert Neptune den SPARQL-Ungleichheitsoperator entsprechend der Spezifikation. Weitere Informationen finden Sie im Abschnitt von SPARQL 1.1 zur Operator-Erweiterbarkeit
Bei Verwendung dieser Option bewertet Neptune jetzt den Vergleich zwischen zwei in der Operator-Zuweisungstabelle nicht explizit definierten Datentypen als true, wenn die Literalwerte und Datentypen syntaktisch gleich sind. Andernfalls wird der Vergleich als „false“ bewertet. Ein error wird in keinem Fall erstellt.
Mit dieser neuen Semantik würde die zweite Abfrage "127.0.0.1"^^<http://example.com/IPAddress> anstelle eines leeren Ergebnisses zurückgeben.
Umgang mit Out-of-Range Literalen in Neptune SPARQL
Mit der XSD-Semantik wird jeder numerische Typ mit seinem Wertebereich definiert, abgesehen von integer und decimal. Diese Definitionen beschränken jeden Typ auf einen Wertebereich. Beispielsweise liegt der Umfang eines xsd:byte-Bereichs zwischen -128 und +127. Jeder Wert außerhalb dieses Bereichs gilt als ungültig.
Wenn Sie versuchen, einen Literalwert außerhalb des Werteraums eines Typs zuzuweisen (wenn Sie beispielsweise versuchen, an auf einen Literalwert von 999 xsd:byte zu setzen), akzeptiert Neptune den out-of-range Wert unverändert, ohne ihn zu runden oder zu kürzen. Allerdings bleibt der Wert nicht als numerischer Wert erhalten, da der angegebene Typ ihn nicht darstellen kann.
Das heißt, Neptune akzeptiert "999"^^xsd:byte, obwohl es sich um einen Wert außerhalb des definierten xsd:byte-Wertebereichs handelt. Nachdem der Wert jedoch in der Datenbank beibehalten wurde, kann er in der exakten Übereinstimmungssemantik nur in einer Objektposition eines dreifachen Musters verwendet werden. Darauf kann kein Bereichsfilter ausgeführt werden, da out-of-range Literale nicht als numerische Werte behandelt werden.
Die SPARQL 1.1-Spezifikation definiert Bereichsoperatorennumeric-Operator-numeric, string-Operator-string, literal-Operator-literal usw. Neptune kann keine Bereichsvergleichsoperatoren wie invalid-literal-operator-numeric-value ausführen.
