Uso del protocolo HTTP de almacén de gráficos (GSP) de SPARQL 1.1 en Amazon Neptune - Amazon Neptune
Detalles de la implementación

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.

Uso del protocolo HTTP de almacén de gráficos (GSP) de SPARQL 1.1 en Amazon Neptune

En la recomendación del protocolo HTTP de almacén de gráficos de SPARQL 1.1, el W3C definió un protocolo HTTP para administrar los gráficos RDF. Define las operaciones para eliminar, crear y reemplazar el contenido de los gráficos RDF, así como para añadir instrucciones RDF al contenido existente.

El protocolo de almacén de gráficos (GSP) proporciona una forma cómoda de manipular todo el gráfico sin tener que escribir consultas SPARQL complejas.

A partir de Versión: 1.0.5.0 (27/07/2021), Neptune es totalmente compatible con este protocolo.

El punto de conexión del protocolo de almacén de gráficos (GSP) es:

https://your-neptune-cluster:port/sparql/gsp/

Para acceder al gráfico predeterminado con GSP, utilice:

https://your-neptune-cluster:port/sparql/gsp/?default

Para acceder a un gráfico con nombre con GSP, utilice:

https://your-neptune-cluster:port/sparql/gsp/?graph=named-graph-URI

Detalles especiales de la implementación de GSP en Neptune

Neptune implementa plenamente la recomendación del W3C que define GSP. Sin embargo, hay algunas situaciones que la especificación no cubre.

Una de ellas es cuando una solicitud PUT o POST especifica uno o más gráficos con nombre en el cuerpo de la solicitud que difieren del gráfico especificado en la URL de la solicitud. Esto solo puede ocurrir cuando el formato RDF del cuerpo de la solicitud admite gráficos con nombre, como, por ejemplo, si se utiliza Content-Type: application/n-quads o Content-Type: application/trig.

En esta situación, Neptune añade o actualiza todos los gráficos con nombre presentes en el cuerpo, así como el gráfico con nombre especificado en la URL.

Por ejemplo, supongamos que, partiendo de una base de datos vacía, se envía una solicitud PUT para realizar actualizaciones o inserciones en los votos en tres gráficos. Uno, denominado urn:votes, contiene todos los votos de todos los años electorales. Otros dos, denominados urn:votes:2005 y urn:votes:2019, contienen votos de años electorales específicos. La solicitud y su carga tienen el siguiente aspecto:

PUT "http://your-Neptune-cluster:port/sparql/gsp/?graph=urn:votes"
  Host: example.com
  Content-Type: application/n-quads

  PAYLOAD:

  <urn:JohnDoe> <urn:votedFor> <urn:Labour> <urn:votes:2005>
  <urn:JohnDoe> <urn:votedFor> <urn:Conservative> <urn:votes:2019>
  <urn:JaneSmith> <urn:votedFor> <urn:LiberalDemocrats> <urn:votes:2005>
  <urn:JaneSmith> <urn:votedFor> <urn:Conservative> <urn:votes:2019>

Una vez ejecutada la solicitud, los datos de la base de datos tienen el siguiente aspecto:

<urn:JohnDoe>   <urn:votedFor> <urn:Labour>           <urn:votes:2005>
<urn:JohnDoe>   <urn:votedFor> <urn:Conservative>     <urn:votes:2019>
<urn:JaneSmith> <urn:votedFor> <urn:LiberalDemocrats> <urn:votes:2005>
<urn:JaneSmith> <urn:votedFor> <urn:Conservative>     <urn:votes:2019>
<urn:JohnDoe>   <urn:votedFor> <urn:Labour>           <urn:votes>
<urn:JohnDoe>   <urn:votedFor> <urn:Conservative>     <urn:votes>
<urn:JaneSmith> <urn:votedFor> <urn:LiberalDemocrats> <urn:votes>
<urn:JaneSmith> <urn:votedFor> <urn:Conservative>     <urn:votes>

Otra situación ambigua es cuando se especifica más de un gráfico en la propia URL de la solicitud, utilizando PUT, POST, GET o DELETE. Por ejemplo:

POST "http://your-Neptune-cluster:port/sparql/gsp/?graph=urn:votes:2005&graph=urn:votes:2019"

O bien:

GET "http://your-Neptune-cluster:port/sparql/gsp/?default&graph=urn:votes:2019"

En esta situación, Neptune devuelve un HTTP 400 con un mensaje que indica que solo se puede especificar un gráfico en la URL de la solicitud.