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.

# Conformidad con los estándares de SPARQL en Amazon Neptune
<a name="feature-sparql-compliance"></a>

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

**Topics**
+ [Estándares aplicables de SPARQL](#feature-sparql-applicable-standards)
+ [Prefijos de espacio de nombres predeterminados en Neptune SPARQL](#sparql-default-prefixes)
+ [Gráfico predeterminado SPARQL y gráficos con nombre](#sparql-default-graph)
+ [Funciones del XPath constructor SPARQL compatibles con Neptune](#access-graph-sparql-xpath-constructors)
+ [IRI base predeterminado para consultas y actualizaciones](#opencypher-compliance-default-iri)
+ [Valores xsd:dateTime en Neptune](#access-graph-sparql-xsd-date-time)
+ [Gestión de Neptune de los valores especiales de coma flotante](#feature-overview-special-values-comparisons)
+ [Limitación en Neptune de los valores de longitud arbitraria](#feature-overview-arbitrary-length-values)
+ [Neptune amplía la comparación de valores iguales en SPARQL](#feature-overview-sparql-not-equal)
+ [Manejo de Out-of-Range literales en Neptune SPARQL](#feature-overview-sparql-out-of-range)

Amazon Neptune cumple los siguientes estándares en la implementación del lenguaje de consulta de gráficos SPARQL.

## Estándares aplicables de SPARQL
<a name="feature-sparql-applicable-standards"></a>
+ SPARQL se define en la recomendación [Lenguaje de consulta SPARQL 1.1](https://www.w3.org/TR/sparql11-query/) del W3C del 21 de marzo de 2013.
+ El lenguaje de consulta y el protocolo de SPARQL Update están definidos en la especificación [SPARQL 1.1 Update](https://www.w3.org/TR/sparql11-update/) del W3C.
+ En el caso de los formatos numéricos, SPARQL sigue la especificación de [W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes](https://www.w3.org/TR/xmlschema11-2/), que es coherente con la especificación IEEE 754 ([Estándar IEEE 754-2019 - IEEE para aritmética de coma flotante](https://standards.ieee.org/content/ieee-standards/en/standard/754-2019.html); consulte también la [página de la Wikipedia sobre IEEE 754](https://en.wikipedia.org/wiki/IEEE_754)). 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
<a name="sparql-default-prefixes"></a>

Neptune define los siguientes prefijos de forma predeterminada para su uso en consultas de SPARQL. Para obtener más información, consulte [Nombres con prefijos](https://www.w3.org/TR/sparql11-query/#prefNames) en la especificación de 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#`

## Gráfico predeterminado SPARQL y gráficos con nombre
<a name="sparql-default-graph"></a>

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 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](https://www.w3.org/TR/sparql11-query/#rdfDataset) de la especificación del lenguaje de consulta 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](load-api-reference-load.md).

**importante**  
 Si no utiliza este parámetro y no especifica un gráfico con nombre, se utiliza la URI alternativa: `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`.

## Funciones del XPath constructor SPARQL compatibles con Neptune
<a name="access-graph-sparql-xpath-constructors"></a>

El estándar SPARQL permite que los motores SPARQL admitan un conjunto extensible de funciones constructoras. XPath 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`

## IRI base predeterminado para consultas y actualizaciones
<a name="opencypher-compliance-default-iri"></a>

Como un clúster de Neptune tiene varios puntos finales diferentes, utilizar la URL de solicitud de una consulta o actualización como IRI base podría generar resultados inesperados al resolver un problema relativo. IRIs

A partir de la [versión 1.2.1.0 del motor](engine-releases-1.2.1.0.md), Neptune utiliza `http://aws.amazon.com/neptune/default/` como IRI base si no hay una IRI base explícita que forme parte de la solicitud.

En la siguiente solicitud, el IRI base forma parte de 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 se incluye ningún IRI 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
```

## Valores xsd:dateTime en Neptune
<a name="access-graph-sparql-xsd-date-time"></a>

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

Esto también significa que, si introduce un valor `dateTime` que especifica una zona horaria determinada, Neptune traduce el valor a UTC y descarta esa información de zona horaria. A continuación, cuando recupere el valor `dateTime` más tarde, se expresará en UTC, no en la hora de la zona horaria original, y no podrá indicar cuál era la zona horaria original.

## Gestión de Neptune de los valores especiales de coma flotante
<a name="feature-overview-special-values-comparisons"></a>

Neptune gestiona los valores especiales de coma flotante en SPARQL de la siguiente manera.

### Gestión de NaN de SPARQL en Neptune
<a name="feature-overview-NaN-comparisons"></a>

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 [especificación XSD](https://www.w3.org/TR/xmlschema-2/#double) trata dos valores `xsd:double` o `xsd:float` de `NaN` 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).

### Gestión de valores infinitos de SPARQL en Neptune
<a name="feature-overview-infinity-comparisons"></a>

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

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

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

### Gestión de cero negativo de SPARQL en Neptune
<a name="feature-overview-zero-comparisons"></a>

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
<a name="feature-overview-arbitrary-length-values"></a>

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

## Neptune amplía la comparación de valores iguales en SPARQL
<a name="feature-overview-sparql-not-equal"></a>

El estándar SPARQL define una lógica ternaria para las expresiones de valor, donde una expresión de valor puede evaluar a `true`, `false` o `error`. La semántica predeterminada para la igualdad de términos, tal y como se define en la [especificación SPARQL 1.1](https://www.w3.org/TR/sparql11-query/#func-RDFterm-equal), que se aplica a las comparaciones `=` y `!=` en las condiciones `FILTER`, produce un `error` al comparar los tipos de datos que no son explícitamente comparables en la [tabla de operadores](https://www.w3.org/TR/sparql11-query/#OperatorMapping) 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 semántica de SPARQL predeterminada que Neptune usaba 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 el operador de desigualdad de SPARQL de acuerdo con la especificación. Consulte la sección [SPARQL 1.1 sobre la extensibilidad de operadores](https://www.w3.org/TR/sparql11-query/#operatorExtensibility), que permite a los motores definir reglas adicionales sobre cómo efectuar la comparación entre 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 Out-of-Range literales en Neptune SPARQL
<a name="feature-overview-sparql-out-of-range"></a>

La semántica XSD define cada tipo numérico con su espacio de valor, excepto para `integer` y `decimal`. Estas definiciones limitan cada tipo a un rango de valores. Por ejemplo, el rango de un rango `xsd:byte` va de -128 a \$1127, 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 [operadores de rango](https://www.w3.org/TR/sparql11-query/#OperatorMapping) con el formato `numeric`*-operador-*`numeric`, `string`*-operador-*`string`, `literal`*-operador-*`literal`, etc. Neptune no puede ejecutar un operador de comparación de rangos con algo como `invalid-literal`*-operador-*`numeric-value`.