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.
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.
Rubriques
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
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
. Pour les formats numériques, SPARQL suit la spécification XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes
du W3C qui est compatible avec la spécification IEEE 754 (IEEE 754-2019 - IEEE Standard for Floating-Point Arithmetic ; voir aussi la page Wikipedia sur IEEE 754 ). Toutefois, les fonctionnalités introduites après la version IEEE 754-1985ne 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
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
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.
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:booleanxsd:integerxsd:doublexsd:floatxsd:decimalxsd:longxsd: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, 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 <http://example.org/default/> INSERT DATA { <node1> <id> "n1" } BASE <http://example.org/default/> SELECT * { <node1> ?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 { <node1> <id> "n1" } SELECT * { <node1> ?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 performances, Neptune stocke toujours les valeurs de date/heure 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 XSDNaN 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= 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
Ce comportement peut entraîner des résultats non intuitifs, comme dans l'exemple suivant.
Données :
<http://example.com/Server/1> <http://example.com/ip> "127.0.0.1"^^<http://example.com/datatype/IPAddress>
Requête 1 :
SELECT * WHERE { <http://example.com/Server/1> <http://example.com/ip> ?o . FILTER(?o = "127.0.0.2"^^<http://example.com/datatype/IPAddress>) }
Requête 2 :
SELECT * WHERE { <http://example.com/Server/1> <http://example.com/ip> ?o . FILTER(?o != "127.0.0.2"^^<http://example.com/datatype/IPAddress>) }
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"^^<http://example.com/IPAddress>, lorsqu'il est évalué pour ?o :=
"127.0.0.1"^^<http://example.com/IPAddress>, 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é <http://example.com/IPAddress>. 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
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"^^<http://example.com/IPAddress> 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 +127, 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 plagenumeric -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.
