SPARQLconformidad con las normas en Amazon Neptune - 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.

SPARQLconformidad con las normas en Amazon Neptune

Tras enumerar SPARQL los estándares aplicables, en las siguientes secciones se proporcionan detalles específicos sobre cómo la SPARQL implementación de Neptune amplía o se aparta de esos estándares.

Amazon Neptune cumple con los siguientes estándares a la hora de implementar el lenguaje de consulta de SPARQL gráficos.

Normas aplicables para SPARQL

Prefijos de espacio de nombres predeterminados en Neptune SPARQL

Neptune define los siguientes prefijos de forma predeterminada para su uso en las consultas. SPARQL Para obtener más información, consulte Nombres con prefijo en la especificación. 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#

SPARQLGráfica predeterminada y gráficas con nombre

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.

Gráfico predeterminado para consultas

Si envía una SPARQL consulta sin especificar explícitamente un gráfico mediante la GRAPH palabra clave o construcciones comoFROM NAMED, por ejemplo, Neptune siempre considera todos los triples de su instancia de base de datos. Por ejemplo, la siguiente consulta devuelve todos los triples de un punto final de SPARQL 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 gráfica predeterminada, consulte la sección RDFConjunto de datos de la especificación del lenguaje de consultas SPARQL 1.1.

Especificación del gráfico con nombre para carga, inserciones o actualizaciones

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

Cuando emite una solicitud Load de Neptune utilizando un formato basado en triples, se puede especificar el gráfico con nombre que se va a utilizar para todos los triples mediante el parámetro parserConfiguration: namedGraphUri. Para obtener información acerca de la sintaxis del comando Load, consulte Comando del programa de carga de Neptune.

importante

Si no usa este parámetro y no especifica una gráfica con nombre, se usa la alternativa:. URI http://aws.amazon.com/neptune/vocab/v01/DefaultNamedGraph

También se utiliza este gráfico con nombre alternativo si se cargan triples a través de SPARQL UPDATE sin proporcionar explícitamente un destino de gráfico con nombre.

Puede utilizar el formato N-Quads basado en cuádruples para especificar un gráfico con nombre para cada triple en la base de datos.

nota

El uso de N-Quads le permite dejar el gráfico con nombre en blanco. En este caso, se usa http://aws.amazon.com/neptune/vocab/v01/DefaultNamedGraph.

Puede anular el gráfico con nombre predeterminado para N-Quads con la opción de configuración del analizador namedGraphUri.

SPARQLXPathFunciones constructoras compatibles con Neptune

El SPARQL estándar permite que SPARQL los motores admitan un conjunto extensible de funciones de XPath construcción. Neptune admite actualmente las siguientes funciones de constructores, donde el prefijo xsd se define como http://www.w3.org/2001/XMLSchema#:

  • xsd:boolean

  • xsd:integer

  • xsd:double

  • xsd:float

  • xsd:decimal

  • xsd:long

  • xsd:unsignedLong

Base predeterminada IRI para consultas y actualizaciones

Debido a que un cúmulo de Neptune tiene varios puntos finales diferentes, utilizar la solicitud URL de una consulta o actualización como base IRI podría generar resultados inesperados a la hora de resolver relativos. IRIs

A partir de la versión 1.2.1.0 del motor, Neptune se utiliza http://aws.amazon.com/neptune/default/ como base IRI si una base IRI explícita no forma parte de la solicitud.

En la siguiente solicitud, la base forma parte de IRI la solicitud:

BASE <http://example.org/default/> INSERT DATA { <node1> <id> "n1" } BASE <http://example.org/default/> SELECT * { <node1> ?p ?o }

Y el resultado sería:

?p ?o http://example.org/default/id n1

Sin embargo, en esta solicitud no IRI se incluye ninguna base:

INSERT DATA { <node1> <id> "n1" } SELECT * { <node1> ?p ?o }

En ese caso, el resultado sería:

?p ?o http://aws.amazon.com/neptune/default/id n1

xsd: dateTime Valores en Neptuno

Por motivos de rendimiento, Neptune siempre almacena los valores de fecha y hora como hora universal coordinada (). UTC Esto hace que las comparaciones directas sean muy eficientes.

Esto también significa que si introduce un dateTime valor que especifica una zona horaria concreta, Neptune traduce el valor a esa información de zona horaria UTC y la descarta. Luego, cuando recupera el dateTime valor más adelante, se expresa en la hora de la zona horaria originalUTC, no en ella, y ya no puede saber cuál era esa zona horaria original.

Gestión de Neptune de los valores especiales de coma flotante

Neptune maneja los valores especiales de punto flotante de la siguiente manera. SPARQL

SPARQLManejo de NaN en Neptune

En Neptune, SPARQL puede aceptar un valor de NaN en una consulta. No se hace ninguna distinción entre los valores de señalización y los valores NaN silenciosos. Neptune trata todos los valores NaN como silenciosos.

Semánticamente, no es posible ninguna comparación de un valor NaN, porque nada es mayor, menor o igual que NaN. Esto significa que un valor de NaN en un lado de una comparación en teoría nunca coincide con nada del otro lado.

