SPARQLconformité aux normes dans Amazon Neptune

Après avoir répertorié SPARQL les normes applicables, les sections suivantes fournissent des détails spécifiques sur la manière dont la SPARQL mise en œuvre de Neptune étend ou diverge de ces normes.

Amazon Neptune respecte les normes suivantes lors de la mise en œuvre du langage de requête SPARQL graphique.

Normes applicables pour SPARQL

• SPARQLest défini par la recommandation du W3C SPARQL1.1 sur le langage de requête du 21 mars 2013.

• Le protocole de SPARQL mise à jour et le langage de requête sont définis par la spécification de mise à jour SPARQL 1.1 du W3C.

• Pour les formats numériques, SPARQL suivez la spécification W3C XML Schema Definition Language (XSD) 1.1, partie 2 : Datatypes, qui est conforme à la spécification IEEE 754 (IEEE754-2019) - Standard pour l'arithmétique à virgule flottante. IEEE Pour plus d'informations, voir également Wikipédia (page 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 par défaut les préfixes suivants à utiliser dans les requêtes. SPARQL Pour plus d'informations, consultez la section Noms préfixés dans la SPARQL spécification.

• 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#

SPARQLGraphe par défaut 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 soumettez une SPARQL requête sans spécifier explicitement un graphe via le GRAPH mot clé ou des constructions telles queFROM NAMED, Neptune prend toujours en compte tous les triplets de votre instance de base de données. Par exemple, la requête suivante renvoie tous les triplets d'un point de terminaison SPARQL Neptune :

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 graphique par défaut, consultez la section RDFEnsemble de données de la spécification du 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 de graphe nommé lors du chargement, de l'insertion ou de la mise à jour de triplets, Neptune utilise le graphe nommé de remplacement défini par le. 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 de graphe nommé, la solution de secours URI est utilisée :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.

SPARQLXPathFonctions de constructeur prises en charge par Neptune

La SPARQL norme permet aux SPARQL moteurs 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

Base par défaut IRI pour les requêtes et les mises à jour

Étant donné qu'un cluster Neptune possède plusieurs points de terminaison différents, l'utilisation de la demande URL d'une requête ou d'une mise à jour comme base IRI peut entraîner des résultats inattendus lors de la résolution relative. IRIs

Depuis la version 1.2.1.0 du moteur, Neptune l'utilise http://aws.amazon.com/neptune/default/ comme base IRI si aucune base explicite ne IRI fait partie de la demande.

Dans la requête suivante, la base IRI fait partie de la requête :

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

Dans cette demande, cependant, aucune base n'IRIest incluse :

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

xsd : dateTime Valeurs dans Neptune

Pour des raisons de performance, Neptune stocke toujours les valeurs de date/heure sous forme de temps universel coordonné (). UTC Cela rend les comparaisons directes très efficaces.

Cela signifie également que si vous entrez une dateTime valeur qui spécifie un fuseau horaire particulier, Neptune convertit la valeur en informations de fuseau horaire UTC et les ignore. Ensuite, lorsque vous récupérerez la dateTime valeur ultérieurement, elle est exprimée en UTC heure 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 gère les valeurs spéciales à virgule flottante comme suit. SPARQL

SPARQLGestion du NaN dans Neptune

Dans Neptune, SPARQL peut accepter une valeur de 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 XSDspécification traite deux xsd:double ou deux xsd:float NaN valeurs 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).

SPARQLGestion de la valeur infinie dans Neptune

Dans Neptune, SPARQL peut accepter une valeur de INF ou -INF dans une requête. INFcompare en tant que valeur supérieure à toute autre valeur numérique et -INF en tant que valeur inférieure à toute autre valeur numérique.

Deux INF valeurs dont les signes correspondent sont comparables l'une à l'autre quel que soit leur type (par exemple, un -INF flottant 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.

SPARQLGestion du zéro négatif 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 la taille de stockage des valeurs XSD entières, à virgule flottante et décimales SPARQL à 64 bits. L'utilisation de valeurs plus grandes génère une erreur InvalidNumericDataException.

Neptune étend sa comparaison avec Equals dans SPARQL

La SPARQL norme définit une logique ternaire pour les expressions de valeur, dans laquelle une expression de valeur peut être évaluée à truefalse, ouerror. La sémantique par défaut pour l'égalité des termes (telle que définie dans la spécification SPARQL 1.1), qui s'applique aux FILTER conditions = et aux != comparaisons entre celles-ci, produit un error lors de la comparaison de types de données qui ne sont pas explicitement comparables dans le tableau des opérateurs de la spécification.

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 SPARQL sémantique par défaut utilisée par Neptune avant la version 1.0.2.1, les deux requêtes renverraient un 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 SPARQL l'opérateur d'inégalité conformément à la spécification. Consultez la section SPARQL 1.1 sur l'extensibilité pour les opérateurs, qui permet aux moteurs de définir des règles supplémentaires sur la manière de comparer les 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"^^<http://example.com/IPAddress> au lieu d'un résultat vide.

Gestion des littéraux hors de portée dans Neptune SPARQL

XSDla sémantique définit chaque type numérique avec son espace de valeurs, à l'exception de et. integer 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 plage 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.