Warning:
This wiki has been archived and is now read-only.

Overview-Document

From SPARQL Working Group
Jump to: navigation, search

This draft has been moved to CVS, cf. http://www.w3.org/2009/sparql/docs/sparql11-overview/

Template:TR

Editors
The W3C SPARQL Working Group, see [Acknowledgements]
Abstract

This document is an overview of SPARQL 1.1. It provides an introduction to a set of W3C specifications that facilitate querying and manipulating RDF knowledge on the Web or in an RDF store.

Status of this Document
@@update This is an automatically generated Mediawiki page, made from some sort of W3C-style spec.

Copyright © 2010 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.


1 Introduction

SPARQL 1.1 is a set of specifications that provide languages and protocols to query and manipulate RDF knowledge on the Web or in an RDF store. The standard comprises the following specifications:

  • SPARQL 1.1 Query Language - A query language for RDF.
  • SPARQL 1.1 Query Results JSON Format and SPARQL 1.1 Query Results CSV and TSV Formats - Apart from the standard [SPARQL Query Results XML Format], SPARQL1.1 now allow thee alternative popular formats to exchange answers to SPARQL queries, namely JSON, CSV (comma separated values) and TSV (tab separated values) which are described in these two documents.
  • SPARQL 1.1 Federated Query - This specification an extension of SPARQL 1.1 Query for executing queries distributed over different SPARQL endpoints.
  • SPARQL 1.1 Entailment Regimes - A specification defining the semantics of SPARQL queries under entailment regimes such as RDF Schema, OWL2, or, RIF.
  • SPARQL 1.1 Update Language - An an update language for RDF graphs
  • SPARQL 1.1 Protocol for RDF - A protocol defining means for conveying arbitrary SPARQL queries and update requests to a SPARQL service.
  • SPARQL 1.1 Service Description - This document defines a method for discovering and a vocabulary for describing SPARQL services.
  • SPARQL 1.1 Graph Store HTTP Protocol - As opposed to the full SPARQL protocol, this specification defines minimal means for managing RDF knowledge directly via common HTTP operations.
  • Using SPARQL1.1 with RDF1.1 - SPARQL1.1 is based on the Resource Description Framework (RDF) specifications in their 2004 version. This document describes how SPARQL1.1 is to be used with RDF1.1, which is currently under development. @@@ this is a placeholder at the moment.
  • @@@Shall this document also link to the test suite?

1.1 Example

In the following, we illustrate the use of SPARQL's languages, protocols, and related specifications by some small example.

Some RDF graphs published on the Web at the URL 'http://example.org/alice' and 'http://foaf.example.org/' contain personal information about Alice and her social contacts as well as a simple RDF Schema [@@@ref] Ontology. We use Turtle [@@@ref] syntax here for illustration.

Graph: http://example.org/alice

 @prefix : <http://example.org/alice#> .
 @prefix foaf: <http://xmlns.com/foaf/0.1/> .
 @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

 :me a foaf:Person .
 :me rdfs:label "Alice" .
 :me foaf:mbox <mailto:alice@example.org> .
 :me foaf:knows <http://example.org/bob#me> .
 <http://example.org/bob#me> foaf:name "Bob" .
 :me foaf:knows <http://example.org/charlie#me> .
 <http://example.org/charlie#me> foaf:name "Charlie" .
 <http://example.org/charlie#me> foaf:mbox <mailto:charlie@example.org> .
 :me foaf:knows <http://example.org/marie#me> .
 <http://example.org/marie#me> foaf:name "Marie" .

Graph: http://foaf.example.org/

 @prefix foaf: <http://xmlns.com/foaf/0.1/> .
 @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

 foaf:knows rdfs:domain foaf:Person .
 foaf:knows rdfs:range foaf:Person .
 foaf:name rdfs:subPropertyOf rdfs:label .

With SPARQL1.1 one can query and manipulate these graphs in various ways.

2 SPARQL 1.1 Query Language

Assuming the graph data from both graphs above are loaded into a SPARQL service, the SPARQL 1.1 query language can be used to formulate queries ranging from simple graph pattern matching to complex queries. For instance, one can ask using a SPARQL SELECT query for the identifiers and names of Alice' friends

PREFIX foaf: <http://xmlns.com/foaf/0.1/>
SELECT ?person ?name
FROM <http://example.org/alice>
WHERE { 
   <http://example.org/alice#me> foaf:knows ?person . 
   ?person foaf:name ?name . 
}

More complex queries may include union, optional query parts, filters, value aggregation, path expressions, nested queries, etc. Moreover, apart from SELECT queries - which return variable bindings - SPARQL supports ASK queries - i.e. boolean "yes/no" queries - and CONSTRUCT queries - which allow to construct new RDF graphs from a query result.

Compared to earlier SPARQL1.0 specification [SPARQL1.0 @@@add reference] from 2008, SPARQL1.1 adds a number of new features to the query language, including subqueries, value assignment, path expressions, aggregates, etc.