Sin embargo, la XSDespecificación trata dos xsd:double o xsd:float NaN valores como iguales. Neptune hace esto para el filtro IN, para el operador igual en las expresiones de filtro y para la semántica de coincidencia (que tiene a NaN en la posición del objeto de un patrón triple).

SPARQLManejo de valores infinitos en Neptune

En Neptune, SPARQL puede aceptar un valor de INF o -INF en una consulta. INFse compara como mayor que cualquier otro valor numérico y -INF se compara como menor que cualquier otro valor numérico.

Dos INF valores con signos coincidentes se comparan como iguales entre sí independientemente de su tipo (por ejemplo, un valor flotante -INF se compara como igual a un doble-INF).

Por supuesto, no es posible ninguna comparación con NaN porque nada es mayor, menor o igual que NaN.

SPARQLManejo de cero negativo en Neptune

Neptune normaliza un valor cero negativo a un cero sin signo. Puede utilizar los valores cero negativos se pueden utilizar en una consulta, pero no se registran como tales en la base de datos y se comparan como iguales a ceros sin signo.

Limitación en Neptune de los valores de longitud arbitraria

Neptune limita el tamaño de almacenamiento de valores XSD enteros, de coma flotante y decimales SPARQL a 64 bits. Si se utilizan valores mayores, se producirá un error InvalidNumericDataException.

Neptuno amplía la comparación de iguales en SPARQL

El SPARQL estándar define una lógica ternaria para las expresiones de valor, en la que una expresión de valor puede evaluar a truefalse, o. error La semántica predeterminada para la igualdad de términos (tal como se define en la especificación SPARQL 1.1), que se aplica a FILTER las condiciones = y a las != comparaciones en ellas, genera una error cuando se comparan tipos de datos que no son explícitamente comparables en la tabla de operadores de la especificación.

Este comportamiento puede conllevar resultados poco intuitivos, como en el siguiente ejemplo.

Datos:

<http://example.com/Server/1> <http://example.com/ip> "127.0.0.1"^^<http://example.com/datatype/IPAddress>

Consulta 1:

SELECT * WHERE { <http://example.com/Server/1> <http://example.com/ip> ?o . FILTER(?o = "127.0.0.2"^^<http://example.com/datatype/IPAddress>) }

Consulta 2:

SELECT * WHERE { <http://example.com/Server/1> <http://example.com/ip> ?o . FILTER(?o != "127.0.0.2"^^<http://example.com/datatype/IPAddress>) }

Con la SPARQL semántica predeterminada que Neptune utilizaba antes de la versión 1.0.2.1, ambas consultas devolverían el resultado vacío. La razón es que, cuando ?o = "127.0.0.2"^^<http://example.com/IPAddress> se evalúa para ?o := "127.0.0.1"^^<http://example.com/IPAddress>, se produce un error distinto de false porque no hay reglas de comparación explícitas especificadas para el tipo de datos personalizados <http://example.com/IPAddress>. Como resultado, la versión negada en la segunda consulta también produce un error. En ambas consultas, el error provoca que se excluya la solución candidata.

A partir de la versión 1.0.2.1, Neptune ha ampliado SPARQL el operador de desigualdad de acuerdo con la especificación. Consulte la sección SPARQL 1.1 sobre la extensibilidad del operador, que permite a los motores definir reglas adicionales sobre cómo comparar tipos de datos integrados definidos por el usuario y no comparables.

Mediante esta opción, Neptune ahora trata una comparación de dos tipos de datos cualesquiera que no estén explícitamente definidos en la tabla de mapeo de operadores como si se evaluaran en true si los valores literales y los tipos de datos son sintácticamente iguales y en false en caso contrario. En cualquier caso no se produce un error.

Con esta nueva semántica, la segunda consulta devolvería "127.0.0.1"^^<http://example.com/IPAddress> en lugar de un resultado vacío.

Manejo de literales fuera de rango en Neptuno SPARQL

XSDla semántica define cada tipo numérico con su espacio de valores, excepto y. integer decimal Estas definiciones limitan cada tipo a un rango de valores. Por ejemplo, el rango de un rango xsd:byte va de -128 a +127, ambos incluidos. Cualquier valor fuera de este rango no se considera válido.

Si intenta asignar un valor literal fuera del espacio de valores de un tipo (por ejemplo, si intenta establecer un xsd:byte valor literal de 999), Neptune acepta el out-of-range valor tal cual, sin redondearlo ni truncarlo. Pero no lo conserva como un valor numérico ya que el tipo determinado no puede representarlo.

Es decir, Neptune acepta "999"^^xsd:byte aunque sea un valor fuera del rango de valores xsd:byte definido. Sin embargo, después de que el valor se conserve en la base de datos, solo se puede utilizar en la semántica de coincidencia exacta, en una posición de objeto de un patrón triple. No se puede ejecutar ningún filtro de rango en él porque los out-of-range literales no se tratan como valores numéricos.

La especificación SPARQL 1.1 define los operadores de rango con la forma numeric -operator-numeric, string -operator-string, literal -operator-literal, etc. Neptune no puede ejecutar un operador de comparación de rangos con algo como invalid-literal-operador-numeric-value.