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.
# Einhaltung von SPARQL-Standards in Amazon Neptune
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.
**Topics**
+ [Geltende Standards für SPARQL](#feature-sparql-applicable-standards)
+ [Standardpräfixe für Namespaces in Neptune SPARQL](#sparql-default-prefixes)
+ [SPARQL-Standard-Graph und benannte Graphen](#sparql-default-graph)
+ [Von Neptune unterstützte XPath SPARQL-Konstruktorfunktionen](#access-graph-sparql-xpath-constructors)
+ [Standard-Basis-IRI für Abfragen und Updates](#opencypher-compliance-default-iri)
+ [xsd:dateTime Werte in Neptune](#access-graph-sparql-xsd-date-time)
+ [Behandlung spezieller Gleitkommawerte in Neptune](#feature-overview-special-values-comparisons)
+ [Begrenzung von Werten beliebiger Länge in Neptune](#feature-overview-arbitrary-length-values)
+ [Neptune erweitert den Equals-Vergleich in SPARQL](#feature-overview-sparql-not-equal)
+ [Umgang mit Out-of-Range Literalen in Neptune SPARQL](#feature-overview-sparql-out-of-range)
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](https://www.w3.org/TR/sparql11-query/) vom 21. März 2013 definiert.
+ Das SPARQL-Update-Protokoll und die Abfragesprache werden durch die W3C [SPARQL 1.1-Update](https://www.w3.org/TR/sparql11-update/)-Spezifikation definiert.
+ Für numerische Formate folgt SPARQL den in [W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes](https://www.w3.org/TR/xmlschema11-2/) beschriebenen Spezifikationen, die mit der IEEE 754-Spezifikation ([IEEE 754-2019 – IEEE Standard for Floating-Point Arithmetic](https://standards.ieee.org/content/ieee-standards/en/standard/754-2019.html) konsistent sind. (Weitere Informationen finden Sie auch auf der [Wikipedia-Seite zu IEEE 754](https://en.wikipedia.org/wiki/IEEE_754)). Funktionen, die nach Version `IEEE 754-1985` eingefü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](https://www.w3.org/TR/sparql11-query/#prefNames) in der SPARQL-Spezifikation.
+ `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](https://www.w3.org/TR/sparql11-query/#rdfDataset)-Abschnitt der Query Language SPARQL 1.1-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 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](load-api-reference-load.md).
**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:boolean`
+ `xsd:integer`
+ `xsd:double`
+ `xsd:float`
+ `xsd:decimal`
+ `xsd:long`
+ `xsd: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](engine-releases-1.2.1.0.md) 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
INSERT DATA { "n1" }
BASE
SELECT * { ?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 { "n1" }
SELECT * { ?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 date/time Werte immer als koordinierte Weltzeit (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-Spezifikation](https://www.w3.org/TR/xmlschema-2/#double) 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).
### 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](https://www.w3.org/TR/sparql11-query/#func-RDFterm-equal) definiert), die für die Vergleiche `=` und `!=` in `FILTER`-Bedingungen gilt, erzeugt einen `error` beim Vergleich von Datentypen, die in der [Operatoren-Tabelle](https://www.w3.org/TR/sparql11-query/#OperatorMapping) nicht explizit vergleichbar sind.
Dieses Verhalten kann zu Ergebnissen, wie im folgenden Beispiel, führen, die nicht intuitiv sind.
Daten:
```
"127.0.0.1"^^
```
Abfrage 1:
```
SELECT * WHERE {
?o .
FILTER(?o = "127.0.0.2"^^)
}
```
Abfrage 2:
```
SELECT * WHERE {
?o .
FILTER(?o != "127.0.0.2"^^)
}
```
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"^^` bei der Auswertung für `?o := "127.0.0.1"^^` einen `error` statt `false` erzeugt, weil keine expliziten Vergleichsregeln für den benutzerdefinierten Datentyp `` 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](https://www.w3.org/TR/sparql11-query/#operatorExtensibility), in dem Engines zusätzliche Regeln für den Vergleich zwischen benutzerdefinierten und nicht vergleichbaren integrierten Datentypen definieren können.
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"^^` 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 \$1127. 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](https://www.w3.org/TR/sparql11-query/#OperatorMapping) im Format `numeric`*-Operator-*`numeric`, `string`*-Operator-*`string`, `literal`*-Operator-*`literal` usw. Neptune kann keine Bereichsvergleichsoperatoren wie `invalid-literal`*-operator-*`numeric-value` ausführen.