SPARQL Endpoints

Every Dydra repository is also a SPARQL endpoint. If you’re not familiar with the SPARQL language, we have an introduction.

Your repository’s SPARQL endpoint is found by appending /sparql to the repository’s URL. So a user jhacker who created a repository named foaf would have a SPARQL endpoint located at http://dydra.com/jhacker/foaf/sparql. As simple query, which specifies a user identifier and returns a statement count for the jhacker/foaf repository can be done with curl

$ curl -H 'Accept: application/sparql-results+json' \
        'http://dydra.com/jhacker/foaf/sparql?query=select%20count(*)%20where%20%7b?s%20?p%20?o%7d&user_id=myId'
{ "head": { "vars": [ "COUNT1" ] },
   "results": {
   "bindings": [ { "COUNT1": {"type":"typed-literal",
                              "datatype":"http://www.w3.org/2001/XMLSchema#integer",
                   "value":"10"} } ] } }
$

Authentication

Please see the API Authentication documentation for a reference on authenticating SPARQL request.

Dydra’s SPARQL Dialect

Like all SPARQL implementations, Dydra’s has some quirks. Unlike all SPARQL implementations, our canonical description comprises a bnf and a set of executable tests, written in RSpec.

Features

We’re always interested in your feedback about our feature set.

SPARQL versions

Dydra’s SPARQL processor supports SPARQL 1.1. Take a look at our blog for further details.

Blank Node Handling

Dydra treats blank node identifiers as canonical. When data is imported, existing blank node identifiers are saved, and new, canonical blank node identifiers are created for new nodes. In practice, this is quite useful: the output of one query can be matched with another.

Normalization

Dydra is a graph store (as opposed to a document store). We store the semantic representations of numerics, dates, and times. The result is that several of these formats do not round-trip. For example, data imported as "01"^^XSD.integer would be returned as "1"^^XSD.integer. See the Dydra reference tests for more detail.

Short Forms

We support several query variations as a matter of convenience.

Simplified Aggregates

Our query processor permits a simplified and abbreviated convenience syntax for aggregates. For example,

SELECT count(*) WHERE {?s ?p ?o}

is treated as equivalent to

SELECT (count(*) AS ?count1) WHERE {?s ?p ?o}
De-duplicated projection variables

Our query processor removes duplicate projection variable from SELECT forms. For example,

SELECT ?s ?p ?o ?s WHERE {?s ?p ?o}

is treated as equivalent to

SELECT ?s ?p ?o WHERE {?s ?p ?o}
The Default Graph

The default graphs of the default dataset which available when no explicit dataset is specified comprises exactly the default graph. That is, sd:UnionDefaultGraph is not a SPARQL endpoint feature.

Undefined Variables

The query compiler recognizes undefined variables and treats them as an error. Where an installation is configured to support request parameters, such formulations can serve to allow optional evaluation depending on which parameters are bound. Without that, we observe the results are more likely unintended empty result sets or missing construct elements. Given which, we have configured this installation to fail such requests.

Null-Rejection

The query compiler is "NULL rejecting". This means that chained OPTIONAL operations must keep in mind that shared variables constrain the results.