The SPARQL 1.1 Query Language document defines the syntax and semantics of SPARQL1.1 queries and provides various examples for their usage.

3 Different query results formats supported by SPARQL 1.1 (XML, JSON, CSV, TSV)

Results of SELECT queries in SPARQL comprise bags of mappings from variables to RDF terms, often conveniently represented in tabular form. For instance, the query from Section 2 has the following results:


?person ?name
http://example.org/charlie#me "Charlie"
http://example.org/bob#me "Bob"
http://example.org/marie#me "Marie"


In order to exchange these results in machine-readable form, SPARQL supports four common exchange formats, namely the Extensible Markup Language (XML), the JavaScript Object Notation (JSON), Comma Separated Values (CSV), and Tab Separated Values (TSV). These results formats are described in three different documents:

These documents specify details of how particular solutions and RDF terms occurring in solutions are encoded in the respective target formats.

The results of our example query, in these three formats look as follows.

XML:

<?xml version="1.0"?>
<sparql xmlns="http://www.w3.org/2005/sparql-results#">
 <head>
   <variable name="P"/>
   <variable name="N"/>
 </head>
 <results>
   <result>
     <binding name="P">
       <uri>http://example.org/marie#me</uri>
     </binding>
     <binding name="N">
       <literal>Marie</literal>
     </binding>
   </result>
   <result>
     <binding name="P">
       <uri>http://example.org/charlie#me</uri>
     </binding>
     <binding name="N">
       <literal>Charlie</literal>
     </binding>
   </result>
   <result>
     <binding name="P">
       <uri>http://example.org/bob#me</uri>
     </binding>
     <binding name="N">
       <literal>Bob</literal>
     </binding>
   </result>
 </results>
</sparql>

JSON:

{
  "head": {
    "vars": [ "P" , "N" ]
  } ,
  "results": {
    "bindings": [
      {
        "P": { "type": "uri" , "value": "http://example.org/marie#me" } ,
        "N": { "type": "literal" , "value": "Marie" }
      } ,
      {
        "P": { "type": "uri" , "value": "http://example.org/charlie#me" } ,
        "N": { "type": "literal" , "value": "Charlie" }
      } ,
      {
        "P": { "type": "uri" , "value": "http://example.org/bob#me" } ,
        "N": { "type": "literal" , "value": "Bob" }
      }
    ]
  }
}


CSV: @@@needs to be checked with final versions of CSV/TSV doc.

person,name
http://example.org/marie#me,Marie
http://example.org/charlie#me,Charlie
http://example.org/bob#me,Bob


TSV: @@@needs to be checked with final versions of CSV/TSV doc.

?person \t ?name
<http://example.org/marie#me> \t "Marie"
<http://example.org/charlie#me> \t "Charlie"
<http://example.org/bob#me> \t "Bob"

(Note: TAB characters are visually marked with '\t' here for illustration only.)

4 SPARQL 1.1 Federated Query

The SPARQL 1.1 Federated Query document describes and extension of the basic SPARQL 1.1 Query Language to explicitly delegate certain subqueries to different SPARQL endpoints.

For instance, in our example, one might want to find out identifiers of persons with the same names as Alice' friends on DBPedia, you may want to combine a query for the names of friends with a remote call to the SPARQL endpoint at http://dbpedia.org/sparql using the SERVICE keyword in a query as follows:

PREFIX foaf: <http://xmlns.com/foaf/0.1/>
SELECT ?person
FROM <http://example.org/alice>
WHERE {
    <http://www.example.org/alice#me> foaf:knows [ foaf:name ?name ] .
    SERVICE <http://dbpedia.org/sparql> { ?person foaf:name ?name } 
}

5 SPARQL 1.1 Entailment Regimes

SPARQL could be used together with ontological information in the form of e.g. RDF Schema or OWL axioms. The following query asks for labels of persons:

SELECT ?label 
FROM <http://example.org/alice>
FROM <http://foaf.example.org/>
WHERE { ?person rdfs:label ?label }

In a SPARQL engine that does not consider any special entailment regimes (on top of standard simple entailment) the query above returns only

?label
"Alice"

whereas an RDF Schema aware query engine will return

?label
"Alice"
"Charlie"
"Bob"
"Marie"

since foaf:name is a sub-property of rdfs:label.

The SPARQL 1.1 Entailent Regimes specification defines which answers should be given under which entailment regime, specifying entailment regimes for RDF, RDF Schema, D-Entailment [@@@RDF-Sem], OWL2 [@@@OWL2], and RIF [@@@RIF].

6 SPARQL 1.1 Update Language

The SPARQL 1.1 Update specification defines the syntax and semantics of SPARQL1.1 Update requests and provides various examples for their usage. Update operations can consist of several sequential requests and are performed on a collection of graphs in a Graph Store. Operations are provided to update, create and, remove RDF graphs in a Graph Store.

