Meilleures pratiques de Neptune avec SPARQL

Suivez ces bonnes pratiques lors de l'utilisation du langage Neptune. Pour plus d'informations sur l'utilisation de SPARQL dans Neptune, consultezAccès au graphe Neptune avec SPARQL.

Interrogation de tous les graphes par défaut

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.

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 Neptune triSQL.

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 dans la spécification de langage de requête SPARQL 1.1.

Spécification d'un graphe nommé pour le chargement

Amazon Neptune associe chaque triplet à un graphe nommé. 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 secours défini par l'URI,http://aws.amazon.com/neptune/vocab/v01/DefaultNamedGraph.

Si vous utilisez le chargeur groupé Neptune, vous pouvez spécifier le graphe nommé à utiliser pour tous les triples (ou quadriceps dont la quatrième position est vide) à l'aide duparserConfiguration: namedGraphUri paramètre. Pour plus d'informations sur la syntaxe desLoad commandes du chargeur Neptune, reportez-vous à la sectionRéglage des requêtes Neptune.

Choisir entre FILTER, FILTER...IN et VALUES dans vos requêtes

Il existe trois façons de base d'injecter des valeurs dans les requêtes SPARQL :   FILTER,   FILTER...IN et VALUES.

Par exemple, imaginons que vous souhaitiez rechercher les amis de plusieurs personnes dans une seule requête. En utilisant FILTER, vous pouvez structurer votre requête comme suit :

  PREFIX ex: <https://www.example.com/>
  PREFIX foaf : <http://xmlns.com/foaf/0.1/>

  SELECT ?s ?o
  WHERE {?s foaf:knows ?o. FILTER (?s = ex:person1 || ?s = ex:person2)}

Cette opération renvoie tous les triplets du graphe dans lesquels ?s est lié à ex:person1 ou ex:person2 et qui ont un arc sortant intitulé foaf:knows.

Vous pouvez également créer une requête en utilisant FILTER...IN qui renvoie des résultats équivalents :

  PREFIX ex: <https://www.example.com/>
  PREFIX foaf : <http://xmlns.com/foaf/0.1/>

  SELECT ?s ?o
  WHERE {?s foaf:knows ?o. FILTER (?s IN (ex:person1, ex:person2))}

Vous pouvez également créer une requête en utilisant VALUES qui, dans ce cas, renvoie également des résultats équivalents :

  PREFIX ex: <https://www.example.com/>
  PREFIX foaf : <http://xmlns.com/foaf/0.1/>

  SELECT ?s ?o
  WHERE {?s foaf:knows ?o. VALUES ?s {ex:person1 ex:person2}}

Bien que, dans bien des cas, ces requêtes soient équivalentes sémantiquement, il y a certains cas où les deux variantes FILTER diffèrent de la variante VALUES :

• Le premier cas est lorsque vous injectez des valeurs en double, telles que l'injection de la même personne deux fois. Dans ce cas, la requête VALUES inclut les doublons dans votre résultat. Vous pouvez explicitement éliminer ces doublons en ajoutant un DISTINCT à la clause SELECT. Toutefois, dans certaines situations, vous souhaiterez peut-être conserver les doublons dans les résultats des requêtes à des fins d’injection des valeurs redondantes.

  Cependant, les versions FILTER...IN et FILTER extraient la valeur une seule fois lorsque la même valeur apparaît plusieurs fois.

• Le deuxième cas est lié au fait que VALUES génère toujours une correspondance exacte, alors que FILTER pourrait appliquer une promotion de type et réaliser des correspondances partielles dans certains cas.

  Par exemple, lorsque vous incluez une valeur littérale comme "2.0"^^xsd:float dans votre clause VALUES, une requête VALUES établit une correspondance exacte avec cette valeur littérale, y compris la valeur littérale et le type de données.

  En revanche, FILTER produit une correspondance partielle pour ces littéraux numériques. Les correspondances peuvent inclure des littéraux avec la même valeur mais des types de données numériques, par exemple xsd:double.

  Note

  Il n'y a pas de différence entre le comportement FILTER et VALUES lorsque vous énumérez les littéraux de chaîne ou des URI.

Les différences entre FILTER et VALUES peuvent affecter l'optimisation et la stratégie d'évaluation de requête qui en résulte. Sauf si votre cas d'utilisation nécessite des correspondances partielles, nous vous recommandons d'utiliser VALUES car cela évite d’examiner les cas spéciaux relatifs au transtypage. En conséquence, VALUES produit souvent une requête plus efficace qui s'exécute plus rapidement et qui coûte moins cher.