Prácticas recomendadas de Neptune con SPARQL - Amazon Neptune

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Prácticas recomendadas de Neptune con SPARQL

Siga estas prácticas recomendadas cuando utilice el lenguaje de consulta SPARQL con Neptune. Para obtener más información sobre el uso de SPARQL en Neptune, consulte Acceso al gráfico de Neptune con SPARQL.

Consulta de todos los gráficos con nombre de forma predeterminada

Amazon Neptune asocia cada triple con un gráfico con nombre. El gráfico predeterminado se define como la unión de todos los gráficos con nombre.

Si envía una consulta SPARQL sin especificar explícitamente un gráfico mediante la palabra clave GRAPH o construcciones como FROM NAMED, Neptune siempre tiene en cuenta todos los triples en su instancia de base de datos. Por ejemplo, la siguiente consulta devuelve todos los triples desde un punto de conexión de SPARQL de Neptune:

SELECT * WHERE { ?s ?p ?o }

Los triples que aparecen en más de un gráfico se devuelven solo una vez.

Para obtener información sobre la especificación de gráfico predeterminado, consulte la sección Conjunto de datos de RDF de la especificación del lenguaje de consulta SPARQL 1.1.

Especificación de un gráfico con nombre para la carga

Amazon Neptune asocia cada triple con un gráfico con nombre. Si no especifica un gráfico con nombre al cargar, insertar o actualizar triples, Neptune utiliza el gráfico con nombre alternativo definido por el URI, http://aws.amazon.com/neptune/vocab/v01/DefaultNamedGraph.

Si utiliza el programa de carga masiva de Neptune, puede especificar el gráfico con nombre que se utilizará para todos los triples (o cuádruples con la cuarta posición en blanco) utilizando el parámetro parserConfiguration: namedGraphUri. Para obtener información acerca de la sintaxis del comando Load del programa de carga de Neptune, consulte Comando del programa de carga de Neptune.

Elegir entre FILTER, FILTER... IN y VALUES en sus consultas

Existen tres formas básicas para introducir valores en las consultas SPARQL:     FILTER,   FILTER...IN,   y   VALUES.

Por ejemplo, suponiendo que desee buscar los amigos de varias personas dentro de una única consulta. Con FILTER, podría estructurar su consulta de la siguiente manera:

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)}

Este devuelve todos los valores triples en el gráfico que tiene ?s vinculado a ex:person1 o ex:person2 y que dispone de un borde saliente etiquetado como foaf:knows.

También puede crear una consulta mediante FILTER...IN que devuelve resultados equivalentes.

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))}

También puede crear una consulta mediante VALUES que, en este caso, también devuelve resultados equivalentes.

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}}

Aunque en muchos casos estas consultas son equivalente semánticamente, existen algunos casos en los que las dos variantes de FILTER difieren de la variante VALUES:

  • El primer caso es cuando introduce los valores duplicados; como, por ejemplo, introducir a la misma persona dos veces. En ese caso, la consulta VALUES incluye los valores duplicados en su resultado. Puede eliminar los duplicados de forma explícita mediante la incorporación de un DISTINCT a la cláusula SELECT. Sin embargo, podría haber situaciones en las que realmente quiere duplicados en los resultados de la consulta para la introducción de un valor redundante.

    Sin embargo, las versiones FILTER y FILTER...IN extraen solo una vez el valor cuando el mismo valor aparece varias veces.

  • El segundo caso está relacionado con el hecho de que VALUES siempre realiza una coincidencia exacta, mientras que FILTER podría aplicar el tipo de promoción y realizar coincidencias parciales en algunos casos.

    Por ejemplo, cuando incluya una cláusula literal como "2.0"^^xsd:float en sus valores, una consulta VALUES coincide totalmente con este valor literal, incluidos el valor literal y el tipo de datos.

    En cambio, FILTER produce una coincidencia parcial para estos valores numéricos. Las coincidencias podría incluir valores literales con el mismo valor, pero con distintos tipos de valores numéricos, como xsd:double.

    nota

    No hay ninguna diferencia entre el comportamiento deFILTER y VALUES cuando se enumeran los valores literales de las cadena o de los URI.

Las diferencias entre FILTER y VALUES pueden afectar a la optimización y a la estrategia de evaluación de consulta resultante. A menos que su caso de uso requiera una coincidencia parcial, le recomendamos que utilice VALUES, ya que evita examinar los casos especiales relacionados con la conversión de tipos. Como resultado, VALUES produce a menudo una consulta más eficaz, que se ejecuta más rápido y es más económica.