For instance, the following request inserts a new friend named Dorothy into the graph http://www.example.org/alice and thereafter deletes all email addresses of Alice' friends.

PREFIX : <http://www.example.org/alice#> .
PREFIX foaf: <http://xmlns.com/foaf/0.1/> .

INSERT DATA { GRAPH <http://www.example.org/alice> { :me foaf:knows [ foaf:name "Dorothy" ].  } } ;
DELETE { ?person foaf:mbox ?mbox } WHERE { :me foaf:knows ?person . ?person foaf:mbox  ?mbox .}

As the second operation shows, insertions and deletions can be dependent on the results of queries to the Graph Store; the respective syntax used in the WHERE part is derived from the http://www.w3.org/TR/sparql11-query/ SPARQL1.1 Query Language].

7 SPARQL 1.1 Protocol for RDF

The SPARQL 1.1 Protocol for RDF defines how to transfer SPARQL 1.1 queries and update requests to a SPARQL service via HTTP, definint how to map requests to HTTP Get and Post operations and how respective HTTP responses to such requests should look like.

For instance, the query from Section 3 above issued against a SPARQL query service hosted at http://www.example.org/sparql/, could according to this specification be wrapped into an HTTP Get request (where the query string is URI-encoded):

GET /sparql/?query=PREFIX%20foaf%3A%20%3Chttp%3A%2F%2Fxmlns.com%2Ffoaf%2F0.1%2F%3E%0ASELECT%20%3FP%20WHERE%20%7B%20%3Chttp%3A%2F%2Fwww.example.org%2Falice%23me%3E%20foaf%3Aknows%20%3FP%7D HTTP/1.1
Host: www.example.org
User-agent: my-sparql-client/0.1

Details about response encoding and different operations for query and update requests, as well as supported HTTP methods are described in the Protocol specification.

8 SPARQL 1.1 Service Description

The SPARQL 1.1 Service Description document desribes a method for discovering, and an RDF vocabulary for describing SPARQL services made available via the SPARQL 1.1 Protocol for RDF.

According to this specification, a service endpoint, when accessed via an HTTP Get operation without further (query or update request) parameters should return an RDF description of the service provided. For instance, the following Given the HTTP request:

GET /sparql/ HTTP/1.1
Host: www.example.org

issued against the SPARQL endpoint hosted at http://www.example.org/sparql/ should return and RDF description, using the Service Description vocabulary, providing details about e.g. the default dataset of the respective andpoint, or SPARQL query language features, entailment regimes, etc. supported.

9 SPARQL 1.1 Graph Store HTTP Protocol

For many applications and services that deal with RDF data, the full SPARQL 1.1 Update language might not be required. To this end, the SPARQL 1.1 Graph Store HTTP Protocol provides means to perform certain operations to manage collection of graphs more directly, via the direct use of HTTP operations following REST principles.

For instance, the first part of the Update request in Section 4 above is a simple insertion of triples into an RDF graph. On a service supporting this protocol, such insertion can - instead of via a SPARQL1.1 Update request - directly be performed via an HTTP POST operation taking the RDF triples to be inserted as payload:

POST /rdf-graphs/service?graph=http%3A%2F%2Fwww.example.org%2Falice HTTP/1.1
Host: example.org
Content-Type: text/turtle
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
:me foaf:knows [ foaf:name "Dorothy" ] .


More such direct HTTP operations for modifying RDF graphs (e.g. to use HTTP PUT to replace an entire graph, or HTTP DELET to drop an RDF graph, etc.) are described in the SPARQL 1.1 Graph Store HTTP Protocol specification, which can be viewed as a lightweight alternative to the SPARQL1.1 protocol in combination with the full SPARQL1.1 Query and SPARQL1.1 Update languages.

10 Acknowledgements

The members of the W3C SPARQL Working group who actively contributed to these specifications are:

  • Carlos Buil Aranda, Universidad Politécnica de Madrid
  • Olivier Corby, Institut National de Recherche en Informatique et en Automatique (INRIA)
  • Souripriya Das, Oracle Corporation
  • Lee Feigenbaum, Cambridge Semantics
  • Paul Gearon, Invited Expert
  • Birte Glimm, Oxford University Computing Laboratory
  • Steve Harris, Garlik Ltd
  • Sandro Hawke, W3C
  • Ivan Herman, W3C
  • Nicholas Humfrey, BBC
  • Nico Michaelis, Dreamlab Technologies AG
  • Chimezie Ogbuji, Invited Expert
  • Matthew Perry, Oracle Corporation
  • Alexandre Passant, DERI, National University of Ireland, Galway
  • Axel Polleres, DERI, National University of Ireland, Galway
  • Eric Prud'hommeaux, W3C
  • Andy Seaborne, The Apache Software Foundation
  • Gregory Williams, Rensselaer Polytechnic Institute