SPARQL compliance¶

SPARQL 1.1 Protocol for RDF¶

SPARQL 1.1 Protocol for RDF defines the means for transmitting SPARQL queries to a SPARQL query processing service, and returning the query results to the entity that requested them.

SPARQL 1.1 Query¶

SPARQL 1.1 Query provides more powerful query constructions compared to SPARQL 1.0. It adds:

• Aggregates;
• Subqueries;
• Negation;
• Expressions in the SELECT clause;
• Property Paths;
• Assignment;
• An expanded set of functions and operators.

SPARQL 1.1 Update¶

SPARQL 1.1 Update provides a means to change the state of the database using a query-like syntax. SPARQL Update has similarities to SQL INSERT INTO, UPDATE WHERE and DELETE FROM behaviour. For full details, see the W3C SPARQL Update working group page.

SPARQL 1.1 Federation¶

SPARQL 1.1 Federation provides extensions to the query syntax for executing distributed queries over any number of SPARQL endpoints. This feature is very powerful, and allows integration of RDF data from different sources using a single query.

For example, to discover DBpedia resources about people who have the same names as those stored in a local repository, use the following query:

SELECT ?dbpedia_id
WHERE {
   ?person a foaf:Person ;
           foaf:name ?name .
   SERVICE <http://dbpedia.org/sparql> {
        ?dbpedia_id a dbpedia-owl:Person ;
                    foaf:name ?name .
   }
}

It matches the first part against the local repository and for each person it finds, it checks the DBpedia SPARQL endpoint to see if a person with the same name exists and, if so, returns the ID.

Since RDF4J repositories are also SPARQL endpoints, it is possible to use the federation mechanism to do distributed querying over several repositories on a local server.

For example, imagine that you have two repositories - one called my_concepts with triples about concepts and another called my_labels, containing all label information.

To retrieve the corresponding label for each concept, you can execute the following query on the my_concepts repository:

SELECT ?id ?label
WHERE {
    ?id a ex:Concept .
    SERVICE <http://localhost:7200/repositories/my_labels> {
        ?id rdfs:label ?label.
    }
}

The following example finds resources in the second SPARQL endpoint, which have a similar rdfs:label to the rdfs:label of <http://dbpedia.org/resource/Vaccination> in the first SPARQL endpoint:

PREFIX rdfs:<http://www.w3.org/2000/01/rdf-schema#>

SELECT ?endpoint2_id {
    SERVICE <http://faraway_endpoint.org/sparql>
    {
        ?endpoint1_id rdfs:label ?l1 .
        FILTER( lang(?l1) = "en" )
    }
    SERVICE <http://remote_endpoint.com/sparql>
    {
        ?endpoint2_id rdfs:label ?l2 .
        FILTER( str(?l2) = str(?l1) )
    }
}
BINDINGS ?endpoint1_id
{ ( <http://dbpedia.org/resource/Vaccination> ) }

However, such a query is very inefficient, because no intermediate bindings are passed between endpoints. Instead, both subqueries execute independently, requiring the second subquery to return all X  rdfs:label Y statements that it stores. These are then joined locally to the (likely much smaller) results of the first subquery.

SPARQL 1.1 Graph Store HTTP Protocol¶

SPARQL 1.1 Graph Store HTTP Protocol provides a means for updating and fetching RDF graph content from a Graph Store over HTTP in the REST style.