SPARQL Protocol for RDF

Table of Contents

1. Introduction

The Semantic Web is based in part on RDF, which is a flexible and extensible way to represent, and reason about, information describing World Wide Web resources. The promise of the Semantic Web rests in part on the promise of ad hoc, arbitrary data aggregation and integration. RDF is crucial to this promise, as is a uniform means of interacting with remote or local RDF storage services. At present there are many different methods of accessing remote RDF storage servers; and even in those cases where the basic access protocol is based on an existing standard, there is no consensus about protocol features, extensibility points, service descriptions and advertisements, data-passing conventions, etc.

This document describes SPARQL, a protocol for accessing RDF data and for conveying RDF queries from query clients to query processors. The SPARQL Protocol has been designed for compatability with the SPARQL Query Language for RDF but is designed to convey queries from other RDF query languages as well. In what follows the SPARQL protocol is described in two ways: first, as an abstract protocol independent of any concrete realization, implementation, or binding to another protocol; second, as a concrete protocol implementation based on HTTP. Other concrete realizations of the abstract protocol described herein are encouraged.

2. Abstract Protocol

When in this document the words must, must not, should, should not, may and recommended appear as emphasized text, they must be interpreted as described in RFC 2119.

The SPARQL abstract protocol is constituted by its types, operations, and responses.

A. Types

The abstract protocol uses the following types, which fall into three categories: W3C XML Schema types, which are relevant to all abstract protocol operations and borrowed from W3C XML Schema Datatypes; protocol types, which are relevant to abstract protocol operations; and query types, which are relevant to query operations.

W3C XML Schema Types

string

The string datatype represents character strings in XML. The value space of string is the set of finite-length sequences of characters (as defined in [XML 1.0 (Second Edition)]) that match the Char production from [XML 1.0 (Second Edition)]. A character is an atomic unit of communication; it is not further specified except to note that every character has a corresponding Universal Character Set code point, which is an integer.

boolean

The type boolean boolean has the value space required to support the mathematical concept of binary-valued logic: {true, false}.

anyURI

anyURI represents a Uniform Resource Identifier Reference (URI). An anyURI value can be absolute or relative, and may have an optional fragment identifier (i.e., it may be a URI Reference). This type should be used to specify the intention that the value fulfills the role of a URI as defined by RFC 2396, as amended by RFC 2732.

positiveInteger

positiveInteger is derived from nonNegativeInteger by setting the value of minInclusive to be 1. This results in the standard mathematical concept of the positive integer numbers. The value space of positiveInteger is the infinite set {1,2,...}.

Protocol Types

OperationProcessor

An OperationProcessor, which identifies a SPARQL processing service, is an anyURI to which a OperationContext is conveyed.

OperationTarget

An OperationTarget is an RDFGraph or an anyURI which identifies a RDF graph resource and against which a protocol operation is executed.

OperationTargetSet

A OperationTargetSet is a set of one or more distinct OperationTarget.

OperationPoint

An OperationPoint is any anyURI, identifying either an OperationProcessor or an OperationTarget, to which an RDF query, or other protocol operation, is conveyed.

Query Types

RDFGraph

