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.
Temas
- Normas aplicables para SPARQL
- Prefijos de espacio de nombres predeterminados en Neptune SPARQL
- SPARQLGráfica predeterminada y gráficas con nombre
- SPARQLXPathFunciones constructoras compatibles con Neptune
- Base predeterminada IRI para consultas y actualizaciones
- xsd: dateTime Valores en Neptuno
- Gestión de Neptune de los valores especiales de coma flotante
- Limitación en Neptune de los valores de longitud arbitraria
- Neptuno amplía la comparación de iguales en SPARQL
- Manejo de literales fuera de rango en Neptuno SPARQL
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
SPARQLse define en la recomendación del lenguaje de consulta SPARQL 1.1
del W3C del 21 de marzo de 2013. Para los formatos numéricos, SPARQL sigue la especificación del lenguaje de definición de XML esquemas del W3C (XSD) 1.1, parte 2: Tipos de datos, que es coherente con la especificación IEEE 754 (IEEE754-2019, estándar para aritmética de punto flotante
). IEEE Para obtener más información, consulta también la Wikipedia (página 754). IEEE Sin embargo, las características que se incorporaron después de la versión IEEE 754-1985
no están incluidas en la especificación.
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
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
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ónxsd: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. INF
se 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 true
false
, o. error
La semántica predeterminada para la igualdad de términos (tal como se define en la especificación SPARQL 1.1FILTER
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
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
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 rangonumeric
-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
.