SPARQL Query Language for RDF
W3C Recommendation 15 January 2008 
This version: http://www.w3.org/TR/2008/REC­rdf­sparql­query­20080115/  Latest version: http://www.w3.org/TR/rdf­sparql­query/  Previous version: http://www.w3.org/TR/2007/PR­rdf­sparql­query­20071112/  Editors: Eric Prud'hommeaux, W3C <eric@w3.org> Andy Seaborne, Hewlett­Packard Laboratories, Bristol <andy.seaborne@hp.com>  
Please refer to the errata for this document, which may include some normative corrections. 
See also translations. 
Copyright © 2006­2007 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
 
Abstract 
RDF is a directed, labeled graph data format for representing information in the Web. This specification defines the syntax and semantics of the SPARQL query language for RDF. SPARQL can be used to express queries across diverse data sources, whether the data is stored natively as RDF or viewed as RDF via middleware. SPARQL contains capabilities for querying required and optional graph patterns along with their conjunctions and disjunctions. SPARQL also supports extensible value testing and constraining queries by source RDF graph. The results of SPARQL queries can be results sets or RDF graphs. 
Status of This Document
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This is a W3C Recommendation. 
This document has been reviewed by W3C Members, by software developers, and by other W3C groups and interested parties, and is endorsed by the Director as a W3C Recommendation. It is a stable document and may be used as reference material or cited from another document. W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web.
Comments on this document should be sent to public­rdf­dawg­comments@w3.org, a mailing list with a public archive. Questions and comments about SPARQL that are not related to this specification, including extensions and features, can be discussed on the mailing list public­sparql­dev@w3.org, (public archive). 
This document was produced by the RDF Data Access Working Group, which is part of the W3C Semantic Web Activity. The first release of this document as a Working Draft was 12 October 2004 and the Working Group has addressed a number of comments received and issues since then. Two changes have been made and logged since the publication of the November 2007 Proposed Recommendation. 
The Working Group's SPARQL Query Language For RDF Implementation Report demonstrates that the goals for interoperable implementations, set in the June 2007 Candidate Recommendation , were achieved. 
The Data Access Working Group has postponed 12 issues, including aggregate functions, and an update language. 
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy. 
Table of Contents 
1 Introduction  1.1 Document Outline 1.2 Document Conventions 1.2.1 Namespaces  1.2.2 Data Descriptions  1.2.3 Result Descriptions  1.2.4 Terminology  2 Making Simple Queries (Informative) 2.1 Writing a Simple Query  2.2 Multiple Matches  2.3 Matching RDF Literals 2.3.1 Matching Literals with Language Tags  2.3.2 Matching Literals with Numeric Types  2.3.3 Matching Literals with Arbitrary Datatypes  2.4 Blank Node Labels in Query Results  2.5 Building RDF Graphs  3 RDF Term Constraints (Informative) 3.1 Restricting the Value of Strings  3.2 Restricting Numeric Values  3.3 Other Term Constraints  4 SPARQL Syntax 4.1 RDF Term Syntax 4.1.1 Syntax for IRI  4.1.2 Syntax for Literals  4.1.3 Syntax for Variables  4.1.4 Syntax for Blank Nodes  4.2 Syntax for Triple Patterns 4.2.1 Predicate­Object Lists  4.2.2 Object Lists  4.2.3 RDF Collections  4.2.4 rdf:type  5 Graph Patterns5.1 Basic Graph Patterns 5.1.1 Blank Node Labels  5.1.2 Extending Basic Graph Pattern Matching  5.2 Group Graph Patterns 5.2.1 Empty Group Pattern  5.2.2 Scope of Filters  5.2.3 Group Graph Pattern Examples  6 Including Optional Values 6.1 Optional Pattern Matching  6.2 Constraints in Optional Pattern Matching  6.3 Multiple Optional Graph Patterns  7 Matching Alternatives  8 RDF Dataset 8.1 Examples of RDF Datasets  8.2 Specifying RDF Datasets 8.2.1 Specifying the default Graph  8.2.2 Specifying Named Graphs  8.2.3 Combining FROM and FROM NAMED  8.3 Querying the Dataset 8.3.1 Accessing Graph Names  8.3.2 Restricting by Graph IRI  8.3.3 Restricting possible Graph IRIs  8.3.4 Named and Default Graphs  9 Solution Sequences and Modifiers 9.1 ORDER BY  9.2 Projection  9.3 Duplicate Solutions9.3.1 DISTINCT  9.3.2 REDUCED  9.4 OFFSET  9.5 LIMIT  10  Query forms 10.1 SELECT  10.2 CONSTRUCT10.2.1 Templates with Blank Nodes  10.2.2 Accessing Graphs in the RDF Dataset  10.2.3 Solution Modifiers and CONSTRUCT  10.3 ASK  10.4 DESCRIBE (Informative) 10.4.1 Explicit IRIs  10.4.2 Identifying Resources  10.4.3 Descriptions of Resources  11 Testing Values 11.1 Operand Data Types  11.2 Filter Evaluation 11.2.1 Invocation  11.2.2 Effective Boolean Value  11.3 Operator Mapping 11.3.1 Operator Extensibility  11.4 Operator Definitions 11.4.1 bound  11.4.2 isIRI  11.4.3 isBlank  11.4.4 isLiteral  11.4.5 str  11.4.6 lang  11.4.7 datatype  11.4.8 logical­or  11.4.9 logical­and  11.4.10 RDFterm­equal  11.4.11 sameTerm  11.4.12 langMatches  11.4.13 regex  11.5 Constructor Functions  11.6 Extensible Value Testing  12 Definition of SPARQL 12.1 Initial Definitions 12.1.1 RDF Terms  12.1.2 RDF Dataset  12.1.3 Query Variables  12.1.4 Triple Patterns  12.1.5 Basic Graph Patterns  12.1.6 Solution Mappings  12.1.7 Solution Sequence Modifiers  12.2 SPARQL Query 12.2.1 Converting Graph Patterns  12.2.2 Examples of Mapped Graph Patterns  12.2.3 Converting Solution Modifiers  12.3 Basic Graph Patterns 12.3.1 SPARQL Basic Graph Pattern Matching  12.3.2 Treatment of Blank Nodes  12.4 SPARQL Algebra  12.5 SPARQL Evaluation Semantics  12.6 Extending SPARQL Basic Graph Matching  
Appendices 
A SPARQL GrammarA.1 SPARQL Query String References  A.2 Codepoint Escape Sequences  A.3 White Space  A.4 Comments  A.5 IRI References  A.6 Blank Node Labels  A.7 Escape sequences in strings  A.8 Grammar  B Conformance  C Security Considerations (Informative)  D Internet Media Type, File Extension and Macintosh File Type  E References  F Acknowledgements (Informative)  
1 Introduction 
RDF is a directed, labeled graph data format for representing information in the Web. RDF is often used to represent, among other things, personal information, social networks, metadata about digital artifacts, as well as to provide a means of integration over disparate sources of information. This specification defines the syntax and semantics of the SPARQL query language for RDF. 
The SPARQL query language for RDF is designed to meet the use cases and requirements identified by the RDF Data Access Working Group in RDF Data Access Use Cases and Requirements y?UCNR].  
The SPARQL query language is closely related to the following specifications: 
l The SPARQL Protocol for RDF y?SPROT] specification defines the remote protocol for issuing SPARQL queries and receiving the results. 
l The SPARQL Query Results XML Format y?RESULTS] specification defines an XML document format for representing the results of SPARQL SELECT and ASK queries. 
1.1 Document Outline 
Unless otherwise noted in the section heading, all sections and appendices in this document are normative.
This section of the document, section 1, introduces the SPARQL query language specification. It presents the organization of this specification document and the conventions used throughout the specification. 
Section 2 of the specification introduces the SPARQL query language itself via a series of example queries and query results. Section 3 continues the introduction of the SPARQL query language with more examples that demonstrate SPARQL's ability to express constraints on the RDF terms that appear in a query's results.
Section 4 presents details of the SPARQL query language's syntax. It is a companion to the full grammar of the language and defines how grammatical constructs represent IRIs, blank nodes, literals, and variables. Section 4 also defines the meaning of several grammatical constructs that serve as syntactic sugar for more verbose expressions.
Section 5 introduces basic graph patterns and group graph patterns, the building blocks from which more complex SPARQL query patterns are constructed. Sections 6, 7, and 8 present constructs that combine SPARQL graph patterns into larger graph patterns. In particular, Section 6 introduces the ability to make portions of a query optional; Section 7 introduces the ability to express the disjunction of alternative graph patterns; and Section 8 introduces the ability to constrain portions of a query to particular source graphs. Section 8 also presents SPARQL's mechanism for defining the source graphs for a query.
Section 9 defines the constructs that affect the solutions of a query by ordering, slicing, projecting, limiting, and removing duplicates from a sequence of solutions.
Section 10 defines the four types of SPARQL queries that produce results in different forms. 
Section 11 defines SPARQL's extensible value testing framework. It also presents the functions and operators that can be used to constrain the values that appear in a query's results.
Section 12 is a formal definition of the evaluation of SPARQL graph patterns and solution modifiers. 
Appendix A contains the normative definition of the SPARQL query language's syntax, as given by a grammar expressed in EBNF notation. 
1.2 Document Conventions 
1.2.1 Namespaces
In this document, examples assume the following namespace prefix bindings unless otherwise stated:
1.2.2 Data Descriptions
This document uses the Turtle y?TURTLE] data format to show each triple explicitly. Turtle allows IRIs to be abbreviated with prefixes: 
@prefix dc:   <http://purl.org/dc/elements/1.1/> .@prefix :     <http://example.org/book/> .:book1  dc:title  "SPARQL Tutorial" .
1.2.3 Result Descriptions
Result sets are illustrated in tabular form. 
A 'binding' is a pair (variable, RDF term). In this result set, there are three variables: x, y and z (shown as column headers). Each solution is shown as one row in the body of the table.  Here, there is a single solution, in which variable x is bound to "Alice", variable y is bound to 
<http://example/a>, and variable z is not bound to an RDF term. Variables are not required to be bound in a solution.
1.2.4 Terminology
The SPARQL language includes IRIs, a subset of RDF URI References that omits spaces. Note that all IRIs in SPARQL queries are absolute; they may or may not include a fragment identifier y?RFC3987, section 3.1]. IRIs include URIs y?RFC3986] and URLs. The abbreviated forms (relative IRIs and prefixed names) in the SPARQL syntax are resolved to produce absolute IRIs. 
The following terms are defined in RDF Concepts and Abstract Syntax y㸀☀㈀㄀☀⠀㌀㜀㘀? and used in SPARQL: 
l IRI (corresponds to the Concepts and Abstract Syntax term "RDF URI reference")  
l literal  
l lexical form  
l plain literal  
l language tag  
l typed literal  
l datatype IRI (corresponds to the Concepts and Abstract Syntax term "datatype URI")  
l blank node  
2 Making Simple Queries (Informative) 
Most forms of SPARQL query contain a set of triple patterns called a basic graph pattern. Triple patterns are like RDF triples except that each of the subject, predicate and object may be a variable. A basic graph pattern matches a subgraph of the RDF data when RDF terms from that subgraph may be substituted for the variables and the result is RDF graph equivalent to the subgraph.
2.1 Writing a Simple Query 
The example below shows a SPARQL query to find the title of a book from the given data graph. The query consists of two parts: the SELECT clause identifies the variables to appear in the query results, and the WHERE clause provides the basic graph pattern to match against the data graph. The basic graph pattern in this example consists of a single triple pattern with a single variable (?title) in the object position.
Data:
<http://example.org/book/book1> <http://purl.org/dc/elements/1.1/title> "SPARQL Tutorial" .
Query:
SELECT ?titleWHERE{  <http://example.org/book/book1> <http://purl.org/dc/elements/1.1/title> ?title .}    
This query, on the data above, has one solution:
Query Result:
2.2 Multiple Matches 
The result of a query is a solution sequence, corresponding to the ways in which the query's graph pattern matches the data. There may be zero, one or multiple solutions to a query.
Data:
@prefix foaf:  <http://xmlns.com/foaf/0.1/> .
_:a  foaf:name   "Johnny Lee Outlaw" ._:a  foaf:mbox   <mailto:jlow@example.com> ._:b  foaf:name   "Peter Goodguy" ._:b  foaf:mbox   <mailto:peter@example.org> ._:c  foaf:mbox   <mailto:carol@example.org> .
Query:
PREFIX foaf:   <http://xmlns.com/foaf/0.1/>SELECT ?name ?mboxWHERE  { ?x foaf:name ?name .    ?x foaf:mbox ?mbox }
Query Result:
Each solution gives one way in which the selected variables can be bound to RDF terms so that the query pattern matches the data. The result set gives all the possible solutions. In the above example, the following two subsets of the data provided the two matches. 
 _:a foaf:name  "Johnny Lee Outlaw" . _:a foaf:box   <mailto:jlow@example.com> .
 _:b foaf:name  "Peter Goodguy" . _:b foaf:box   <mailto:peter@example.org> .
This is a basic graph pattern match; all the variables used in the query pattern must be bound in every solution. 
2.3 Matching RDF Literals 
The data below contains three RDF literals:
@prefix dt:   <http://example.org/datatype#> .@prefix ns:   <http://example.org/ns#> .@prefix :     <http://example.org/ns#> .@prefix xsd:  <http://www.w3.org/2001/XMLSchema#> . 
:x   ns:p     "cat"@en .:y   ns:p     "42"^^xsd:integer .:z   ns:p     "abc"^^dt:specialDatatype .
Note that, in Turtle, "cat"@en is an RDF literal with a lexical form "cat" and a language en; "42"^^xsd:integer is a typed literal with the datatype http://www.w3.org/2001/XMLSchema#integer; and "abc"^^dt:specialDatatype is a typed literal with the datatype 
http://example.org/datatype#specialDatatype.
This RDF data is the data graph for the query examples in sections 2.3.1–2.3.3. 
2.3.1 Matching Literals with Language Tags
Language tags in SPARQL are expressed using @ and the language tag, as defined in Best Common Practice 47 y?BCP47]. 
This following query has no solution because "cat" is not the same RDF literal as "cat"@en:
SELECT ?v WHERE { ?v ?p "cat" }
but the query below will find a solution where variable v is bound to :x because the language tag is specified and matches the given data:
SELECT ?v WHERE { ?v ?p "cat"@en }
2.3.2 Matching Literals with Numeric Types
Integers in a SPARQL query indicate an RDF typed literal with the datatype xsd:integer. For example: 42 is a shortened form of  
"42"^^<http://www.w3.org/2001/XMLSchema#integer>.
The pattern in the following query has a solution with variable v bound to :y.
SELECT ?v WHERE { ?v ?p 42 }
Section 4.1.2 defines SPARQL shortened forms for xsd:float and xsd:double. 
2.3.3 Matching Literals with Arbitrary Datatypes
The following query has a solution with variable v bound to :z. The query processor does not have to have any understanding of the values in the space of the datatype. Because the lexical form and datatype IRI both match, the literal matches.
SELECT ?v WHERE { ?v ?p "abc"^^<http://example.org/datatype#specialDatatype> }
2.4 Blank Node Labels in Query Results 
Query results can contain blank nodes. Blank nodes in the example result sets in this document are written in the form "_:" followed by a blank node label. 
Blank node labels are scoped to a result set (as defined in "SPARQL Query Results XML Format") or, for the CONSTRUCT query form, the result graph. Use of the same label within a result set indicates the same blank node.
Data: 
@prefix foaf:  <http://xmlns.com/foaf/0.1/> .
_:a  foaf:name   "Alice" ._:b  foaf:name   "Bob" .
Query: 
PREFIX foaf:   <http://xmlns.com/foaf/0.1/>SELECT ?x ?nameWHERE  { ?x foaf:name ?name }
The results above could equally be given with different blank node labels because the labels in the results only indicate whether RDF terms in the solutions are the same or different.
These two results have the same information: the blank nodes used to match the query are different in the two solutions. There need not be any relation between a label _:a in the result set and a blank node in the data graph with the same label.
An application writer should not expect blank node labels in a query to refer to a particular blank node in the data.
2.5 Building RDF Graphs 
SPARQL has several query forms. The SELECT query form returns variable bindings. The CONSTRUCT query form returns an RDF graph. The graph is built based on a template which is used to generate RDF triples based on the results of matching the graph pattern of the query. 
Data:
@prefix org:    <http://example.com/ns#> .
_:a  org:employeeName   "Alice" ._:a  org:employeeId     12345 .
_:b  org:employeeName   "Bob" ._:b  org:employeeId     67890 .
Query:
PREFIX foaf:   <http://xmlns.com/foaf/0.1/>PREFIX org:    <http://example.com/ns#>
CONSTRUCT { ?x foaf:name ?name }WHERE  { ?x org:employeeName ?name }
Results:
@prefix org: <http://example.com/ns#> .      _:x foaf:name "Alice" ._:y foaf:name "Bob" .
which can be serialized in RDF/XML as: 
<rdf:RDF    xmlns:rdf="http://www.w3.org/1999/02/22­rdf­syntax­ns#"     xmlns:foaf="http://xmlns.com/foaf/0.1/"    >  <rdf:Description>    <foaf:name>Alice</foaf:name>  </rdf:Description>  <rdf:Description>    <foaf:name>Bob</foaf:name>  </rdf:Description></rdf:RDF>
3 RDF Term Constraints (Informative) 
Graph pattern matching produces a solution sequence, where each solution has a set of bindings of variables to RDF terms. SPARQL FILTERs restrict solutions to those for which the filter expression evaluates to TRUE.
This section provides an informal introduction to SPARQL FILTERs; their semantics are defined in Section 11. Testing Values. The examples in this section share one input graph:
Data: 
@prefix dc:   <http://purl.org/dc/elements/1.1/> .@prefix :     <http://example.org/book/> .@prefix ns:   <http://example.org/ns#> .
:book1  dc:title  "SPARQL Tutorial" .:book1  ns:price  42 .:book2  dc:title  "The Semantic Web" .:book2  ns:price  23 .
3.1 Restricting the Values of Strings 
SPARQL FILTER functions like regex can test RDF literals. regex matches only plain literals with no language tag. regex can be used to match the lexical forms of other literals by using the str function. 
Query:
PREFIX  dc:  <http://purl.org/dc/elements/1.1/>SELECT  ?titleWHERE   { ?x dc:title ?title          FILTER regex(?title, "^SPARQL")         }
Query Result:
Regular expression matches may be made case­insensitive with the "i" flag. 
Query:
PREFIX  dc:  <http://purl.org/dc/elements/1.1/>SELECT  ?titleWHERE   { ?x dc:title ?title          FILTER regex(?title, "web", "i" )         }
Query Result:
The regular expression language is defined by XQuery 1.0 and XPath 2.0 Functions and Operators and is based on XML Schema Regular Expressions. 
3.2 Restricting Numeric Values 
SPARQL FILTERs can restrict on arithmetic expressions.
Query:
PREFIX  dc:  <http://purl.org/dc/elements/1.1/>PREFIX  ns:  <http://example.org/ns#>SELECT  ?title ?priceWHERE   { ?x ns:price ?price .          FILTER (?price < 30.5)          ?x dc:title ?title . }
Query Result:
By constraining the price variable, only :book2 matches the query because only :book2 has a price less than 30.5, as the filter condition requires. 
3.3 Other Term Constraints 
In addition to numeric types, SPARQL supports types xsd:string, xsd:boolean and xsd:dateTime (see 11.1 Operand Data Types). 11.3 Operator Mapping lists a set of test functions, including BOUND, isLITERAL and langMATCHES and accessors, including STR, LANG and 
DATATYPE. 11.5 Constructor Functions lists a set of XML Schema constructor functions that are in the SPARQL language to cast values from one type to another.
4 SPARQL Syntax 
This section covers the syntax used by SPARQL for RDF terms and triple patterns. The full grammar is given in appendix A. 
4.1 RDF Term Syntax 
4.1.1 Syntax for IRIs
The IRIref production designates the set of IRIs y?RFC3987]; IRIs are a generalization of URIs y?RFC3986] and are fully compatible with URIs and URLs. The PrefixedName production designates a prefixed name. The mapping from a prefixed name to an IRI is described below. IRI references (relative or absolute IRIs) are designated by the IRI_REF production, where the '<' and '>' delimiters do not form part of the IRI reference. Relative IRIs match the irelative­ref reference in section 2.2 ABNF for IRI References and IRIs in y?RFC3987] and are resolved to IRIs as described below.
Grammar rules:
The set of RDF terms defined in RDF Concepts and Abstract Syntax includes RDF URI references while SPARQL terms include IRIs. RDF URI references containing "<", ">", '"' (double quote), space, "{", "}", "|", "\", "^", and "`" are not IRIs. The behavior of a SPARQL query against RDF statements composed of such RDF URI references is not defined.
Prefixed names
The PREFIX keyword associates a prefix label with an IRI. A prefixed name is a prefix label and a local part, separated by a colon ":". A prefixed name is mapped to an IRI by concatenating the IRI associated with the prefix and the local part. The prefix label or the local part may be empty. Note that SPARQL local names allow leading digits while XML local names do not. 
Relative IRIs
Relative IRIs are combined with base IRIs as per Uniform Resource Identifier (URI): Generic Syntax y?RFC3986] using only the basic algorithm in Section 5.2 . Neither Syntax­Based Normalization nor Scheme­Based Normalization (described in sections 6.2.2 and 6.2.3 of RFC3986) are performed. Characters additionally allowed in IRI references are treated in the same way that unreserved characters are treated in URI references, per section 6.5 of Internationalized Resource Identifiers (IRIs) y?RFC3987]. 
The BASE keyword defines the Base IRI used to resolve relative IRIs per RFC3986 section 5.1.1, "Base URI Embedded in Content". Section 5.1.2, "Base URI from the Encapsulating Entity" defines how the Base IRI may come from an encapsulating document, such as a SOAP envelope with an xml:base directive or a mime multipart document with a Content­Location header. The "Retrieval URI" identified in 5.1.3, Base "URI from the Retrieval URI", is the URL from which a particular SPARQL query was retrieved. If none of the above specifies the Base URI, the default Base URI (section 5.1.4, "Default Base URI") is used.
The following fragments are some of the different ways to write the same IRI:
<http://example.org/book/book1>
BASE <http://example.org/book/><book1>
PREFIX book: <http://example.org/book/>book:book1
4.1.2 Syntax for Literals
The general syntax for literals is a string (enclosed in either double quotes, "...", or single quotes, '...'), with either an optional language tag (introduced by @) or an optional datatype IRI or prefixed name (introduced by ^^).
As a convenience, integers can be written directly (without quotation marks and an explicit datatype IRI) and are interpreted as typed literals of datatype xsd:integer; decimal numbers for which there is '.' in the number but no exponent are interpreted as xsd:decimal; and numbers with exponents are interpreted as xsd:double. Values of type xsd:boolean can also be written as true or false.
To facilitate writing literal values which themselves contain quotation marks or which are long and contain newline characters, SPARQL provides an additional quoting construct in which literals are enclosed in three single­ or double­quotation marks. 
Examples of literal syntax in SPARQL include:
l "chat" 
l 'chat'@fr with language tag "fr" 
l "xyz"^^<http://example.org/ns/userDatatype> 
l "abc"^^appNS:appDataType 
l '''The librarian said, "Perhaps you would enjoy 'War and Peace'."''' 
l 1, which is the same as "1"^^xsd:integer 
l 1.3, which is the same as "1.3"^^xsd:decimal 
l 1.300, which is the same as "1.300"^^xsd:decimal 
l 1.0e6, which is the same as "1.0e6"^^xsd:double 
l true, which is the same as "true"^^xsd:boolean 
l false, which is the same as "false"^^xsd:boolean 
Grammar rules:
Tokens matching the productions INTEGER, DECIMAL, DOUBLE and BooleanLiteral are equivalent to a typed literal with the lexical value of the token and the corresponding datatype (xsd:integer, xsd:decimal, xsd:double, xsd:boolean). 
4.1.3 Syntax for Query Variables
Query variables in SPARQL queries have global scope; use of a given variable name anywhere in a query identifies the same variable. Variables are prefixed by either "?" or "$"; the "?" or "$" is not part of the variable name. In a query, $abc and ?abc identify the same variable. The possible names for variables are given in the SPARQL grammar. 
Grammar rules:
4.1.4 Syntax for Blank Nodes
Blank nodes in graph patterns act as non­distinguished variables, not as references to specific blank nodes in the data being queried. 
Blank nodes are indicated by either the label form, such as "_:abc", or the abbreviated form "y㸀?". A blank node that is used in only one place in the query syntax can be indicated with y㸀?. A unique blank node will be used to form the triple pattern. Blank node labels are written as "_:abc" for a blank node with label "abc". The same blank node label cannot be used in two different basic graph patterns in the same query.
The y㸀ᴀ匀̀ᴀ夀? construct can be used in triple patterns. It creates a blank node label which is used as the subject of all contained predicate­object pairs. The created blank node can also be used in further triple patterns in the subject and object positions.
The following two forms
y㸀̀ᴀ匀̀Ԁ夀Ԁ̀䀀̀?
y㸀䀀̀ᴀ匀̀Ԁ夀Ԁ̀?
allocate a unique blank node label (here "b57") and are equivalent to writing:
_:b57 :p "v" .
This allocated blank node label can be used as the subject or object of further triple patterns. For example, as a subject: 
y㸀̀ᴀ匀̀Ԁ夀Ԁ̀䀀̀ᴀ吀̀Ԁ娀Ԁ̀?
which is equivalent to the two triples:
_:b57 :p "v" ._:b57 :q "w" .
and as an object:
:x :q y㸀̀ᴀ匀̀Ԁ夀Ԁ̀䀀̀?
which is equivalent to the two triples:
:x  :q _:b57 ._:b57 :p "v" .
Abbreviated blank node syntax can be combined with other abbreviations for common subjects and common predicates. 
  y㸀̀䤀刀䐀䤀ᴀ儀䐀倀䠀̀̀∀儀䐀倀䠀̀?    foaf:mbox  <mailto:alice@example.org> ]
This is the same as writing the following basic graph pattern for some uniquely allocated blank node label, "b18":
  _:b18  foaf:name  ?name .  _:b18  foaf:mbox  <mailto:alice@example.org> .
Grammar rules:
4.2 Syntax for Triple Patterns 
Triple Patterns are written as a whitespace­separated list of a subject, predicate and object; there are abbreviated ways of writing some common triple pattern constructs.
The following examples express the same query:
PREFIX  dc: <http://purl.org/dc/elements/1.1/>SELECT  ?titleWHERE   { <http://example.org/book/book1> dc:title ?title }  
PREFIX  dc: <http://purl.org/dc/elements/1.1/>PREFIX  : <http://example.org/book/>
SELECT  $titleWHERE   { :book1  dc:title  $title }
BASE    <http://example.org/book/>PREFIX  dc: <http://purl.org/dc/elements/1.1/>
SELECT  $titleWHERE   { <book1>  dc:title  ?title }
Grammar rules:
4.2.1 Predicate­Object Lists 
Triple patterns with a common subject can be written so that the subject is only written once and is used for more than one triple pattern by employing the ";" notation.
    ?x  foaf:name  ?name ;        foaf:mbox  ?mbox .
This is the same as writing the triple patterns:
    ?x  foaf:name  ?name .    ?x  foaf:mbox  ?mbox .
4.2.2 Object Lists
If triple patterns share both subject and predicate, the objects may be separated by ",".
    ?x foaf:nick  "Alice" , "Alice_" .
is the same as writing the triple patterns:
   ?x  foaf:nick  "Alice" .   ?x  foaf:nick  "Alice_" .
Object lists can be combined with predicate­object lists: 
   ?x  foaf:name ?name ; foaf:nick  "Alice" , "Alice_" .
is equivalent to:
   ?x  foaf:name  ?name .   ?x  foaf:nick  "Alice" .   ?x  foaf:nick  "Alice_" .
4.2.3 RDF Collections
RDF collections can be written in triple patterns using the syntax "(element1 element2 ...)". The form "()" is an alternative for the IRI 
http://www.w3.org/1999/02/22­rdf­syntax­ns#nil. When used with collection elements, such as (1 ?x 3 4), triple patterns with blank nodes are allocated for the collection. The blank node at the head of the collection can be used as a subject or object in other triple patterns. The blank nodes allocated by the collection syntax do not occur elsewhere in the query.
(1 ?x 3 4) :p "w" .
is syntactic sugar for (noting that b0, b1, b2 and b3 do not occur anywhere else in the query):
    _:b0  rdf:first  1 ;          rdf:rest   _:b1 .    _:b1  rdf:first  ?x ;          rdf:rest   _:b2 .    _:b2  rdf:first  3 ;          rdf:rest   _:b3 .    _:b3  rdf:first  4 ;          rdf:rest   rdf:nil .    _:b0  :p         "w" . 
RDF collections can be nested and can involve other syntactic forms:
(1 y㸀ᴀ匀̀ᴀ吀䀀̀଀̀ᔀ̀ఀ̀ఀ̀?
is syntactic sugar for:
    _:b0  rdf:first  1 ;          rdf:rest   _:b1 .    _:b1  rdf:first  _:b2 .    _:b2  :p         :q .    _:b1  rdf:rest   _:b3 .    _:b3  rdf:first  _:b4 .    _:b4  rdf:first  2 ;          rdf:rest   rdf:nil .    _:b3  rdf:rest   rdf:nil .
Grammar rules:
4.2.4 rdf:type
The keyword "a" can be used as a predicate in a triple pattern and is an alternative for the IRI  http://www.w3.org/1999/02/22­rdf­
syntax­ns#type. This keyword is case­sensitive. 
  ?x  a  :Class1 .  y㸀̀䐀̀ᴀ䐀匀匀☀伀䐀嘀嘀̀䀀̀ᴀ匀̀Ԁ夀Ԁ̀?
is syntactic sugar for:
  ?x    rdf:type  :Class1 .  _:b0  rdf:type  :appClass .  _:b0  :p        "v" .
5 Graph Patterns 
SPARQL is based around graph pattern matching. More complex graph patterns can be formed by combining smaller patterns in various ways:
l Basic Graph Patterns, where a set of triple patterns must match  
l Group Graph Pattern, where a set of graph patterns must all match  
l Optional Graph patterns, where additional patterns may extend the solution  
l Alternative Graph Pattern, where two or more possible patterns are tried  
l Patterns on Named Graphs, where patterns are matched against named graphs  
In this section we describe the two forms that combine patterns by conjunction: basic graph patterns, which combine triples patterns, and group graph patterns, which combine all other graph patterns.
The outer­most graph pattern in a query is called the query pattern. It is grammatically identified by GroupGraphPattern in 
5.1 Basic Graph Patterns 
Basic graph patterns are sets of triple patterns. SPARQL graph pattern matching is defined in terms of combining the results from matching basic graph patterns.
A sequence of triple patterns interrupted by a filter comprises a single basic graph pattern. Any graph pattern terminates a basic graph pattern.
5.1.1 Blank Node Labels
When using blank nodes of the form _:abc,  labels for blank nodes are scoped to the basic graph pattern.  A label can be used in only a single basic graph pattern in any query. 
5.1.2 Extending Basic Graph Pattern Matching
SPARQL is defined for matching RDF graphs with simple entailment. SPARQL can be extended to other forms of entailment given certain conditions as described below.  
5.2 Group Graph Patterns 
In a SPARQL query string, a group graph pattern is delimited with braces: {}. For example, this query's query pattern is a group graph pattern of one basic graph pattern.
PREFIX foaf:    <http://xmlns.com/foaf/0.1/>SELECT ?name ?mboxWHERE  {          ?x foaf:name ?name .          ?x foaf:mbox ?mbox .       }
The same solutions would be obtained from a query that grouped the triple patterns into two basic graph patterns. For example, the query below has a different structure but would yield the same solutions as the previous query: 
PREFIX foaf:    <http://xmlns.com/foaf/0.1/>SELECT ?name ?mboxWHERE  { { ?x foaf:name ?name . }         { ?x foaf:mbox ?mbox . }       }
Grammar rules:
5.2.1 Empty Group Pattern
The group pattern:
{ }
matches any graph (including the empty graph) with one solution that does not bind any variables. For example:
SELECT ?xWHERE {}
matches with one solution in which variable x is not bound.
5.2.2 Scope of Filters
A constraint, expressed by the keyword FILTER, is a restriction on solutions over the whole group in which the filter appears. The following patterns all have the same solutions:
 {  ?x foaf:name ?name .    ?x foaf:mbox ?mbox .    FILTER regex(?name, "Smith") }  
 {  FILTER regex(?name, "Smith")    ?x foaf:name ?name .    ?x foaf:mbox ?mbox . }
 {  ?x foaf:name ?name .    FILTER regex(?name, "Smith")    ?x foaf:mbox ?mbox . }
5.2.3 Group Graph Pattern Examples
  {    ?x foaf:name ?name .    ?x foaf:mbox ?mbox .  }
is a group of one basic graph pattern and that basic graph pattern consists of two triple patterns.
  {    ?x foaf:name ?name . FILTER regex(?name, "Smith")    ?x foaf:mbox ?mbox .  }
is a group of one basic graph pattern and a filter, and that basic graph pattern consists of two triple patterns; the filter does not break the basic graph pattern into two basic graph patterns.
  {    ?x foaf:name ?name .    {}    ?x foaf:mbox ?mbox .  }
is a group of three elements, a basic graph pattern of one triple pattern, an empty group, and another basic graph pattern of one triple pattern. 
6 Including Optional Values 
Basic graph patterns allow applications to make queries where the entire query pattern must match for there to be a solution. For every solution of a query containing only group graph patterns with at least one basic graph pattern, every variable is bound to an RDF Term in a solution. However, regular, complete structures cannot be assumed in all RDF graphs. It is useful to be able to have queries that allow information to be added to the solution where the information is available, but do not reject the solution because some part of the query pattern does not match. Optional matching provides this facility: if the optional part does not match, it creates no bindings but does not eliminate the solution.
6.1 Optional Pattern Matching 
Optional parts of the graph pattern may be specified syntactically with the OPTIONAL keyword applied to a graph pattern:
pattern OPTIONAL { pattern } 
The syntactic form:
{ OPTIONAL { pattern } } 
is equivalent to:
{ { } OPTIONAL { pattern } } 
Grammar rule:
The OPTIONAL keyword is left­associative : 
pattern OPTIONAL { pattern } OPTIONAL { pattern } 
is the same as:
{ pattern OPTIONAL { pattern } } OPTIONAL { pattern } 
In an optional match, either the optional graph pattern matches a graph, thereby defining and adding bindings to one or more solutions, or it leaves a solution unchanged without adding any additional bindings.
Data:
@prefix foaf:       <http://xmlns.com/foaf/0.1/> .@prefix rdf:        <http://www.w3.org/1999/02/22­rdf­syntax­ns#> . 
_:a  rdf:type        foaf:Person ._:a  foaf:name       "Alice" ._:a  foaf:mbox       <mailto:alice@example.com> ._:a  foaf:mbox       <mailto:alice@work.example> .
_:b  rdf:type        foaf:Person ._:b  foaf:name       "Bob" .
Query:
PREFIX foaf: <http://xmlns.com/foaf/0.1/>SELECT ?name ?mboxWHERE  { ?x foaf:name  ?name .         OPTIONAL { ?x  foaf:mbox  ?mbox }       }
With the data above, the query result is:
There is no value of mbox in the solution where the name is "Bob".
This query finds the names of people in the data. If there is a triple with predicate mbox and the same subject, a solution will contain the object of that triple as well. In this example, only a single triple pattern is given in the optional match part of the query but, in general, the optional part may be any graph pattern. The entire optional graph pattern must match for the optional graph pattern to affect the query solution.
6.2 Constraints in Optional Pattern Matching 
Constraints can be given in an optional graph pattern. For example:
@prefix dc:   <http://purl.org/dc/elements/1.1/> .@prefix :     <http://example.org/book/> .@prefix ns:   <http://example.org/ns#> .
:book1  dc:title  "SPARQL Tutorial" .:book1  ns:price  42 .:book2  dc:title  "The Semantic Web" .:book2  ns:price  23 .
PREFIX  dc:  <http://purl.org/dc/elements/1.1/>PREFIX  ns:  <http://example.org/ns#>SELECT  ?title ?priceWHERE   { ?x dc:title ?title .          OPTIONAL { ?x ns:price ?price . FILTER (?price < 30) }        }
No price appears for the book with title "SPARQL Tutorial" because the optional graph pattern did not lead to a solution involving the variable "price".
6.3 Multiple Optional Graph Patterns 
Graph patterns are defined recursively. A graph pattern may have zero or more optional graph patterns, and any part of a query pattern may have an optional part. In this example, there are two optional graph patterns.
Data:
@prefix foaf:       <http://xmlns.com/foaf/0.1/> .
_:a  foaf:name       "Alice" ._:a  foaf:homepage   <http://work.example.org/alice/> .
_:b  foaf:name       "Bob" ._:b  foaf:mbox       <mailto:bob@work.example> .
Query:
PREFIX foaf: <http://xmlns.com/foaf/0.1/>SELECT ?name ?mbox ?hpageWHERE  { ?x foaf:name  ?name .         OPTIONAL { ?x foaf:mbox ?mbox } .         OPTIONAL { ?x foaf:homepage ?hpage }       }
Query result:
7 Matching Alternatives 
SPARQL provides a means of combining graph patterns so that one of several alternative graph patterns may match. If more than one of the alternatives matches, all the possible pattern solutions are found.
Pattern alternatives are syntactically specified with the UNION keyword.
Data:
@prefix dc10:  <http://purl.org/dc/elements/1.0/> .@prefix dc11:  <http://purl.org/dc/elements/1.1/> .
_:a  dc10:title     "SPARQL Query Language Tutorial" ._:a  dc10:creator   "Alice" .
_:b  dc11:title     "SPARQL Protocol Tutorial" ._:b  dc11:creator   "Bob" .
_:c  dc10:title     "SPARQL" ._:c  dc11:title     "SPARQL (updated)" .
Query:
PREFIX dc10:  <http://purl.org/dc/elements/1.0/>PREFIX dc11:  <http://purl.org/dc/elements/1.1/>
SELECT ?titleWHERE  { { ?book dc10:title  ?title } UNION { ?book dc11:title  ?title } }
Query result:
This query finds titles of the books in the data, whether the title is recorded using Dublin Core properties from version 1.0 or version 1.1. To determine exactly how the information was recorded, a query could use different variables for the two alternatives:
PREFIX dc10:  <http://purl.org/dc/elements/1.0/>PREFIX dc11:  <http://purl.org/dc/elements/1.1/>
SELECT ?x ?yWHERE  { { ?book dc10:title ?x } UNION { ?book dc11:title  ?y } }
This will return results with the variable x bound for solutions from the left branch of the UNION, and y bound for the solutions from the right branch. If neither part of the UNION pattern matched, then the graph pattern would not match.
The UNION pattern combines graph patterns; each alternative possibility can contain more than one triple pattern:
PREFIX dc10:  <http://purl.org/dc/elements/1.0/>PREFIX dc11:  <http://purl.org/dc/elements/1.1/>
SELECT ?title ?authorWHERE  { { ?book dc10:title ?title .  ?book dc10:creator ?author }         UNION         { ?book dc11:title ?title .  ?book dc11:creator ?author }       }
This query will only match a book if it has both a title and creator predicate from the same version of Dublin Core.
Grammar rule:
8 RDF Dataset 
The RDF data model expresses information as graphs consisting of triples with subject, predicate and object. Many RDF data stores hold multiple RDF graphs and record information about each graph, allowing an application to make queries that involve information from more than one graph.
A SPARQL query is executed against an RDF Dataset which represents a collection of graphs. An RDF Dataset comprises one graph, the default graph, which does not have a name, and zero or more named graphs, where each named graph is identified by an IRI. A SPARQL query can match different parts of the query pattern against different graphs as described in section 8.3 Querying the Dataset.  
An RDF Dataset may contain zero named graphs; an RDF Dataset always contains one default graph. A query does not need to involve matching the default graph; the query can just involve matching named graphs.
The graph that is used for matching a basic graph pattern is the active graph. In the previous sections, all queries have been shown executed against a single graph, the default graph of an RDF dataset as the active graph. The GRAPH keyword is used to make the active graph one of all of the named graphs in the dataset for part of the query.
8.1 Examples of RDF Datasets 
The definition of RDF Dataset does not restrict the relationships of named and default graphs. Information can be repeated in different graphs; relationships between graphs can be exposed. Two useful arrangements are:
l to have information in the default graph that includes provenance information about the named graphs 
l to include the information in the named graphs in the default graph as well. 
Example 1:
# Default graph @prefix dc: <http://purl.org/dc/elements/1.1/> .
<http://example.org/bob>    dc:publisher  "Bob" .<http://example.org/alice>  dc:publisher  "Alice" .
# Named graph: http://example.org/bob @prefix foaf: <http://xmlns.com/foaf/0.1/> .
_:a foaf:name "Bob" ._:a foaf:mbox <mailto:bob@oldcorp.example.org> .
# Named graph: http://example.org/alice @prefix foaf: <http://xmlns.com/foaf/0.1/> .
_:a foaf:name "Alice" ._:a foaf:mbox <mailto:alice@work.example.org> .
In this example, the default graph contains the names of the publishers of two named graphs. The triples in the named graphs are not visible in the default graph in this example.
Example 2:
RDF data can be combined by the RDF merge y?RDF­MT] of graphs. One possible arrangement of graphs in an RDF Dataset is to have the default graph be the RDF merge of some or all of the information in the named graphs.
In this next example, the named graphs contain the same triples as before. The RDF dataset includes an RDF merge of the named graphs in the default graph, re­labeling blank nodes to keep them distinct. 
# Default graph @prefix foaf: <http://xmlns.com/foaf/0.1/> .
_:x foaf:name "Bob" ._:x foaf:mbox <mailto:bob@oldcorp.example.org> .
_:y foaf:name "Alice" ._:y foaf:mbox <mailto:alice@work.example.org> .
# Named graph: http://example.org/bob @prefix foaf: <http://xmlns.com/foaf/0.1/> .
_:a foaf:name "Bob" ._:a foaf:mbox <mailto:bob@oldcorp.example.org> .
# Named graph: http://example.org/alice @prefix foaf: <http://xmlns.com/foaf/0.1/> .
_:a foaf:name "Alice" ._:a foaf:mbox <mailto:alice@work.example> . 
In an RDF merge, blank nodes in the merged graph are not shared with blank nodes from the graphs being merged.
8.2 Specifying RDF Datasets 
A SPARQL query may specify the dataset to be used for matching by using the FROM clause and the FROM NAMED clause to describe the RDF dataset. If a query provides such a dataset description, then it is used in place of any dataset that the query service would use if no dataset description is provided in a query. The RDF dataset may also be specified in a SPARQL protocol request, in which case the protocol description overrides any description in the query itself. A query service may refuse a query request if the dataset description is not acceptable to the service.
The FROM and FROM NAMED keywords allow a query to specify an RDF dataset by reference; they indicate that the dataset should include graphs that are obtained from representations of the resources identified by the given IRIs (i.e. the absolute form of the given IRI references). The dataset resulting from a number of FROM and FROM NAMED clauses is:
l a default graph consisting of the RDF merge of the graphs referred to in the FROM clauses, and 
l a set of (IRI, graph) pairs, one from each FROM NAMED clause. 
If there is no FROM clause, but there is one or more FROM NAMED clauses, then the dataset includes an empty graph for the default graph.
Grammar rules:
8.2.1 Specifying the Default Graph
Each FROM clause contains an IRI that indicates a graph to be used to form the default graph. This does not put the graph in as a named graph.
In this example, the RDF Dataset contains a single default graph and no named graphs:
# Default graph (stored at http://example.org/foaf/aliceFoaf) @prefix  foaf:  <http://xmlns.com/foaf/0.1/> .
_:a  foaf:name     "Alice" ._:a  foaf:mbox     <mailto:alice@work.example> .
PREFIX foaf: <http://xmlns.com/foaf/0.1/>SELECT  ?nameFROM    <http://example.org/foaf/aliceFoaf>WHERE   { ?x foaf:name ?name }
If a query provides more than one FROM clause, providing more than one IRI to indicate the default graph, then the default graph is based on the RDF merge of the graphs obtained from representations of the resources identified by the given IRIs. 
8.2.2 Specifying Named Graphs
A query can supply IRIs for the named graphs in the RDF Dataset using the FROM NAMED clause. Each IRI is used to provide one named graph in the RDF Dataset. Using the same IRI in two or more FROM NAMED clauses results in one named graph with that IRI appearing in the dataset.
# Graph: http://example.org/bob @prefix foaf: <http://xmlns.com/foaf/0.1/> .
_:a foaf:name "Bob" ._:a foaf:mbox <mailto:bob@oldcorp.example.org> .
# Graph: http://example.org/alice @prefix foaf: <http://xmlns.com/foaf/0.1/> .
_:a foaf:name "Alice" ._:a foaf:mbox <mailto:alice@work.example> .
...FROM NAMED <http://example.org/alice>FROM NAMED <http://example.org/bob>...
The FROM NAMED syntax suggests that the IRI identifies the corresponding graph, but the relationship between an IRI and a graph in an RDF dataset is indirect. The IRI identifies a resource, and the resource is represented by a graph (or, more precisely: by a document that serializes a graph). For further details see y?WEBARCH]. 
8.2.3 Combining FROM and FROM NAMED
The FROM clause and FROM NAMED clause can be used in the same query.
# Default graph (stored at http://example.org/dft.ttl) @prefix dc: <http://purl.org/dc/elements/1.1/> .
<http://example.org/bob>    dc:publisher  "Bob Hacker" .<http://example.org/alice>  dc:publisher  "Alice Hacker" .
# Named graph: http://example.org/bob @prefix foaf: <http://xmlns.com/foaf/0.1/> .
_:a foaf:name "Bob" ._:a foaf:mbox <mailto:bob@oldcorp.example.org> .
# Named graph: http://example.org/alice @prefix foaf: <http://xmlns.com/foaf/0.1/> .
_:a foaf:name "Alice" ._:a foaf:mbox <mailto:alice@work.example.org> .
PREFIX foaf: <http://xmlns.com/foaf/0.1/>PREFIX dc: <http://purl.org/dc/elements/1.1/>
SELECT ?who ?g ?mboxFROM <http://example.org/dft.ttl>FROM NAMED <http://example.org/alice>FROM NAMED <http://example.org/bob>WHERE{   ?g dc:publisher ?who .   GRAPH ?g { ?x foaf:mbox ?mbox }}
The RDF Dataset for this query contains a default graph and two named graphs. The GRAPH keyword is described below.
The actions required to construct the dataset are not determined by the dataset description alone. If an IRI is given twice in a dataset description, either by using two FROM clauses, or a FROM clause and a FROM NAMED clause, then it does not assume that exactly one or exactly two attempts are made to obtain an RDF graph associated with the IRI. Therefore, no assumptions can be made about blank node identity in triples obtained from the two occurrences in the dataset description. In general, no assumptions can be made about the equivalence of the graphs. 
8.3 Querying the Dataset 
When querying a collection of graphs, the GRAPH keyword is used to match patterns against named graphs. GRAPH can provide an IRI to select one graph or use a variable which will range over the IRI of all the named graphs in the query's RDF dataset.
The use of GRAPH changes the active graph for matching basic graph patterns within part of the query. Outside the use of GRAPH, the default graph is matched by basic graph patterns.
The following two graphs will be used in examples:
# Named graph: http://example.org/foaf/aliceFoaf @prefix  foaf:     <http://xmlns.com/foaf/0.1/> .@prefix  rdf:      <http://www.w3.org/1999/02/22­rdf­syntax­ns#> . @prefix  rdfs:     <http://www.w3.org/2000/01/rdf­schema#> . 
_:a  foaf:name     "Alice" ._:a  foaf:mbox     <mailto:alice@work.example> ._:a  foaf:knows    _:b .
_:b  foaf:name     "Bob" ._:b  foaf:mbox     <mailto:bob@work.example> ._:b  foaf:nick     "Bobby" ._:b  rdfs:seeAlso  <http://example.org/foaf/bobFoaf> .
<http://example.org/foaf/bobFoaf>     rdf:type      foaf:PersonalProfileDocument .
# Named graph: http://example.org/foaf/bobFoaf @prefix  foaf:     <http://xmlns.com/foaf/0.1/> .@prefix  rdf:      <http://www.w3.org/1999/02/22­rdf­syntax­ns#> . @prefix  rdfs:     <http://www.w3.org/2000/01/rdf­schema#> . 
_:z  foaf:mbox     <mailto:bob@work.example> ._:z  rdfs:seeAlso  <http://example.org/foaf/bobFoaf> ._:z  foaf:nick     "Robert" .
<http://example.org/foaf/bobFoaf>     rdf:type      foaf:PersonalProfileDocument .
Grammar rule:
8.3.1 Accessing Graph Names
The query below matches the graph pattern against each of the named graphs in the dataset and forms solutions which have the src variable bound to IRIs of the graph being matched. The graph pattern is matched with the active graph being each of the named graphs in the dataset. 
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
SELECT ?src ?bobNickFROM NAMED <http://example.org/foaf/aliceFoaf>FROM NAMED <http://example.org/foaf/bobFoaf>WHERE  {    GRAPH ?src    { ?x foaf:mbox <mailto:bob@work.example> .      ?x foaf:nick ?bobNick    }  }
The query result gives the name of the graphs where the information was found and the value for Bob's nick:
8.3.2 Restricting by Graph IRI
The query can restrict the matching applied to a specific graph by supplying the graph IRI. This sets the active graph to the graph named by the IRI. This query looks for Bob's nick as given in the graph http://example.org/foaf/bobFoaf.
PREFIX foaf: <http://xmlns.com/foaf/0.1/>PREFIX data: <http://example.org/foaf/>
SELECT ?nickFROM NAMED <http://example.org/foaf/aliceFoaf>FROM NAMED <http://example.org/foaf/bobFoaf>WHERE  {     GRAPH data:bobFoaf {         ?x foaf:mbox <mailto:bob@work.example> .         ?x foaf:nick ?nick }  }
which yields a single solution:
8.3.3 Restricting Possible Graph IRIs
A variable used in the GRAPH clause may also be used in another GRAPH clause or in a graph pattern matched against the default graph in the dataset.
The query below uses the graph with IRI http://example.org/foaf/aliceFoaf to find the profile document for Bob; it then matches another pattern against that graph. The pattern in the second GRAPH clause finds the blank node (variable w) for the person with the same mail box (given by variable mbox) as found in the first GRAPH clause (variable whom), because the blank node used to match for variable whom from Alice's FOAF file is not the same as the blank node in the profile document (they are in different graphs).
PREFIX  data:  <http://example.org/foaf/>PREFIX  foaf:  <http://xmlns.com/foaf/0.1/>PREFIX  rdfs:  <http://www.w3.org/2000/01/rdf­schema#> 
SELECT ?mbox ?nick ?ppdFROM NAMED <http://example.org/foaf/aliceFoaf>FROM NAMED <http://example.org/foaf/bobFoaf>WHERE{  GRAPH data:aliceFoaf  {    ?alice foaf:mbox <mailto:alice@work.example> ;           foaf:knows ?whom .    ?whom  foaf:mbox ?mbox ;           rdfs:seeAlso ?ppd .    ?ppd  a foaf:PersonalProfileDocument .  } .  GRAPH ?ppd  {      ?w foaf:mbox ?mbox ;         foaf:nick ?nick  }}
Any triple in Alice's FOAF file giving Bob's nick is not used to provide a nick for Bob because the pattern involving variable nick is restricted by ppd to a particular Personal Profile Document.
8.3.4 Named and Default Graphs
Query patterns can involve both the default graph and the named graphs. In this example, an aggregator has read in a Web resource on two different occasions. Each time a graph is read into the aggregator, it is given an IRI by the local system. The graphs are nearly the same but the email address for "Bob" has changed.
In this example, the default graph is being used to record the provenance information and the RDF data actually read is kept in two separate graphs, each of which is given a different IRI by the system. The RDF dataset consists of two named graphs and the information about them. 
RDF Dataset:
# Default graph @prefix dc: <http://purl.org/dc/elements/1.1/> .@prefix g:  <tag:example.org,2005­06­06:> . @prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
g:graph1 dc:publisher "Bob" .g:graph1 dc:date "2004­12­06"^^xsd:date . 
g:graph2 dc:publisher "Bob" .g:graph2 dc:date "2005­01­10"^^xsd:date . 
# Graph: locally allocated IRI: tag:example.org,2005­06­06:graph1 @prefix foaf: <http://xmlns.com/foaf/0.1/> .
_:a foaf:name "Alice" ._:a foaf:mbox <mailto:alice@work.example> .
_:b foaf:name "Bob" ._:b foaf:mbox <mailto:bob@oldcorp.example.org> .
# Graph: locally allocated IRI: tag:example.org,2005­06­06:graph2 @prefix foaf: <http://xmlns.com/foaf/0.1/> .
_:a foaf:name "Alice" ._:a foaf:mbox <mailto:alice@work.example> .
_:b foaf:name "Bob" ._:b foaf:mbox <mailto:bob@newcorp.example.org> .
This query finds email addresses, detailing the name of the person and the date the information was discovered.
PREFIX foaf: <http://xmlns.com/foaf/0.1/>PREFIX dc:   <http://purl.org/dc/elements/1.1/>
SELECT ?name ?mbox ?dateWHERE  {  ?g dc:publisher ?name ;        dc:date ?date .    GRAPH ?g      { ?person foaf:name ?name ; foaf:mbox ?mbox }  }
The results show that the email address for "Bob" has changed.
The IRI for the date datatype has been abbreviated in the results for clarity.
9 Solution Sequences and Modifiers 
Query patterns generate an unordered collection of solutions, each solution being a partial function from variables to RDF terms. These solutions are then treated as a sequence (a solution sequence), initially in no specific order; any sequence modifiers are then applied to create another sequence. Finally, this latter sequence is used to generate one of the results of a SPARQL query form. 
A solution sequence modifier is one of:
l Order modifier: put the solutions in order  
l Projection modifier: choose certain variables  
l Distinct modifier: ensure solutions in the sequence are unique  
l Reduced modifier: permit elimination of some non­unique solutions  
l Offset modifier: control where the solutions start from in the overall sequence of solutions  
l Limit modifier: restrict the number of solutions  
Modifiers are applied in the order given by the list above.
Grammar rules:
Prefix IRI
rdf: http://www.w3.org/1999/02/22­rdf­syntax­ns#
rdfs: http://www.w3.org/2000/01/rdf­schema#
xsd: http://www.w3.org/2001/XMLSchema#
fn: http://www.w3.org/2005/xpath­functions#
x y z
"Alice" <http://example/a>      
title
"SPARQL Tutorial"
name mbox
"Johnny Lee Outlaw" <mailto:jlow@example.com>
"Peter Goodguy" <mailto:peter@example.org>
   v    
v
<http://example.org/ns#x>
v
<http://example.org/ns#y>
v
<http://example.org/ns#z>
x name
_:c "Alice"
_:d "Bob"
x name
_:r "Alice"
_:s "Bob"
title
"SPARQL Tutorial"
title
"The Semantic Web"
title price
"The Semantic Web" 23
y㸀ᤀᨀ䀀̀?IRIref   ::=   IRI_REF | PrefixedName
y㸀ᤀᬀ䀀̀?PrefixedName   ::=   PNAME_LN | PNAME_NS
y㸀ᤀᰀ䀀̀?BlankNode   ::=   BLANK_NODE_LABEL | ANON
y㸀ᨀጀ䀀̀?IRI_REF   ::=   '<' (y㸀䄀ἀ℀Ԁ帀怀开䄀䌀㼀?­y㸀؀嬀ጀ?­#x20])* '>'
y㸀ᨀ᐀䀀̀?PNAME_NS   ::=   PN_PREFIX? ':'
y㸀ᨀᔀ䀀̀?PNAME_LN   ::=   PNAME_NS PN_LOCAL
y㸀ᤀጀ䀀̀?RDFLiteral   ::=   String ( LANGTAG | ( '^^' IRIref ) )?
y㸀ᤀ᐀䀀̀?NumericLiteral   ::=   NumericLiteralUnsigned |  NumericLiteralPositive |  NumericLiteralNegative
y㸀ᤀᔀ䀀̀?NumericLiteralUnsigned   ::=   INTEGER | DECIMAL | DOUBLE
y㸀ᤀᘀ䀀̀?NumericLiteralPositive   ::=   INTEGER_POSITIVE |  DECIMAL_POSITIVE |  DOUBLE_POSITIVE
y㸀ᤀᜀ䀀̀?NumericLiteralNegative   ::=   INTEGER_NEGATIVE |  DECIMAL_NEGATIVE |  DOUBLE_NEGATIVE
y㸀ᤀ᠀䀀̀?BooleanLiteral   ::=   'true' | 'false'
y㸀ᤀᤀ䀀̀?String   ::=   STRING_LITERAL1 | STRING_LITERAL2 |  STRING_LITERAL_LONG1 | STRING_LITERAL_LONG2
y㸀ᨀᤀ䀀̀?LANGTAG   ::=   '@' y㸀?­zA­Z]+ ('­' y㸀?­zA­Z0­9]+)*
y㸀ᨀᨀ䀀̀?INTEGER   ::=   y㸀?­9]+
y㸀ᨀᬀ䀀̀?DECIMAL   ::=   y㸀?­9]+ '.' y㸀?­9]* | '.' y㸀?­9]+
y㸀ᨀᰀ䀀̀?DOUBLE   ::=   y㸀?­9]+ '.' y㸀?­9]* EXPONENT | '.' (y㸀?­9])+ EXPONENT | (y㸀?­9])+ EXPONENT
y㸀ᬀጀ䀀̀?INTEGER_POSITIVE   ::=   '+' INTEGER
y㸀ᬀ᐀䀀̀?DECIMAL_POSITIVE   ::=   '+' DECIMAL
y㸀ᬀᔀ䀀̀?DOUBLE_POSITIVE   ::=   '+' DOUBLE
y㸀ᬀᘀ䀀̀?INTEGER_NEGATIVE   ::=   '­' INTEGER
y㸀ᬀᜀ䀀̀?DECIMAL_NEGATIVE   ::=   '­' DECIMAL
y㸀ᬀ᠀䀀̀?DOUBLE_NEGATIVE   ::=   '­' DOUBLE
y㸀ᬀᤀ䀀̀?EXPONENT   ::=   y㸀䠀⠀䀀̀尾+­]? y㸀?­9]+
y㸀ᬀᨀ䀀̀?STRING_LITERAL1   ::=   "'" ( (y㸀䄀؀嬀ᔀᨀ؀嬀᠀☀؀嬀␀؀嬀✀䀀ఀ̀开?ECHAR )* "'"
y㸀ᬀᬀ䀀̀?STRING_LITERAL2   ::=   '"' ( (y㸀䄀؀嬀ᔀᔀ؀嬀᠀☀؀嬀␀؀嬀✀䀀ఀ̀开?ECHAR )* '"'
y㸀ᜀᜀ?Var   ::=   VAR1 | VAR2
y㸀ᨀᜀ䀀̀?VAR1   ::=   '?' VARNAME
y㸀ᨀ᠀䀀̀?VAR2   ::=   '$' VARNAME
y㸀ᰀᨀ䀀̀?VARNAME   ::=   ( PN_CHARS_U | y㸀?­9] ) ( PN_CHARS_U | y㸀?­9] | #x00B7 | y㸀؀嬀ጀᘀጀ?­#x036F] | y㸀؀嬀ᔀጀᘀ?­#x2040] )*
y㸀ᘀᰀ䀀̀?BlankNodePropertyList   ::=   'y㸀?PropertyListNotEmpty']'
y㸀ᤀᰀ䀀̀?BlankNode   ::=   BLANK_NODE_LABEL | ANON
y㸀ᨀᘀ䀀̀?BLANK_NODE_LABEL   ::=   '_:' PN_LOCAL
y㸀ᰀᜀ䀀̀?ANON   ::=   'y㸀਀?WS* ']'
y㸀ᘀᔀ䀀̀?TriplesSameSubject   ::=   VarOrTerm PropertyListNotEmpty | TriplesNode PropertyList
y㸀ᘀᘀ䀀̀?PropertyListNotEmpty   ::=   Verb ObjectList ( ';' ( Verb ObjectList )? )*
y㸀ᘀᜀ䀀̀?PropertyList   ::=   PropertyListNotEmpty?
y㸀ᘀ᠀䀀̀?ObjectList   ::=   Object ( ',' Object )*
y㸀ᘀᨀ䀀̀?Verb   ::=   VarOrIRIref | 'a'
y㸀ᜀጀ䀀̀?Collection   ::=   '(' GraphNode+ ')'
y㸀ᰀᔀ䀀̀?NIL   ::=   '(' WS* ')'
y㸀᐀ᘀ䀀̀?WhereClause   ::=   'WHERE'? GroupGraphPattern
y㸀ᔀጀ䀀̀?GroupGraphPattern    ::=   '{' TriplesBlock? ( ( GraphPatternNotTriples | Filter ) '.'? TriplesBlock? )* '}' 
y㸀ᔀ᐀䀀̀?TriplesBlock    ::=   TriplesSameSubject ( '.' TriplesBlock? )? 
y㸀ᔀᔀ䀀̀?GraphPatternNotTriples   ::=   OptionalGraphPattern | GroupOrUnionGraphPattern | GraphGraphPattern 
y㸀ᔀᘀ䀀̀?OptionalGraphPattern   ::=   'OPTIONAL' GroupGraphPattern
name mbox
"Alice" <mailto:alice@example.com>
"Alice" <mailto:alice@work.example>
"Bob"
title price
"SPARQL Tutorial"
"The Semantic Web" 23
name mbox hpage
"Alice" <http://work.example.org/alice/>
"Bob" <mailto:bob@work.example>
title
"SPARQL Protocol Tutorial"
"SPARQL"
"SPARQL (updated)"
"SPARQL Query Language Tutorial"
x y
"SPARQL (updated)"
"SPARQL Protocol Tutorial"
"SPARQL"
"SPARQL Query Language Tutorial"
author title
"Alice" "SPARQL Protocol Tutorial"
"Bob" "SPARQL Query Language Tutorial"
y㸀ᔀ᠀䀀̀?GroupOrUnionGraphPattern   ::=   GroupGraphPattern  ( 'UNION' GroupGraphPattern )*
y㸀ᰀ䀀̀?DatasetClause   ::=   'FROM' ( DefaultGraphClause | NamedGraphClause )
y㸀᐀ጀ䀀̀?DefaultGraphClause   ::=   SourceSelector
y㸀᐀᐀䀀̀?NamedGraphClause   ::=   'NAMED' SourceSelector
y㸀᐀ᔀ䀀̀?SourceSelector   ::=   IRIref
name
"Alice"
y㸀ᔀᜀ䀀̀?GraphGraphPattern   ::=   'GRAPH' VarOrIRIref GroupGraphPattern
src bobNick
<http://example.org/foaf/aliceFoaf> "Bobby"
<http://example.org/foaf/bobFoaf> "Robert"
nick
"Robert"
mbox nick ppd
<mailto:bob@work.example> "Robert" <http://example.org/foaf/bobFoaf>
name mbox date
"Bob" <mailto:bob@oldcorp.example.org> "2004­12­06"^^xsd:date
"Bob" <mailto:bob@newcorp.example.org> "2005­01­10"^^xsd:date
y㸀᠀䀀̀?SelectQuery   ::=   'SELECT' ( 'DISTINCT' | 'REDUCED' )? ( Var+ | '*' ) DatasetClause* WhereClause SolutionModifier