SPARQLEinhaltung von Standards in Amazon Neptune - Amazon Neptune
SPARQLAnwendbare NormenStandardpräfixe für NamespacesStandard-Graphen und benannte GraphenNeptun-Konstruktoren XPathBasis IRI für Abfragenxsd: dateTimeSpezielle GleitkommawerteWerte beliebiger LängeEquals-VerhaltenOut-of-Range Literale

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.

SPARQLEinhaltung von Standards in Amazon Neptune

Nach der Auflistung der geltenden SPARQL Standards finden Sie in den folgenden Abschnitten spezifische Informationen darüber, wie die SPARQL Implementierung von Neptune diese Standards erweitert oder von ihnen abweicht.

Amazon Neptune erfüllt bei der Implementierung der SPARQL Graph-Abfragesprache die folgenden Standards.

Anwendbare Standards für SPARQL

Standard-Namespace-Präfixe in Neptune SPARQL

Neptune definiert standardmäßig die folgenden Präfixe für die Verwendung in Abfragen. SPARQL Weitere Informationen finden Sie in der Spezifikation unter Namen mit Präfixen. 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#

SPARQLStandarddiagramm und benannte Grafiken

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 Abfrage einreichen, ohne explizit einen Graphen über das GRAPH Schlüsselwort oder Konstrukte wie anzugebenFROM NAMED, berücksichtigt Neptune immer alle Tripel in Ihrer DB-Instance. Die folgende Abfrage gibt beispielsweise alle Tripel von einem SPARQL Neptun-Endpunkt zurück:

SELECT * WHERE { ?s ?p ?o }

Triples, die in mehr als einem Graphen vorhanden sind, werden nur einmal zurückgegeben.

Informationen zur Standarddiagrammspezifikation finden Sie im Abschnitt RDFDatensatz der SPARQL 1.1 Query Language-Spezifikation.

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 durch den definierten Fallback namens graph. URI http://aws.amazon.com/neptune/vocab/v01/DefaultNamedGraph

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 verwenden und kein benanntes Diagramm angeben, wird das Fallback verwendet:. URI 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.

SPARQLXPathVon Neptune unterstützte Konstruktorfunktionen

Der SPARQL Standard ermöglicht es SPARQL Engines, einen erweiterbaren Satz von Konstruktorfunktionen zu unterstützen. XPath Neptune unterstützt zurzeit die folgenden Konstruktorfunktionen, wobei das xsd-Präfix als http://www.w3.org/2001/XMLSchema# definiert ist:

  • xsd:boolean

  • xsd:integer

  • xsd:double

  • xsd:float

  • xsd:decimal

  • xsd:long

  • xsd:unsignedLong

Standardbasis IRI für Abfragen und Updates

Da ein Neptun-Cluster über mehrere verschiedene Endpunkte verfügt, kann die Verwendung der Anfrage einer Abfrage oder URL eines Updates als Basis zu unerwarteten Ergebnissen bei der Auflösung relativer Daten IRI führen. IRIs

Ab Engine-Version 1.2.1.0 verwendet Neptune http://aws.amazon.com/neptune/default/ als Basis, IRI wenn eine explizite Basis nicht Teil der IRI Anfrage ist.

In der folgenden Anfrage IRI ist die Basis Teil der Anfrage:

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 Anfrage IRI ist jedoch keine Basis 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 Leistungsgründen speichert Neptune Datums-/Uhrzeitwerte immer als koordinierte Weltzeit (). UTC Dies macht direkte Vergleiche sehr effizient.

Das bedeutet auch, dass Neptune, wenn Sie einen dateTime Wert eingeben, der eine bestimmte Zeitzone angibt, den Wert in diese Zeitzoneninformationen übersetzt UTC und diese verwirft. Wenn Sie den dateTime Wert dann später abrufen, wird er in der Zeit der ursprünglichen Zeitzone ausgedrücktUTC, und Sie können nicht mehr erkennen, was diese ursprüngliche Zeitzone war.

Behandlung spezieller Gleitkommawerte in Neptune

Neptune behandelt spezielle Gleitkommawerte wie folgt. SPARQL

SPARQLUmgang mit NaN in Neptune

SPARQLKann 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 XSDSpezifikation behandelt jedoch zwei xsd:double oder xsd:float NaN Werte 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).

SPARQLUmgang mit unendlichen Werten in Neptune

SPARQLKann in Neptune einen Wert von INF oder -INF in einer Abfrage akzeptieren. INFvergleicht als größer als jeder andere numerische Wert und -INF vergleicht als kleiner als jeder andere numerische Wert.

Zwei INF Werte mit übereinstimmenden Vorzeichen werden unabhängig von ihrem Typ als gleichwertig verglichen (z. B. wird ein Gleitkommawert mit einem Doppelwert -INF verglichen-INF).

Selbstverständlich ist mit NaN kein Vergleich möglich, denn nichts ist größer, kleiner oder gleich NaN.

SPARQLBehandlung negativer Nullwerte 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-, Fließkomma- und Dezimalwerten SPARQL auf 64 Bit. Die Verwendung von größeren Werten führt zum Fehler InvalidNumericDataException.

Neptune Extends entspricht einem Vergleich in SPARQL

Der SPARQL Standard definiert eine ternäre Logik für Wertausdrücke, bei der ein Wertausdruck entweder als, oder ausgewertet werden kann. true false error Die Standardsemantik für Termgleichheit (wie in der SPARQL1.1-Spezifikation definiert), die für = und != Vergleiche FILTER unter Bedingungen gilt, erzeugt error beim Vergleich von Datentypen, die in der Tabelle mit Operatoren in der Spezifikation nicht explizit vergleichbar sind, ein.

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 das leere 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 hat Neptune den SPARQL Ungleichheitsoperator entsprechend der Spezifikation erweitert. Weitere Informationen finden Sie im Abschnitt SPARQL 1.1 zur Erweiterbarkeit von Operatoren, der es Engines ermöglicht, zusätzliche Regeln für den Vergleich zwischen benutzerdefinierten und nicht vergleichbaren integrierten Datentypen zu definieren.

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

XSDDie Semantik definiert jeden numerischen Typ mit seinem Wertebereich, mit Ausnahme integer von 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 Bereichsoperatoren in der Form numeric -Operator-numeric, string -Operator-string, literal -Operator- literal usw. Neptune kann keine Bereichsvergleichsoperatoren wie invalid-literal-operator-numeric-value ausführen.