RDFGraph is a canonically serialized RDF graph, that is, instanceOf(http://www.w3.org/1999/02/22-rdf-syntax-ns#). RDF/XML is the canonical way to serialize RDFGraph. There are other, semantically equivalent ways to serialize RDF graphs, and concrete protocols may allow for their use in addition to RDF/XML.

AllGraphTriples

Some abstract protocol operations require a succinct, RDF query language indpendent way to represent the selection of all RDF triples from an RDF graph. The SPARQL abstract protocol uses the asterisk, * (Unicode 002A), as the lexical representation of AllGraphTriples.

RDFGraphQuery

The SPARQL protocol is intended to convey RDF queries from many different RDF query languages. The type defined here, RDFGraphQuery, is a string which represents a legal query from any RDF query language. No grammar is given in this specification for RDFGraphQuery.

DistinctQueryResults

Some RDF query languages support the notion of distinct query results: duplicate query results are winnowed before being returned to the client. DistinctQueryResults is a key-value pair, distinct: boolean, where the value is a boolean: if true, distinct results must be returned to the client; if false, distinct results may not be returned to the client.

LimitQueryResults

Some RDF query languages support the notion of limiting the number of query results; LimitQueryResults is a key-value pair, limit: positiveInteger, where the value is a positiveInteger, which is the maximum number of query results that are to be returned to the client via the protocol.

QueryBundle

A QueryBundle is a set—{RDFGraphQuery | AllGraphTriples | anyURI[, DistinctQueryResults, LimitQueryResults]}—comprised of either an RDFGraphQuery or an AllGraphTriples or an anyURI (which, when dereferenced, returns an RDFGraphQuery); an optional DistinctQueryResults; an optional LimitQueryResults.

BooleanQueryResult

Some RDF query languages, including SPARQL Query Language for RDF, allow for yes-no or boolean queries—called in this document BooleanQueryResult—the results of which is a boolean value.

VariableBindingSet

instanceOf(http://www.w3.org/2001/sw/DataAccess/rf1/)CHANGEME

A well-formed instance of SPARQL Variable Binding Results XML Format, an XML vocabulary for exchanging the variable results format provided by the SPARQL Query Language for RDF.

QueryResult

A QueryResult is either an RDFGraph, BooleanQueryResult, or VariableBindingSet.

B. Responses

The SPARQL Abstract Protocol defines three kinds of response: success, fault, and informational. Success responses indicate that the protocol operation was successfully executed; fault responses indicate that the protocol operation was not successfully executed; informational responses either provide additional information about an abstract protocol operation or describe specific conditions relevant to particular abstract protocol operations.

In response to abstract protocol operations, conforming implementations must return a response type indicating the status of the operation. Additionally, conforming implementations should return an RDF graph describing the response for machine processing. For some kinds of protocol operations, conforming implementations may return more than one response code.

The SPARQL abstract protocol defines the following responses.

C. Operations

The SPARQL Abstract Protocol is made up of two operations: Query and GetGraph.

Passing Arguments by Reference, Value, and Query

On the Web data can be passed from one entity to another in a variety of ways. A datum can be included in a request between entities. Or it can be treated as a first-class web resource, given a dereferenceable URI, and passed by reference—that is, a URI identifying the datum can be included in a request or response between entities, with the shared expectation that the URI will be dereferenced in order to retrieve a representation of the datum. It is desirable for a variety of reasons that the SPARQL Absract Protocol be agnostic as to the various ways in which SPARQL concrete protocol designs may pass data between entities.

In the context of the Web, passing data by reference means passing data—whether queries, query targets, other operation targets, or other data—by way of passing a URI that, when dereferenced, returns a representation of that data. For example, consider the utility of authoritative sets of rules for processing subsets of OWL or RDFS. One way to share such rulesets on the Web is by giving them authoritative, or at least conventionally well-known, URIs, so that they can be retrieved when needed. We anticipate the same utility for stable URIs identifying authoritative or canonical RDF queries, including SPARQL Query Language for RDF queries. And the same considerations that apply to RDF queries are likely to apply to canonical or authoritative RDF graphs.

Alternately, in some situations, it's easier or more elegant to pass data by value, which means here passing data in requests or responses between entities by directly including that data in those requests or responses in some realized representational form. Thus, in some of the protocol operation definitions in this section, it is permissible to include a string that is a valid RDFGraphQuery in some RDF query language grammar. And in other operations it is permissible to include an RDFGraph with or against which some operation is to be performed.

Finally, in yet other situations, it may not be practical either to pass a datum by value, perhaps because the datum is not yet known, or to pass the datum by reference, perhaps because no such URI exists. In some of these situations, it may make good sense to pass the data by query or by "computed value". Passing by query means passing arguments in which the literal representational form is a query that is to be executed against a graph, the QueryResults of which are used in some protocol operation.

The definitions of abstract operations, types, responses presented in this document are such as to constrain SPARQL concrete protocols as little as possible with regard to these ways of passing data on the Web.

Implicit Arguments

All of the abstract protocol operations defined here, with the exception of makeGraph, are equally well conveyed to an RDF graph as to an operation processing service. This specification, therefore, aims to be agnostic as to which kind of entity these operations are conveyed. But in the case where an operation is conveyed to an RDF graph, that RDF graph must be considered the implicit OperationTarget against which the operation is to be executed. Thus, an OperationPoint is defined as an anyURI that identifies either an OperationTarget or an OperationProcessor. If it identifies the latter, then the request must also include either an OperationTarget or an OperationTargetSet. If it identifies the former, then the request may include an OperationTargetSet, and conformant implementations must treat the OperationPoint as the target against which an operation is to be executed. The getOptions operation may be used to determine the type of an OperationPoint.

1. Query

Query(QueryBundle, OperationPoint[, (OperationTarget | OperationTargetSet)]) → {QueryResult, Response}

Identifier: http://www.w3.org/2005/01/sparqlP#Query

Conceptually, the arguments to the Query operation are threefold: (1) the query; (2) an entity responsible for handling the query, in some manner unspecified herein; and (3) the target or targets against which the query is to be executed. The QueryBundle contains or points to, via URI, the query itself, as well as some information about how query results are to be handled: whether some upper bound on the number of returned results is required, and whether results should be distinct. The OperationPoint identifies the entity to which the query is conveyed. The optional OperationTarget or OperationTargetSet identifies the RDF graph or graphs against which the query is to be executed.

The Query operation must convey a query to an OperationPoint and must return the results of the query. The results of the Query operation must include one of these response types: OK, MalformedRequest, Unauthorized, Forbidden, NotFound, OperationPointError, UnsupportedOperation, Unavailable, TemporarilyMoved, or PermanentlyMoved.

For example, Query({*, distinct: true}, http://example/1.rdf) should convey to http://example/1.rdf the AllGraphTriples query to be executed against http://example/1.rdf. However, Query({"select ?a where (?a, rdf:type, foaf:Person)", limit: 5}, http://example2/qsp, {http://example/3.rdf, 2.rdf, http://example2/3.rdf}) does not rely on an implicit identification of the target of the operation; it conveys the query to the OperationPoint http://example2/qsp, to be executed against the target set {http://example/3.rdf, 2.rdf, http://example2/3.rdf}, and it requests that a maximum of 5 query results be returned.

Query is a REQUIRED protocol operation.

2. GetGraph

GetGraph(OperationPoint[, (OperationTarget | OperationTargetSet)]) → (1*RDFGraph, 1*Response)

Identifier: http://www.w3.org/2005/01/sparqlP#GetGraph

GetGraph is a simple operation, essentially requesting a representation of one, or distinct representations of more than one, RDFGraph(s), identified by one or more anyURIs, from an OperationPoint. Thus, GetGraph returns the serialized RDFGraph identified by OperationTarget or all of the separately serialized RDFGraphs identifed by OperationTargetSet. SPARQL concrete protocols should specify expected behavior in the case where one or more members of the OperationTargetSet are unavailable, but one or more are available, for retrieval. The results of the GetGraph operation must include one or more of these response types: OK, MalformedRequest, Unauthorized, Forbidden, NotFound, OperationPointError, UnsupportedOperation, Unavailable, TemporarilyMoved, or PermanentlyMoved.

For example, GetGraph(http://example/qsp, {http://example/1.rdf, http://example/2.rdf/, 3.rdf}) is a request, conveyed to http://example/qsp, for three RDFGraphs: http://example/1.rdf, http://example/2.rdf, and 3.rdf. Likewise, GetGraph(http://example/3.rdf) is a request, conveyed to http://example/3.rdf for the RDFGraph identified by http://example/3.rdf.

GetGraph is an OPTIONAL protocol operation.

3. GetServiceDescription

GetServiceDescription(OperationPoint[, (OperationTarget | OperationTargetSet)]) → (1*RDFGraph, 1*Response)

Identifier: http://www.w3.org/2005/01/sparqlP#GetServiceDescription

The GetServiceDescription operation returns an RDFGraph that describes the protocol and query language options for a particular RDFGraph or for OperationProcessor. The results of the GetServiceDescription operation must include one or more of these response types: OK, MalformedRequest, Unauthorized, Forbidden, NotFound, OperationPointError, UnsupportedOperation, Unavailable, TemporarilyMoved, or PermanentlyMoved.

For example, GetServiceDescription(http://example/qsp) returns—on the assumption that http://example/qsp identifies an OperationProcessor—an RDFGraph describing the protocol and query language options, as well as the available QueryTargets. Likewise, GetServiceDescription(http://example/qsp, 2.rdf) returns an RDFGraph describing the protocol and query language options that may be invoked with 2.rdf as an OperationTarget. Finally, GetServiceDescription(http://example/3.rdf) returns an RDFGraph describing the protocol and query language options that may be invoked with http://example/3.rdf as an OperationPoint or OperationTarget.

GetServiceDescription is an OPTIONAL protocol operation.

3. SPARQL Concrete HTTP Binding

SPARQL HTTP Protocol Types

Mapping SPARQL Abstract Response Types to HTTP Status Codes

Operations

HTTP Query Parameters

If query is present, query-lang must also be present, except where the type of the query is SPARQL...FIXME.

@@ need discussion of each one, but examples work for now to make the point

@@ need to add more examples: non-sparql query example; conditional get; cache-control; authentication; faults; response bodies in RDF; Allow, Expect, Accept-Range

@@ sort out the return types: xml var bindings, rdf subgraphs, var bindings in rdf, booleans

@@ show the alternate query form for queries that are too long to be conveyed via GET and query parameters...

1. Query

1.1 query: One query against one RDF graph. Value of graph is "http://my.example/3.rdf"; value of the query is "SELECT ?a ?b ?c WHERE (?a, ?b, ?c)".

GET /qps?query-lang=http...&graph-id=http%3A%2F%2Fmy.example%2F3.rdf&query=SELECT+%3Fa%2C+%3Fb%2C+%3Fc+WHERE+%28%3Fa%2C+%3Fb%2C+%3Fc%29&distinct=true&limit=10 HTTP/1.1
User-Agent: my-sparql-client/0.0
Host: my.example

200 OK HTTP/1.1
Server: my-sparql-server/0.0
Content-Type: application/xml

<?xml version="1.0" encoding="UTF-8"?>

<results xmlns="http://www.w3.org/2001/sw/DataAccess/rf1/result">
  <result>
    <a uri="http://work.example.org/alice/"/>
    <b uri="http://work.example.org/#name"/>
    <c>Alice</c>
  </result>
  <result> 
    <a uri="http://work.example.org/bob/"/>
    <b uri="http://work.example.org/#name"/>
    <c xml:lang="en">Bob</c>
  </result>
</results>

1.2 query: One query, passed by reference, against one RDF graph

GET /qps?graph=http%3A%2F%2Fmy.example%2F3.rdf&query-uri=http%3%2F%2Fmy.example%2Fquery.spql HTTP/1.1
User-Agent: my-sparql-client/0.0
Host: my.example

200 OK HTTP/1.1
Server: my-sparql-server/0.0
Content-Type: application/rdf+xml

<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF 
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" 
    xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" 
    xmlns:iswc="http://annotation.semanticweb.org/2004/iswc#" 
    xml:base="http://www.mindswap.org/2004/iswc">
  <iswc:InProceedings rdf:ID="server-side-xptr-paper">
    <rdfs:seeAlso rdf:resource="iswc.html"/>
    <iswc:title>A Semantic Web Resource Protocol: XPointer and HTTP</iswc:title>
    <iswc:author rdf:resource="#bijan"/>
    <iswc:author rdf:resource="http://clark.dallas.tx.us/kendall/foaf.rdf"/>
    <iswc:author rdf:resource="#bryan"/>
    <iswc:conference rdf:resource="#ISWC2004"/>
    <iswc:year>2004</iswc:year>
    <iswc:topic rdf:resource="http://annotation.semanticweb.org/2004/iswc#Semantic_Web_Middleware"/>
  </iswc:InProceedings>
</rdf:RDF>

1.3 query: One query against multiple RDF Graphs

GET /qps?graph=2.rdf&graph=4.rdf&graph=http%3A%2F%2Ffoaf.example%2Ffoaf%3fid=50&query=SELECT+%2A HTTP/1.1
User-Agent: my-sparql-client/0.0
Host: my.example

200 OK HTTP/1.1
Server: my-sparql-server/0.0
Content-Type: multipart/mime

2. GetGraph

2.1 GetGraph: Retrieve graph with content negotiation for RDF/XML

GET /qps?graph=1.rdf HTTP/1.1
Accept: application/rdf+xml;q=0.9,text/n3;q=0.2
Accept-Encoding: gzip,deflate,compress;q=0.9
Accept-Charset: utf-8 
User-Agent: my-sparql-client/0.0
Host: my.example

200 OK HTTP/1.1
Server: my-sparql-server/0.0
Content-Type: application/rdf+xml

<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF>...</rdf:RDF>

2.2 GetGraph Retrieve RDF graph with content negotiation for N3

GET /3.rdf HTTP/1.1
Accept: text/n3
Accept-Encoding: gzip,deflate,compress;q=0.9
Accept-Chareset: utf-8
User-Agent: my-sparql-client/0.0
Host: my.example

200 OK HTTP/1.1
Content-Type: text/n3

@prefix foaf:  <http://xmlns.com/foaf/0.1/%gt; .

[]
     foaf:name   "Johnny Lee Outlaw" ;
     foaf:mbox   <mailto:jlow@example.com> .

2.3 GetGraph: Retrieve multiple RDF graphs

GET /qps?graph=2.rdf&graph=4.rdf HTTP/1.1
User-Agent: my-sparql-client/0.0
Host: my.example

200 OK HTTP/1.1
Content-Type: multipart/related
...

3. Terminology

A. Requirements Keywords

A. Abstract Protocol Notation

(Note: I've adapated most of this from the extended EBNF in RFC 2616. Some of the descriptive text below is quoted directly from RFC 2616.)

→

A right-arrow character indicates the return types of a protocol operation.

instanceOf(<anyURI>)

Indicates a well-formed, and optionally valid, instance of an XML vocabulary identified by <URI>. For example, instanceOf(http://www.w3.org/1999/02/22-rdf-syntax-ns#) indicates a well-formed instance of RDF/XML. Representation types other than XML may be expressed in the same notation even if they do not define well-formedness or validity or define it differently than XML.

key: value

Two elements separated by a comma indicates a key-value pair.

A | B

Elements separated by a bar indicate alternatives.

{A, B, C}

Elements enclosed in curly braces and separated by a comma indicate a set of elements.

+(*A, 1*5B)

Elements, including optionals and repetitions, enclosed in +( and ), and separated by commas, indicate a bag—an unordered collection with duplicates.

(*A, 1*5B)

Elements, including optionals and repetitions, enclosed in parentheses, and separated by commas, indicate a list—an ordered collection with duplicates.

C(A, B)

A name followed by elements, including optionals, enclosed in parentheses and separted by commas indicate the arguments of an operation, C.

[A]

Elements enclosed in square brackets indicate optional elements.

*A

The asterisk character preceding an element indicates repetition. The full form is <n>*<m>element indicating at least <n> and at most <m> occurrences of element. Default values are 0 and no-upper-bound so that *(element) allows any number, including zero; 1*element requires at least one; and 1*2element allows one or two.

<n>(A)

Indicates <n> repetitions of A.

[A_B_C]

A string of bold upper case letters, separated by _, enclosed in square brackets indicates the abstract name of some HTTP query parameter.

B. Domain-specific Terms

Client, also Requester

From RFC 2616, "A program that establishes connections for the purpose of sending requests."

SPARQL Client

A program that establishes connections for the purpose of sending SPARQL abstract protocol requests.

Server, also Responder

From RFC 2616, "An application program that accepts connections in order to service requests by sending back responses."

SPARQL Server

A program that accepts connections in order to service SPARQL abstract protocol operations by returning the results of those operations and appropriate response types.

Origin Server

From RFC 2616, "The server on which a given resource resides or is to be created."

Operation Processor Service

There are at least two ways to conceptualize and implement a SPARQL server in a heterogenous environment like the Web. The first way is graph-centric: the resources exposed to SPARQL operations are RDF graphs. The second way is service-centric: the primary resource exposed is a service that receives requests for SPARQL operations and responds accordingly. In this document a service-centric SPARQL server is known as an Operation Processor Service.

Operation Point

A service or graph endpoint; i.e., a class of Web resource, identified by URI, that encompasses both SPARQL Operation Processor Services and RDF graphs. The SPARQL protocol conveys protocol operation requests, including queries, from SPARQL clients to Operation Points and returns the responses to clients.

RDF Query Language

A computer language for querying RDF graphs. For example, SPARQL Query Language for RDF, RDQL, and SeRQL are RDF query languages.

Query

A legal sentence in a particular RDF query language grammar.

RDF triple

From RDF Semantics, 6.1 RDF Triples, "An RDF triple contains three components: the subject, which is an RDF URi reference or a blank node; the predicate, which is an RDF URI reference; [and] the object, which is an RDF URI reference, a literal or a blank node."

Base RDF Triple, also Told RDF Triple

A base or told RDF triple is one that exists explicitly in an RDF graph or knowledge base. For example, in the RDF graph

@prefix triumph:  <http://triumph.example/schema/#> .
@prefix rdfs:    <http://www.w3.org/2000/01/rdf-schema#> .
@prefix rdf:     <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .

<http://triumph.example/part/0d92ie433>
    rdf:type    triumph:part ;
    rdfs:label  "Accelerator Cable MK3" ;
    triumph:part-number  "LCD 100-04BSPT" .

the RDF triple (http://triumph.example/part/0d92ie433, rdf:type, triumph:part) is a told or base triple.

Virtual RDF Triple, also Inferred RDF Triple

A virtual or inferred triple is one that does not exist explicitly in an RDF graph or knowledge base; it exists as a result of some inference or reasoning operation on the graph.

RDF graph

From RDF Semantics, 6.2 RDF Graph, "An RDF graph is a set of RDF triples. The set of nodes of an RDF graph is the set of subjects and objects of triples in the graph."

Abstract Protocol

A set of abstract protocol operations, basic types, and responses for conveying operation requests from clients to servers and for conveying operation results from servers to clients.

Concrete Protocol

A concrete implementation—concrete opereations, types, and responses—of the abstract protocol which may itself be realized by means of another, existing concrete protocol; for example, HTTP or SOAP.

Query Results

Some abstract protocol operations specify results that are to be returned by the server that executes those operations. Query and other operation results are to be distinguished from the response codes that the server may be required to return.

Query Result IMT

The Internet Media Type of a Query Result.

Operation Target Graph

An RDF graph against which a protocol operation, including a query, is to be executed.

8. References

Joseki, DIG, AtomAPI, Annotea Protocol, REST, SS XPtr stuff, HTTP 1.1 spec, TAG URIs, WebArch

9. Acknowledgments

My thanks to members of DAWG, especially Bryan Thompson, Andy Seaborne, and Eric Prud'hommeaux, as well as to my UMD colleagues Bijan Parisa, Jim Hendler, Ron Alford, and the members of the Mindlab Semantic Web Undergraduate Social—all of whom helped make this document possible.

CVS Change Log:

 
$Log: Overview.html,v $
Revision 1.3  2018/10/09 13:31:07  denis
fix validation of xhtml documents

Revision 1.2  2017/10/02 10:30:41  denis
add fixup.js to old specs

Revision 1.1  2005/01/14 16:23:57  matthieu
new entry

Revision 1.14  2005/01/14 15:06:05  eric
result namespace

Revision 1.13  2005/01/14 14:50:24  eric
validated ids with '+' in them

Revision 1.12  2005/01/14 14:39:29  eric
typo

Revision 1.11  2005/01/14 14:37:40  eric
fixed some anchors

Revision 1.10  2005/01/14 02:37:04  eric
+ fixed SOTD per kendall's correction

Revision 1.9  2005/01/13 15:30:08  eric
+ fixed some borken links

Revision 1.8  2005/01/13 14:33:14  eric
+ fixed some more ids

Revision 1.7  2005/01/13 14:32:12  eric
added ids

Revision 1.6  2005/01/13 14:10:23  eric
finished simple XML validation

Revision 1.5  2005/01/13 13:06:51  eric
validating

Revision 1.4  2005/01/13 12:52:44  eric
+ added abstract and SOTD
+ getting into form for TR publication

Revision 1.3  2005/01/13 12:24:15  eric
+ switched to http://www.w3.org/2005/01/sparqlP# namespace
  - concearned that poor editing blurred the distinctinon between the class Query and the parameter query

Revision 1.2  2005/01/13 11:14:25  eric
added change log