Managing Data in Dydra With SPARQL 1.1 Graph Store HTTP Protocol

Although this post uses Dydra graph database cloud service to illustrate the concepts, the approach is equally applicable to any RDF graph store that supports the SPARQL 1.1 Graph Store HTTP Protocol

Loading data to Dydra is pretty simple from the UI or with SPARQL 1.1 Update, however it can sometimes be easier to implement or work with HTTP operations at named graph level (where a named graph can be thought of as an RDF ‘document’).

To enable this Dydra supports the HTTP GET, PUT, DELETE and POST methods as defined by the SPARQL 1.1 Graph Store HTTP Protocol recommendation.

The graph store service endpoint of a repository is the repository URI followed by /service i.e.:

http://dydra.com/{user}/{repo}/service

To access the default graph, simply add ?default parameter. To access a specific named graph use ?graph parameter with the percent-encoded IRI of the named graph as the value (Dydra uses the indirect graph identification approach). For example to work with the graph http://example.com/mygraph use parameter ?graph=http%3A%2F%2Fwww.example.com%2Fmygraph (you can easily percent encode the graph IRI using online tools such as the URL Decoder/Encoder).

If the Dydra repository has privacy settings applied, you will also need to authenticate using basic HTTP authentication in conjunction with your API key e.g.:

http://dydra.com/{user}/{repo}/service?default&auth_token={MY_API_KEY}

The HTTP methods behave as follows:

  • GET fetches a serialization of the specified graph. The default format is Turtle, but other formats can be requested via content negotiation using the Accept header
  • PUT stores the RDF payload in the specified graph. Any existing data in the graph is overwritten. The format of the supplied RDF is specified using the Content-Type header
  • DELETE removes the specified graph from the repository. If the default graph is specified, it is equivalent to DROP DEFAULT in SPARQL 1.1 Update
  • POST appends the RDF payload to the specified graph. Any existing data in the graph is retained (an RDF merge of the graphs is performed). Again the format of the supplied RDF is specified using the Content-Type header.

Examples using curl

Get the default graph in the nlv01111/gsp repository in (default) Turtle serialization format:

curl https://dydra.com/nlv01111/gsp/service?default

Get the named graph http://example.com/mygraph in the nlv01111/gsp repository in JSON-LD format and output to local file data.jsonld:

curl "https://dydra.com/nlv01111/gsp/service?graph=http%3A%2F%2Fexample.com%2Fmygraph" \
  --header "Accept: application/ld+json" \
  --output data.jsonld

Put a local Turtle file data.ttl to the default graph in the nlv01111/gsp repository:

curl -X PUT "https://dydra.com/nlv01111/gsp/service?default&auth_token=${MY_API_KEY}" \
  --data-binary @data.ttl \
  --header "Content-Type: text/turtle"

Put a local RDF/XML file data.rdf to the named graph http://example.com/mygraph in the nlv01111/gsp repository:

curl -X PUT "https://dydra.com/nlv01111/gsp/service?graph=http%3A%2F%2Fexample.com%2Fid%2Fmygraph&auth_token=${MY_API_KEY}" \
  --data-binary @data.rdf \
  --header "Content-Type: application/rdf+xml"