Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Conformité d'Amazon Neptune avec les normes SPARQL
Après avoir répertorié les normes SPARQL applicables, les sections suivantes fournissent des détails spécifiques sur la manière dont l'implémentation SPARQL de Neptune étend ces normes ou diverge de celles-ci.
**Topics**
+ [
## Normes applicables pour SPARQL
](#feature-sparql-applicable-standards)
+ [
## Préfixes d'espace de noms par défaut dans Neptune SPARQL
](#sparql-default-prefixes)
+ [
## Graphe par défaut SPARQL et graphes nommés
](#sparql-default-graph)
+ [
## Fonctions du XPath constructeur SPARQL prises en charge par Neptune
](#access-graph-sparql-xpath-constructors)
+ [
## IRI de base par défaut pour les requêtes et les mises à jour
](#opencypher-compliance-default-iri)
+ [
## Valeurs xsd:dateTime dans Neptune
](#access-graph-sparql-xsd-date-time)
+ [
## Traitement des valeurs spéciales à virgule flottante par Neptune
](#feature-overview-special-values-comparisons)
+ [
## Limite Neptune des valeurs de longueur arbitraire
](#feature-overview-arbitrary-length-values)
+ [
## Neptune étend la comparaison Equals dans SPARQL
](#feature-overview-sparql-not-equal)
+ [
## Gestion des Out-of-Range littéraux dans Neptune SPARQL
](#feature-overview-sparql-out-of-range)
Amazon Neptune est conforme avec les normes suivantes lors de l'implémentation du langage de requête de graphe SPARQL.
## Normes applicables pour SPARQL
+ SPARQL est défini par la recommandation du W3C [SPARQL 1.1 Query Language](https://www.w3.org/TR/sparql11-query/) du 21 mars 2013.
+ Le protocole de mise à jour SPARQL et le langage de requête sont définis par la spécification W3C [SPARQL 1.1 Update](https://www.w3.org/TR/sparql11-update/).
+ Pour les formats numériques, SPARQL suit la spécification [XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes](https://www.w3.org/TR/xmlschema11-2/) du W3C qui est compatible avec la spécification IEEE 754 ([IEEE 754-2019 - IEEE Standard for Floating-Point Arithmetic](https://standards.ieee.org/content/ieee-standards/en/standard/754-2019.html) ; voir aussi la [page Wikipedia sur IEEE 754](https://en.wikipedia.org/wiki/IEEE_754)). Toutefois, les fonctionnalités introduites après la version `IEEE 754-1985` ne sont pas incluses dans la spécification.
## Préfixes d'espace de noms par défaut dans Neptune SPARQL
Neptune définit les préfixes suivants par défaut à utiliser dans les requêtes SPARQL. Pour plus d'informations, consultez [Noms préfixés](https://www.w3.org/TR/sparql11-query/#prefNames) dans la spécification 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#`
## Graphe par défaut SPARQL et graphes nommés
Amazon Neptune associe chaque triplet à un graphe nommé. Le graphe par défaut est défini comme l'union de tous les graphes nommés.
**Graphe par défaut pour les requêtes**
Si vous envoyez une requête SPARQL sans spécifier explicitement un graphe via le mot-clé `GRAPH` ou des constructions telles que `FROM NAMED`, Neptune prend toujours en compte tous les triplets dans votre instance de base de données. Par exemple, la requête suivante renvoie tous les triplets à partir d'un point de terminaison Neptune SPARQL :
`SELECT * WHERE { ?s ?p ?o }`
Les triplets qui apparaissent dans plusieurs graphes ne sont renvoyés qu'une seule fois.
Pour plus d'informations sur la spécification du graphe par défaut, consultez la section [RDF Dataset](https://www.w3.org/TR/sparql11-query/#rdfDataset) dans la spécification de langage de requête SPARQL 1.1.
**Spécification du graphe nommé pour le chargement, les insertions ou les mises à jour**
Si vous ne spécifiez pas un graphe nommé lors du chargement, de l'insertion ou de la mise à jour de triplets, Neptune utilise le graphe nommé de secours défini par l'URI `http://aws.amazon.com/neptune/vocab/v01/DefaultNamedGraph`.
Lorsque vous envoyez une demande `Load` Neptune à l'aide d'un format basé sur les triplets, vous pouvez spécifier le graphe nommé à utiliser pour tous les triplets à l'aide du paramètre `parserConfiguration: namedGraphUri`. Pour plus d'informations sur la syntaxe de la commande `Load`, consultez [Commande de chargeur Neptune](load-api-reference-load.md).
**Important**
Si vous n'utilisez pas ce paramètre, et que vous ne spécifiez pas un graphe nommé, l'URI de secours est utilisé : `http://aws.amazon.com/neptune/vocab/v01/DefaultNamedGraph`.
Ce graphe nommé de secours est également utilisé si vous chargez des triplets via `SPARQL UPDATE` sans fournir explicitement une cible de graphe nommé.
Vous pouvez utiliser le format basé sur les quadrilatères NQuads afin de spécifier un graphe nommé pour chaque triplet de la base de données.
**Note**
L'utilisation de NQuads vous permet de laisser vide le graphe nommé. Dans ce cas, `http://aws.amazon.com/neptune/vocab/v01/DefaultNamedGraph` est utilisé.
Vous pouvez remplacer le graphe nommé par défaut pour NQuads à l'aide de l'option de configuration de l'analyseur `namedGraphUri`.
## Fonctions du XPath constructeur SPARQL prises en charge par Neptune
La norme SPARQL permet aux moteurs SPARQL de prendre en charge un ensemble extensible de fonctions de XPath constructeur. Neptune prend actuellement en charge les fonctions de constructeur suivantes, dont le préfixe `xsd` est défini comme `http://www.w3.org/2001/XMLSchema#` :
+ `xsd:boolean`
+ `xsd:integer`
+ `xsd:double`
+ `xsd:float`
+ `xsd:decimal`
+ `xsd:long`
+ `xsd:unsignedLong`
## IRI de base par défaut pour les requêtes et les mises à jour
Comme un cluster Neptune possède plusieurs points de terminaison différents, l'utilisation de l'URL de demande d'une requête ou d'une mise à jour comme IRI de base peut entraîner des résultats inattendus lors de la résolution relative. IRIs
Depuis la [version 1.2.1.0 du moteur](engine-releases-1.2.1.0.md), Neptune utilise `http://aws.amazon.com/neptune/default/` comme IRI de base si aucun IRI de base explicite ne fait partie de la demande.
Dans la demande suivante, l'IRI de base fait partie de la demande :
```
BASE
INSERT DATA { "n1" }
BASE
SELECT * { ?p ?o }
```
Le résultat serait le suivant :
```
?p ?o
http://example.org/default/id n1
```
En revanche, dans cette demande, aucun IRI de base n'est inclus :
```
INSERT DATA { "n1" }
SELECT * { ?p ?o }
```
Dans ce cas, le résultat serait :
```
?p ?o
http://aws.amazon.com/neptune/default/id n1
```
## Valeurs xsd:dateTime dans Neptune
Pour des raisons de performance, Neptune stocke toujours les date/time valeurs en temps universel coordonné (UTC). Cela rend les comparaisons directes très efficaces.
Cela signifie également que si vous entrez une valeur `dateTime` spécifiant un fuseau horaire particulier, Neptune convertit cette valeur en UTC et rejette ces informations de fuseau horaire. Ensuite, lorsque vous récupérez la valeur `dateTime` ultérieurement, elle est exprimée en UTC, et non en heure du fuseau horaire d'origine, et vous ne pouvez plus savoir quel était ce fuseau horaire d'origine.
## Traitement des valeurs spéciales à virgule flottante par Neptune
Neptune traite les valeurs spéciales à virgule flottante dans SPARQL comme suit :
### Gestion des valeurs NaN SPARQL dans Neptune
Dans Neptune, SPARQL peut accepter une valeur `NaN` dans une requête. Aucune distinction n'est faite entre les valeurs `NaN` de signalisation et silencieuses. Neptune considère toutes les valeurs `NaN` comme étant silencieuses.
D'un point de vue sémantique, aucune comparaison d'une valeur `NaN` n'est possible, car aucune valeur n'est supérieure, inférieure ou égale à une valeur `NaN`. Cela signifie qu'une valeur `NaN` d'un côté d'une comparaison ne correspond jamais à *quoi que ce soit* de l'autre côté.
Cependant, la [spécification XSD](https://www.w3.org/TR/xmlschema-2/#double) traite deux valeurs `NaN` `xsd:double` ou `xsd:float` comme égales. Neptune respecte ce principe pour le filtre `IN`, pour l'opérateur égal dans les expressions de filtre, et pour la sémantique de correspondance exacte (ayant un élément `NaN` dans la position de l'objet d'un modèle triple).
### Traitement des valeurs infinies SPARQL dans Neptune
Dans Neptune, SPARQL peut accepter une valeur `INF` ou `-INF` dans une requête. Une valeur `INF` est comparée comme étant supérieure à toute autre valeur numérique, et une valeur `-INF` est comparée comme étant inférieure à toute autre valeur numérique.
Deux valeurs INF avec des signes correspondants sont égales l'une à l'autre quel que soit leur type (par exemple, un nombre à virgule flottante `-INF` est égal à un double `-INF`).
Bien sûr, aucune comparaison avec une valeur `NaN` n'est possible, car aucune valeur n'est supérieure, inférieure ou égale à une valeur `NaN`.
### Traitement du zéro négatif SPARQL dans Neptune
Neptune normalise une valeur de zéro négatif en un zéro non signé. Des valeurs nulles négatives peuvent être utilisées dans une requête, mais elles ne sont pas enregistrées en tant que telles dans la base de données et elles sont comparées comme étant égales à des zéros non signés.
## Limite Neptune des valeurs de longueur arbitraire
Neptune limite à 64 bits la taille de stockage des valeurs entières, à virgule flottante et décimales XSD dans SPARQL. L'utilisation de valeurs plus grandes génère une erreur `InvalidNumericDataException`.
## Neptune étend la comparaison Equals dans SPARQL
La norme SPARQL définit une logique ternaire pour les expressions de valeur, dans lesquelles une expression de valeur peut être évaluée à `true`, `false` ou `error`. La sémantique par défaut pour l'égalité des termes telle que définie dans la [spécification SPARQL 1.1](https://www.w3.org/TR/sparql11-query/#func-RDFterm-equal), qui s'applique aux comparaisons `=` et `!=` dans des conditions `FILTER` génère une `error` lors de la comparaison de types de données qui ne sont pas comparables explicitement dans la [table des opérateurs](https://www.w3.org/TR/sparql11-query/#OperatorMapping) dans la spécification.
Ce comportement peut entraîner des résultats non intuitifs, comme dans l'exemple suivant.
Données :
```
"127.0.0.1"^^
```
Requête 1 :
```
SELECT * WHERE {
?o .
FILTER(?o = "127.0.0.2"^^)
}
```
Requête 2 :
```
SELECT * WHERE {
?o .
FILTER(?o != "127.0.0.2"^^)
}
```
Avec la sémantique SPARQL par défaut utilisée par Neptune avant la version 1.0.2.1, les deux requêtes renvoyaient le résultat vide. En effet, `?o = "127.0.0.2"^^`, lorsqu'il est évalué pour `?o := "127.0.0.1"^^`, génère le résultat `error` plutôt que `false`, car aucune règle de comparaison explicite n'est spécifiée pour le type de données personnalisé ``. Par conséquent, la version négative dans la deuxième requête produit également une `error`. Dans les deux requêtes, `error` provoque le filtrage de la solution candidate.
À partir de la version 1.0.2.1, Neptune a étendu l'opérateur d'inégalité SPARQL conformément à la spécification. Consultez la [section SPARQL 1.1 sur l'extensibilité de l'opérateur](https://www.w3.org/TR/sparql11-query/#operatorExtensibility), qui permet aux moteurs de définir des règles supplémentaires sur la façon d'effectuer une comparaison entre des types de données intégrés définis par l'utilisateur et non comparables.
En utilisant cette option, Neptune traite désormais une comparaison de deux types de données qui n'est pas explicitement définie dans la table de mappage des opérateurs comme prenant la valeur `true` si les valeurs littérales et les types de données sont égaux d'un point de vue syntaxique, ou comme prenant la valeur false dans le cas contraire. Un `error` n'est en aucun cas produit.
En utilisant ces nouvelles sémantiques, la deuxième requête renverrait `"127.0.0.1"^^` au lieu d'un résultat vide.
## Gestion des Out-of-Range littéraux dans Neptune SPARQL
La sémantique XSD définit chaque type numérique avec son espace de valeurs, à l'exception de `integer` et `decimal`. Ces définitions limitent chaque type à une plage de valeurs. Par exemple, la plage d'une plage `xsd:byte` est comprise entre -128 et \$1127, inclusivement. Toute valeur en dehors de cette plage est considérée comme non valide.
Si vous essayez d'attribuer une valeur littérale en dehors de l'espace des valeurs d'un type (par exemple, si vous essayez de définir an `xsd:byte` sur une valeur littérale de 999), Neptune accepte la out-of-range valeur telle quelle, sans l'arrondir ni la tronquer. Mais il ne le persiste pas en tant que valeur numérique car le type donné ne peut pas le représenter.
Autrement dit, Neptune accepte `"999"^^xsd:byte` même s'il s'agit d'une valeur qui se trouve en dehors de la plage de valeurs `xsd:byte` définie. Cependant, une fois la valeur conservée dans la base de données, elle ne peut être utilisée que dans la sémantique de correspondance exacte, dans une position d'objet d'un motif triple. Aucun filtre de plage ne peut y être exécuté car out-of-range les littéraux ne sont pas traités comme des valeurs numériques.
La spécification SPARQL 1.1 définit les [opérateurs de plage](https://www.w3.org/TR/sparql11-query/#OperatorMapping) sous la forme `numeric` *-operator-*`numeric`, `string` *-operator-*`string`, `literal`*-operator-*`literal`, etc. Neptune ne peut pas exécuter un opérateur de comparaison de plages tel que `invalid-literal`*-operator-*`numeric-value`.