SPARQL New Features and Rationale

W3C Editor's Draft

This version:

@@No published version

Latest version:

http://www.w3.org/TR/sparql-features/

Editors:

Kjetil Kjernsmo, Computas AS

Alexandre Passant, DERI Galway at the National University of Ireland, Galway, Ireland

---

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

Abstract

Status of this Document

May Be Superseded

This is an editor's draft of a feature requirement documents for the continued SPARQL language development. This document does NOT represent consensus of the SPARQL WG.

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/.

No Endorsement

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

Patents

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. This document is informative only. 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.

1 Introduction

This document provides an overview of the main new features of SPARQL and their rationale. This is an update to SPARQL adding several new features that have been agreed by the SPARQL WG. These language features were determined based on real applications and user and tool-developer experience.

1.1 List of Features

The following features have been agreed by the SPARQL WG. These features have been grouped into Required and Time-permitting features as follows.

Required features

• Aggregate functions
• Subqueries
• Negation
• Project expressions
• Update
• Service description

Time-permitting features

• BGP extensions for entailment regimes (OWL flavors, RDFS, RIF)
• Property paths
• Commonly used SPARQL functions (e.g. string manipulation functions)
• Basic federated query
• Query language syntax (Commas in select lists, IN/BETWEEN operator)

1.2 Goals and structure of the document

In the remainder of this document we will present the new features according to the nomenclature agreed by the Working Group:

• SPARQL/Query 1.1: referring to the SPARQL Query Language
• SPARQL/Update 1.0: referring to the SPARQL Update Language

Each feature is described in a common pattern as follows:

Motivations

a brief sentence explaining why the new feature was added

Description

a more complete description of the feature

Existing implementation(s)

a list of existing implementations for the proposed feature and example syntax used in the implementation

Related discussions

links to related discussions of the WG regarding the feature (mainly issues raised) and

Status

the status of the feature, i.e. either required or time-permitting.

This current working draft details only one required features, but motivation and a description is also provided for the time-permitting features.

2 SPARQL/Query 1.1

2.1: Aggregate functions

2.1.1 Motivations

Aggregate functions allow operations such as counting, numerical min/max/average and so on, by operating over columns of results. They are currently not taken into account in SPARQL and then require additional scripting to parse query results and get these informations, e.g. the number of triples that satisfy a particular statement. Hence, a language extension is needed.

2.1.2 Description

In SPARQL/Query 1.0 (original SPARQL), query patterns yield a solution set (effectively a table of solutions) from which certain columns are projected and returned as the result of the query. Aggregates provides the ability to partition a solution set into one or more groups based on rows that share specified values, and then to create a new solution set which contains one row per aggregated group. Each solution in this new aggregate solution set may contain either variables whose values are constant throughout the group or aggregate functions that can be applied to the rows in a group to yield a single value. Common aggregate functions include COUNT, SUM, MIN, and MAX.

Aggregate functions are commonly required to perform a slew of application and data-analysis tasks, such as:

• Determining the number of distinct resources that satisfy certain criteria
• Calculating the average exam score of students grouped by school district
• Summing the campaign contributions of donors, grouped by postal code and political party

Applications can typically take a SPARQL/Query 1.0 solution set and calculate aggregate values themselves. Enabling SPARQL engines to calculate aggregates, however, results in moving work from the application to the SPARQL engine, and will usually result in significantly smaller solution sets being returned to the application.

2.1.3 Existing implementation

The following systems are known by the WG at the time of publication to support one or more aggregate functions:

• Garlik's JXT implements COUNT() and AVG()
• ARQ implements COUNT() and SUM() with syntax like (COUNT(*) AS ?c) to fit with expressions. Bare COUNT(*) allowed.
• Open Anzo's Glitter engine implements AVG(), COUNT(), SUM(), MIN(), MAX().
• Virtuoso implements AVG(), COUNT(), SUM(), MIN(), MAX(), user-defined aggregates such as VECTOR_AGG or XML tree constructors. Appropriate GROUP BY clause is composed automatically, if missing in the original query.
• ARC supports COUNT, MAX, MIN, AVG, and SUM.
• Dave Beckett's Redland implements COUNT(), but there is no underlying query engine support.

Several aggregate functions are widely implemented, and implementations tend to project out results like for example:

SELECT COUNT(?person) AS ?alices
WHERE {
  ?person :name "Alice" .
}

return the number of times the a triple of the form _ :name "Alice" appears in the source data.

SELECT AVG(?value) AS ?average
WHERE {
  ?good a :Widget ;
        :value ?value .
}

2.1.4 Related discussions

Related issues raised by the WG:

• [ISSUE 11]: Implicit vs explicit GROUPing
• [ISSUE 12]: Presence and syntactic detail of HAVING clause
• [ISSUE 13]: Subqueries in HAVING analogous to subqueries in FILTERs
• [ISSUE 14]: Which aggregates to include
• [ISSUE 15]: Extensibility of aggregate functions
• [ISSUE 16]: Dealing with aggregates over mixed datatypes

2.1.5 Status

This feature is considered as Required by the WG.

2.2: Subqueries

2.2.1 Motivations

It is sometimes necessary to nest the results of a query within another query. It currently requires to get the results of a first query, parse them with dedicated scripts, and then launch the second query. The Subquery feature would allow to do such nesting in a single SPARQL query.

2.2.2 Description

In SPARQL/Query 1.0 (original SPARQL), to nest the result of a first query into another one, one has to rely on dedicated script(s) and run separate queries. For instance, to identify all the people that Alice knows and a single name for each of them, the following script should be done (in PHP, assuming the do_query function allows to run a SPARQL query and get the results as an array of PHP objects)

$query = "
SELECT ?person WHERE {
 :Alice :knows ?person .
}";
$res = do_query($query);  
foreach ($res as $r) {
  $person = $r->person->value;
  $query = "SELECT ?name WHERE {
    ?person foaf:name ?name .
  } LIMIT 1";    
}
  

The Subquery feature will provide a way to nest the results of a query within another query. That feature could be used, for instance, in the following use cases:

• Identifying the 10th latest blog posts created in a weblog, with a single author name for each
• Retrieving a list of people with their friends, having only one friend name for each
• Limit the number of distinct results retrieved based on the number of resources rather than the number of solutions.

The query form of subqueries has not yet been decided by the WG (see issues below).

2.2.3 Existing implementation(s)

The following implementations are known by the WG at the time of publication to provide a way to run subqueries:

• Virtuoso supports both scalar subqueries (in all places where a variable name may occur) and subqueries as derived tables.
• ARQ includes support for nested SELECTs

For instance, the following query is possible in ARQ, and is equivalent to the script mentioned before.

SELECT ?person ?name WHERE {
  :Alice foaf:knows ?person .
  { 
    SELECT ?name WHERE { 
      ?person foaf:name ?name 
    } LIMIT 1 
  }
}

2.2.4 Related discussions

Related issues raised by the WG:

• [ISSUE 3]: Subquery syntax (e.g. mandatory curly braces)
• [ISSUE 4]: What is the variable scope between main queries and subqueries?
• [ISSUE 5]: ASK queries in FILTERs?
• [ISSUE 6]: SELECT queries in FILTERs?
• [ISSUE 7]: CONSTRUCT & DESCRIBE queries in FROM [NAMED]?
• [ISSUE 8]: What determines the RDF dataset for subqueries?
• [ISSUE 9]: SELECT queries in graph patterns?
• [ISSUE 10]: ASK queries in graph patterns?

2.2.5 Status

This feature is considered as Required by the WG.

2.3: Negation

2.3.1 Motivations

In SPARQL/Query 1.0 (original SPARQL), Negation by failure is possible by combining OPTIONAL, FILTER and !BOUND. It is yet difficult to write and can be a burden for learning and using SPARQL. Hence, dedicated language constructs for expressing negation are desired, as users requested, which the WG agrees with.

2.3.2 Description

Various tasks, such as data validation and social network analysis, can require the checking of whether certain triples do or don't exist in the graph. Checking the absence of triples is a form of negation, called Negation by failure (since it checks if a pattern does not match, and not if it does not exist following the open-world assumption) and is already possible in SPARQL/Query 1.0 (original SPARQL), using FILTER, OPTIONAL and !BOUND(), as follows (to retrieve the ?name of ?x for which no foaf:knows value exists, i.e. identify the name of people who do not know anyone).

PREFIX foaf: <http://xmlns.com/foaf/0.1/>
SELECT ?name
WHERE { ?x foaf:givenName  ?name .
	OPTIONAL { ?x foaf:knows ?who } .
	FILTER (!BOUND(?who)) 
} 

Yet, this is not very intuitive to write and learn for users nor does it cater for efficient implementations of negation. Hence, the Negation feature to be included will provide the support for testing the absence of a match to a query pattern. Negation can be used in the following use cases:

• Identify all people that do not know someone or do not have a particular skill
• Identifying any content that has not been assigned a reviewer in a particular review process
• Identify customers that did not buy a particular object

The feature would introduce a new operator into the algebra or a new function for filters. Any existing queries do not use these operators and are therefore unaffected.

2.3.3 Existing implementation(s)

The following implementations are known by the WG at the time of publication to support Negation by failure:

• RDF::Query uses an UNSAID keyword, that was proposed during the first SPARQL WG but not addressed at that time
• The SeRQL query language [SeRQL] provides a MINUS operator
• ARQ supports negation thanks to NOT EXISTS operator (UNSAID) being an alias for it
• SQL provides a NOT EXISTS operator to identify table without a given record

The following example uses SeRQL's MINUS syntax to find the names of all people that do not know anyone, in a similar way to the previous query

SELECT x
  FROM {x} foaf:givenName {name}
MINUS
SELECT x
  FROM {x} foaf:givenName {name} ;
    foaf:knows {who}
USING NAMESPACE foaf = <http://xmlns.com/foaf/0.1/>

The following example uses the UNSAID syntax:

    
  PREFIX foaf: <http://xmlns.com/foaf/0.1/>
  SELECT ?x
  WHERE { ?x foaf:givenName ?name
          UNSAID { ?x foaf:knows ?who }
        }
  

2.3.4 Related discussions

Related issues raised by the WG:

• [ISSUE 29]: Should negation be done via a binary operator on subqueries, a binary operator within graph patterns, or a filter+subquery?

2.3.5 Status

This feature is considered as Required by the WG.

2.4: Project expressions

2.4.1 Motivations

Being able to return the values of expressions over result bindings, rather than just RDF terms in the store.

2.4.2 Description

In SPARQL/Query 1.0 (original SPARQL), projection queries (SELECT queries) may only project out variables bound in the query. Because variables can only be bound via triple pattern matching, there is no way to project out values that are not matched in the underlying RDF data set. Projecting expressions represents the ability for SPARQL SELECT queries to project any SPARQL expression, rather than only variables. A projected expression might be a variable, a constant URI, a constant literal, or an arbitrary expression (including function calls) on variables and constants. Functions could include both SPARQL built-in functions and extension functions supported by an implementation.

There are many use cases that motivate the ability to project expressions rather than just variables in SPARQL queries. In general, the motivation is to return values that do not occur in the graphs that comprise a query's RDF data set. Specific examples include:

• Returning the total cost of an order's line item as the product of two variables: ?unit_cost * ?quantity
• Use SPARQL accessors to find the languages used in a dataset: LANG(?o)
• Returning computed values, such as the current day of the week: ex:dayOfTheWeek(ex:Today())
• Performing simple string parsing: ex:substring(?url, 8, ex:length(?url))

TODO: More mention should be made of the connection with subqueries, as the two can be used together to answer many usecases.

2.4.3 Existing implementation(s)

The following systems are known by the WG at the time of publication to support some uses of project expressions:

• Garlik's JXT (though doesn't do CONSTRUCT)
• In ARQ with a slightly different syntax (AS is part of the () expression).
• In Open Anzo's Glitter SPARQL engine, with the same syntax as ARQ
• Virtuoso, syntax is (expression) AS ?alias, the clause "as ?alias" is optional so parentheses around expression are required.
• XSPARQL allows XPath/XQuery functions to be used as expressions in CONSTRUCTs as in the example above.
• Dave Beckett's Redland supports project expressions, but there is no backend support.

We wish to find names, and whether the person is over 18.

 SELECT ?name (?age > 18) AS over18
 WHERE {
   ?person :name ?name ;
           :age ?age .
 }

Another example, we wish to find the full name of everyone who is interested in trees.

 PREFIX foaf: <http://xmlns.com/foaf/0.1/>

 PREFIX : <http://www.example.org/>
 
 SELECT fn:string-join(?givenName, ' ', ?surname) AS ?fullName
 WHERE {
   ?person foaf:givenname ?givenName ;
           foaf:surname ?surname ;
           foaf:interest :trees .
 }

This example has made use of a concatenation function from XPath-Functions. Which functions will be available for value construction in SPARQL is an open issue that will be dealt with on a time-permitting basis.

To return an RDF graph where the first and family names are concatenated to a full name we can use a query similar to the SELECT example from the previous query as a subquery and use a project expression like this:

 PREFIX foaf: <http://xmlns.com/foaf/0.1/>
 CONSTRUCT { ?x foaf:name ?fullName }
 WHERE {
   { SELECT fn:string-join(?gn, " ", ?sn) AS ?fullName
     WHERE { foaf:givenname ?gn ; foaf:surname ?sn . } }
 }

TODO: It should be established whether any implementations support both subqueries and fn:string-join()

2.4.4 Related discussions

The WG has noted that project expressions

• is an important way to access the result of aggregate functions,
• can be used to resolve [ISSUE 4] concerning the variable scope between main queries and subqueries.

2.4.5 Status

This feature is considered as Required by the WG.

2.5 Query language syntax

2.5.1 Motivation

Certain limitations of the SPARQL/Query 1.0 language syntax cause unnecessary barriers for learning and using SPARQL.

2.5.2 Description

Time-permitting, the SPARQL Working Group will consider extending SPARQL/Query's syntax to include:

• Commas between variables and expressions within a SELECT list
• IN and BETWEEN operators to abbreviate disjunction and comparisons within FILTER expressions

2.5.5 Status

This feature is considered as time-permitting only by the WG.

2.6 Property paths

2.6.1 Motivation

Many classes of query over RDF graphs require searching data structures that are hierarchical and involve arbitrary-length paths through the graphs. Examples include:

• Retrieving all the elements of an RDF collection (structured as a linked list)
• Retrieve all of the names of people linked to me transitively via the ex:mother and ex:father relationships (i.e. all my known ancestors)
• What are all of the direct and indirect superclasses of a given owl:Class?

2.6.2 Description

SPARQL/Query 1.0 can express queries over fixed-length paths within RDF graphs. SPARQL/Query 1.0 can also express queries over arbitrary but bounded-length paths via repeated UNION constructs. SPARQL/Query 1.0 cannot express queries that require traversing hierarchical structures via unbounded, arbitrary-length paths.

Time-permitting, the SPARQL Working Group will define the syntax and semantics of property paths, a mechanism for expressing arbitrary-length paths of predicates within SPARQL triple patterns.

2.6.5 Status

This feature is considered as time-permitting only by the WG.

2.7 Commonly Used SPARQL Functions

2.7.1 Motivation

Many SPARQL implementations support functions beyond those required by the SPARQL/Query 1.0 specification. There is little to no interoperability between the names and semantics of these functions for common tasks such as string manipulation.

2.7.2 Description

Time-permitting, the SPARQL WG will define URIs and semantics for a set of functions commonly supported by existing SPARQL implementations.

See Working Group issue: ISSUE-2 - http://www.w3.org/2009/sparql/tracker/issues/2

2.7.5 Status

This feature is considered as time-permitting only by the WG.

2.8 Basic Federated Query

2.8.1 Motivation

SPARQL is a concise query language to retrieve and join information from multiple RDF graphs via a single query. In many cases, the different RDF graphs are stored behind distinct SPARQL endpoints.

2.8.2 Description

Federated query is the ability to take a query and provide solutions based on information from many different sources. It is a hard problem in its most general form and is the subject of continuing (and continuous) research. A building block is the ability to have one query be able to issue a query on another SPARQL endpoint during query execution.

Time-permitting, the SPARQL Working Group will define the syntax and semantics for handling a basic class of federated queries in which the SPARQL endpoints to use in executing portions of the query are explicitly given by the query author.

2.8.5 Status

This feature is considered as time-permitting only by the WG.

3: Service description

3.1 Motivations

Given the variety of SPARQL implementations, and differences in datasets and extension functions, a method of discovering a SPARQL endpoint's capabilities and summary information of its data in a machine-readable way is needed.

3.2 Description

Many SPARQL implementations support a variety of SPARQL extensions (many proposed here for standardization), extension functions (for use in FILTERs), and different entailment regimes. Moreover, the differences in datasets provided by SPARQL endpoints is often hard to grasp without some existing knowledge of the underlying data. This proposal suggests that these differences may be described by the endpoints themselves, detailing both (1) the capabilities of the endpoint and (2) the data contained in the endpoint.

The Service description features can be used in the following uses-cases:

• Check the entailment regime supported by a SPARQL endpoint before running a query
• Check if an RDF store contains instance of particular class to see if it is worth running a query over it
• Check if an RDF store supports a particular extension function

3.3 Existing implementation(s)

The following services are known by the WG at the time of publication to support the Service description feature

• RDF::Query provides service descriptions (based primarily on the DARQ and SADDLE vocabularies) referenced in the HTTP response headers of a query
• Virtuoso has support for DBPedia VoiD data using a special default-graph of <http://dbpedia.org/stats/void#>, which can be queried using the SPARQL endpoint.
• Garlik's JXT implements something similar to this feature, differences from as described are, the MIME header is "X-Endpoint-Description:" and the URI given is relative to the endpoint: /description.

The following service description is an example of what is provided when querying powered by RDF::Query using about=1 HTTP parameters, e.g. http://example.org/sparql?about=1.

@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix sd: <http://darq.sf.net/dose/0.1#> .
@prefix saddle: <http://www.w3.org/2005/03/saddle/#> .
@prefix sparql: <http://kasei.us/2008/04/sparql#> .
@prefix void: <http://rdfs.org/ns/void#> .
[] a sd:Service ;
  rdfs:label "SPARQL Endpoint for example.org" ;
  sd:url <http://example.org/sparql> ;
  sd:totalTriples 12729 ;
  saddle:queryLanguage [ rdfs:label "SPARQL" ; saddle:spec <http://www.w3.org/TR/rdf-sparql-query/> ] ;
  saddle:queryLanguage [ rdfs:label "RDQL" ; saddle:spec <http://www.w3.org/Submission/RDQL/> ] ;
  saddle:resultFormat [
    rdfs:label "SPARQL Query Results XML" ;
    saddle:mediaType "application/sparql-results+xml" ;
    saddle:spec <http://www.w3.org/TR/rdf-sparql-XMLres/
  ] ;
  saddle:resultFormat [
  	rdfs:label "RDF/XML" ;
  	saddle:mediaType "application/rdf+xml" ;
  	saddle:spec <http://www.w3.org/TR/rdf-syntax/>
  ] ;
  saddle:resultFormat [
		rdfs:label "SPARQL Query Results JSON" ;
		saddle:mediaType "application/sparql-results+json" ;
  	saddle:spec <http://www.w3.org/TR/rdf-sparql-json-res/>
  ] ;
  
  sparql:extensionFunction <java:com.hp.hpl.jena.query.function.library.sha1sum> ;
  sparql:extensionFunction <java:com.ldodds.sparql.Distance> ;

  sparql:sparqlExtension <http://kasei.us/2008/04/sparql-extension/service> ;
  sparql:sparqlExtension <http://kasei.us/2008/04/sparql-extension/unsaid> ;
  sparql:sparqlExtension <http://kasei.us/2008/04/sparql-extension/federate_bindings> .

3.4 Related discussions

The serviceDescription issue was previously postponed by the DAWG.

3.5 Status

This feature is considered as Required by the WG.

4 Update

The Working Group has resolved to specify a SPARQL/Update language, but may also pursue a HTTP based graph update via the protocol. This issue is orthogonal to the SPARQL/Update language. Whether or not there will be a concrete mapping between SPARQL/Update and HTTP based graph update is currently under discussion in the working group.

4.1: SPARQL/Update 1.0 Language

4.1.1 Motivations

To change an RDF graph (either adding, updating or removing statements as well as adding statements from one graph to another or to the default graph of a triple store) one would currently have to use a programming language and one of several APIs. In other query languages, notably SQL, there are mechanisms to change the data in the database. To allow RDF graphs to be manipulated the same way and avoid using third-party APIs, a language extension is needed.

4.1.2 Description

This feature is a language extension to express updates to an RDF graph or to an RDF store. As such, it uses the SPARQL in both style and detail, reduces the learning curve for developers and reduces implementation costs.

The following facilities are expected to be provided by the SPARQL/Update 1.0 language:

• Insert new triples to an RDF graph.
• Delete triples from an RDF graph.
• Perform a group of update operations as a single action.
• Create a new RDF Graph to a Graph Store.
• Delete an RDF graph from a Graph Store.

4.1.3 Existing implementation(s)

The [SPARUL] Member Submission, that contains several examples, have been widely implemented and is considered a starting point for the present work.

The two following examples illustrates some of the features:

PREFIX dc: <http://purl.org/dc/elements/1.1/>
INSERT DATA
{ <http://example/book3> dc:title    "A new book" ;
                         dc:creator  "A.N.Other" .
}
  

DELETE { ?book ?p ?v }
WHERE
  {   ?book dc:date ?date . 
       FILTER ( ?date < "2000-01-01T00:00:00"^^xsd:dateTime ) 
       ?book ?p ?v
      } 
  }   	
  

The following systems are known by the WG to support the [SPARUL] Member Submission at the time of publication:

• ARQ
• Virtuoso

4.1.4 Related discussions

Related issues raised by the WG:

• [ISSUE 17]: Minimal vs fully-fledged update language
• [ISSUE 18]: Concurrency in SPARQL/Update
• [ISSUE 19]: Security issues on SPARQL/Update
• [ISSUE 20]: Graphs aware stores vs. quad stores for SPARQL/Update (empty graphs)
• [ISSUE 21]: More complex update operations, e.g. CHANGE objects
• [ISSUE 22]: Support of SOAP in SPARQL/Update
• [ISSUE 23]: Content negotiation/switch for mediatype
• [ISSUE 24]: Move data between graphs (select on one graph and insert into another... copy from/to)
• [ISSUE 25]: Dynamic graph (variable) for INTO graph to update/modify
• [ISSUE 26]: Conjunction of operation vs atomocity, transactions
• [ISSUE 27]: Subqueries in Update operations, full expressivity
• [ISSUE 28]: Entailment regimes vs. update?

4.1.5 Status

This feature is considered as Required by the WG.

4.2 Protocol Enhancements for Update

4.2.1 Motivations

By making it possible to update an RDF graph using RESTful HTTP methods, it becomes possible to use either a SPARQL endpoint or a plain Web server to update RDF data.

4.2.2 Description

It should be possible to manipulate RDF graphs using HTTP verbs, notably PUT, POST and DELETE. By this, clients doesn't need to know the SPARQL language to update graphs when it is not needed.

4.2.3 Existing implementation(s)

The following systems are known by the WG at the time of publication to support a RESTful update protocol.

• Garlik's JXT supports HTTP PUT and DELETE.
• IBM's Jazz Foundation supports graph update via a RESTful protocol.

4.2.4 Related discussions

4.2.5 Status

This feature is under discussion in the WG.

5 BGP extensions for entailment regimes

5.1 Motivation

Many software systems that support entailment regimes such as OWL dialects and RDF Schema extend the semantics of SPARQL Basic Graph Pattern matching to apply to entailments other than simple entailment. The formal semantics of these SPARQL/Query extensions are not standardized, and query writers cannot currently be guaranteed interoperable behavior when working with multiple query engines that extend SPARQL with the same entailment regime.

5.2 Description

SPARQL/Query 1.0 defines a mechanism to adapt SPARQL to entailment regimes beyond simple entailment by providing necessary conditions on re-defining the meaning of SPARQL Basic Graph Pattern matching. Time-permitting, the SPARQL WG will use the existing framework to define the semantics of SPARQL queries for one or more of these entailment frameworks:

• OWL 2 with both Direct and RDF Based Semantics, including OWL 2 profiles
• RDF Schema
• Some dialects of RIF

5.5 Status

This feature is considered as time-permitting only by the WG.

6 Acknowledgments

The editors would like to thank the SPARQL Working Group for their valuable input for this document.

7 References

[SPARQL/Query 1.0]

SPARQL Query Language for RDF. Eric Prud'hommeaux, Andy Seaborne. W3C Recommendation 15 January 2008. http://www.w3.org/TR/rdf-sparql-query/

[SPARUL]

SPARQL Update - A language for updating RDF graphs. Andy Seaborne, Geetha Manjunath, Chris Bizer, John Breslin, Souripriya Das, Ian Davis, Steve Harris, Kingsley Idehen, Olivier Corby, Kjetil Kjernsmo, Benjamin Nowack. W3C Member Submission 15 July 2008. http://www.w3.org/Submission/2008/SUBM-SPARQL-Update-20080715/

[SeRQL]

The SeRQL query language (revision 3.0). 2002-2008 Aduna B.V http://www.openrdf.org/doc/sesame2/users/ch09.html

[XPath-Functions]

XQuery 1.0 and XPath 2.0 Functions and Operators, A. Malhotra, J. Melton, N. Walsh (Editors), W3C Recommendation, World Wide Web Consortium, 23 January 2007, http://www.w3.org/TR/2007/REC-xpath-functions-20070123/.

      $Log: Overview.html,v $
      Revision 1.119  2009/07/06 12:20:58  kkjernsm
      Change status of Redland support for count() and project expressions

      Revision 1.118  2009/06/30 14:31:14  apassant
      Added Status of BGP extension

      Revision 1.117  2009/06/30 14:30:34  kkjernsm
      Fix links

      Revision 1.116  2009/06/30 14:21:42  apassant
      Removed non-existing CSS link

      Revision 1.115  2009/06/30 14:20:04  apassant
      Removed section 5.5 in TOC

      Revision 1.114  2009/06/30 13:45:25  apassant
      Small grammar fixes

      Revision 1.113  2009/06/29 16:04:07  apassant
      Added links to the time-permitting features in Introduction

      Revision 1.112  2009/06/29 15:56:43  apassant
      Updated Entailment Description

      Revision 1.111  2009/06/26 11:02:29  kkjernsm
      fix markup

      Revision 1.110  2009/06/26 10:59:38  kkjernsm
      Update TOC

      Revision 1.109  2009/06/26 10:52:50  kkjernsm
      Say that stub descriptions for time-permitting are there

      Revision 1.108  2009/06/26 10:50:27  kkjernsm
      fix numbering

      Revision 1.107  2009/06/26 10:47:06  kkjernsm
      Add Lee's summary of time-permitting features.

      Revision 1.106  2009/06/25 07:56:46  kkjernsm
      use correct URL for patent disclosures

      Revision 1.105  2009/06/25 07:47:57  kkjernsm
      uncomment patent policy section

      Revision 1.104  2009/06/24 13:59:45  kkjernsm
      Add ARC to aggregates

      Revision 1.103  2009/06/24 13:56:10  kkjernsm
      reorder the implementations

      Revision 1.102  2009/06/24 13:47:18  kkjernsm
      known to -> known by

      Revision 1.101  2009/06/24 13:24:05  kkjernsm
      Add comments about the status of existing implementations.

      Revision 1.100  2009/06/24 12:47:22  kkjernsm
      Add links to existing implementations from the Wiki, as resolved

      Revision 1.99  2009/06/24 12:39:49  kkjernsm
      Add IBM about Restful updates

      Revision 1.98  2009/06/24 12:35:45  kkjernsm
      Remove the one CONSTRUCT example from project expressions

      Revision 1.97  2009/06/24 12:13:53  kkjernsm
      Add proposed shortname

      Revision 1.96  2009/06/23 14:52:30  kkjernsm
      Add Garlik HTTP Update

      Revision 1.95  2009/06/23 14:50:02  kkjernsm
      Add TODO in project expressions

      Revision 1.94  2009/06/23 14:48:09  kkjernsm
      Add paranthesis

      Revision 1.93  2009/06/23 06:08:57  apassant
      Added ARQ in the Negation section

      Revision 1.92  2009/06/16 17:00:18  kkjernsm
      typo fix from Axel

      Revision 1.91  2009/06/16 14:49:48  kkjernsm
      Add UNSAID example

      Revision 1.90  2009/06/16 14:41:47  apassant
      Fixed Introduction numbering

      Revision 1.89  2009/06/16 14:38:18  kkjernsm
      fix negation wording

      Revision 1.88  2009/06/16 14:34:54  apassant
      Fixed HTML

      Revision 1.87  2009/06/16 14:34:07  apassant
      Updated Introduction based on Axel's proposal

      Revision 1.86  2009/06/16 14:31:53  kkjernsm
      <AndyS> Checking F&O:  fn:concat --> fn:string-join

      Revision 1.85  2009/06/16 14:01:37  kkjernsm
      add new examples

      Revision 1.84  2009/06/16 13:32:36  kkjernsm
      Add some discussions to project expressions

      Revision 1.83  2009/06/16 10:15:31  kkjernsm
      Update examples

      Revision 1.82  2009/06/16 10:04:22  kkjernsm
      Add XPath-Functions reference

      Revision 1.81  2009/06/15 01:57:48  apassant
      Added SQL NOT EXISTS in Negation

      Revision 1.80  2009/06/12 17:48:26  kkjernsm
      Fix references, us @id

      Revision 1.79  2009/06/12 17:46:30  kkjernsm
      Fix two numbers

      Revision 1.78  2009/06/12 17:45:20  kkjernsm
      Make Protocol 4.2

      Revision 1.77  2009/06/10 10:29:57  apassant
      Fixed HTML error

      Revision 1.76  2009/06/10 10:16:34  apassant
      Slightly updated motivations for Negation

      Revision 1.75  2009/06/10 10:13:54  apassant
      s/type of subqueries/query form of subqueries

      Revision 1.74  2009/06/10 10:13:13  apassant
      Fixed Subqueries examples

      Revision 1.73  2009/06/10 10:08:10  apassant
      Fixed variable names without ?

      Revision 1.71  2009/06/10 10:01:54  apassant
      Added list of Features in the introduction

      Revision 1.70  2009/06/09 14:48:18  kkjernsm
      Fix numbering, remove TODO

      Revision 1.69  2009/06/09 14:45:19  kkjernsm
      Make Service Description a section

      Revision 1.68  2009/06/09 12:28:41  kkjernsm
      Some of Andy's suggestions

      Revision 1.67  2009/06/09 12:22:48  kkjernsm
      slightly more on HTTP update

      Revision 1.66  2009/06/09 11:42:21  kkjernsm
      Another typo

      Revision 1.65  2009/06/09 11:39:01  kkjernsm
      Very small typo

      Revision 1.64  2009/06/09 11:19:58  kkjernsm
      Add the LimitPerResource case to Subqueries

      Revision 1.63  2009/06/09 11:09:39  kkjernsm
      a bit of inconsistency in fragment identifier cases

      Revision 1.62  2009/06/09 11:05:13  kkjernsm
      Really strict

      Revision 1.61  2009/06/09 11:04:03  kkjernsm
      Strict XHTML?

      Revision 1.60  2009/06/09 11:00:32  kkjernsm
      Fix TOC

      Revision 1.59  2009/06/09 09:21:03  kkjernsm
      Some editing about Update

      Revision 1.58  2009/06/09 08:49:17  kkjernsm
      Link my homepage

      Revision 1.57  2009/06/09 08:45:48  kkjernsm
      Aggregate examples of existing implementations

      Revision 1.56  2009/06/09 08:32:13  kkjernsm
      Minor changes

      Revision 1.55  2009/06/09 08:11:10  kkjernsm
      Add Project Expressions from the Wiki

      Revision 1.54  2009/06/09 07:55:44  kkjernsm
      Wrap some long lines

      Revision 1.53  2009/06/08 20:51:53  apassant
      Minor editing on various parts

      Revision 1.52  2009/06/08 15:11:38  kkjernsm
      Add aggregates description

      Revision 1.51  2009/06/06 17:18:35  apassant
      Commented Use-cases section
      Fixed HTML

      Revision 1.50  2009/06/06 17:12:36  apassant
      Update Negation example with SeRQL MINUS example

      Revision 1.49  2009/06/06 17:04:06  apassant
      Added RDF::Query example regarding Service Description

      Revision 1.48  2009/06/05 13:22:52  apassant
      Updated abstract

      Revision 1.47  2009/06/04 21:20:42  apassant
      Added content for Service description

      Revision 1.46  2009/06/04 21:10:26  apassant
      Commented time-permitting features

      Revision 1.45  2009/06/04 21:05:05  apassant
      Updated Negation

      Revision 1.44  2009/06/04 20:50:01  apassant
      Updated Subqueries

      Revision 1.43  2009/06/04 15:24:24  kkjernsm
      two colons on RDF::Query

      Revision 1.42  2009/06/04 15:14:46  apassant
      Updated Subqueries with description and examples

      Revision 1.41  2009/06/02 20:55:20  kkjernsm
      Remove reference to OWL. Also remove reference to patent policy, since
      that's not clear for this group.

      Revision 1.40  2009/06/02 20:51:18  kkjernsm
      Explain examples more

      Revision 1.39  2009/06/02 16:11:09  kkjernsm
      replace 'example syntax' with 'existing implementation'

      Revision 1.38  2009/06/02 15:55:33  kkjernsm
      Add protocol section

      Revision 1.37  2009/06/02 13:52:12  apassant
      Added reference to SeRQL

      Revision 1.36  2009/06/02 13:26:47  apassant
      Updated Negation

      Revision 1.35  2009/06/02 12:55:41  apassant
      Updated Introduction

      Revision 1.34  2009/06/02 12:45:18  apassant
      Added skeleton for Property paths, Commonly used SPARQL functions, Basic federated query

      Revision 1.33  2009/06/02 12:34:12  apassant
      Added skeleton for Service description

      Revision 1.32  2009/05/19 15:03:44  apassant
      Link to the Negation ISSUE

      Revision 1.31  2009/05/15 14:26:00  apassant
      Fixed sections numbering

      Revision 1.30  2009/05/15 14:21:17  apassant
      Added a 'Status' section for each feature

      Revision 1.29  2009/05/07 18:51:17  apassant
      Fixed missing revision in the Changelog

      Revision 1.28  2009/05/07 18:47:15  apassant
      Links to the Update ISSUEs

      Revision 1.27  2009/05/07 15:04:29  apassant
      Links to the Aggregate ISSUEs

      Revision 1.26  2009/05/07 13:09:31  apassant
      Links to the Subqueries ISSUEs

      Revision 1.25  2009/05/07 12:48:31  kkjernsm
      Small XML error

      Revision 1.24  2009/05/06 19:12:13  apassant
      Added current syntax for negation

      Revision 1.23  2009/05/06 18:59:37  apassant
      s/Proposed syntax/Example syntax

      Revision 1.22  2009/05/06 18:38:00  apassant
      SPARQL/Query 1.1 and SPARQL/Update 1.0
      Updated features list according to http://www.w3.org/2009/sparql/wiki/index.php?title=FeatureProposal&oldid=744

      Revision 1.21  2009/05/06 18:21:28  kkjernsm
      Just SPARQL, not 1.1

      Revision 1.20  2009/05/06 18:05:30  kkjernsm
      Remove the stub name, call it 1.1

      Revision 1.19  2009/05/03 09:56:13  apassant
      Updated sections on Update and Aggregates
      Added SPARUL reference

      Revision 1.18  2009/05/03 09:42:17  apassant
      Updated introduction

      Revision 1.17  2009/05/01 22:21:54  kkjernsm
      Remove and comment on some OWL references.

      Revision 1.16  2009/05/01 22:16:46  kkjernsm
      s/SPARQL 2/SPARQL NG/

      Revision 1.15  2009/04/30 15:02:46  kkjernsm
      A bit on aggregates

      Revision 1.14  2009/04/30 14:57:29  kkjernsm
      Grab some text from Andy's submission about Update

      Revision 1.13  2009/04/30 14:41:41  kkjernsm
      Add outline of agreed features

      Revision 1.12  2009/04/30 14:33:16  kkjernsm
      Use ids instead of the archaic a@name

      Revision 1.11  2009/04/30 14:26:42  kkjernsm
      Break long lines, short lines decrease the likelihood of conflicts in editing.

      Revision 1.10  2009/04/27 16:08:41  kkjernsm
      Corrected some XML errors
      
      Revision 1.9  2009/04/27 15:21:23  apassant
      Cleaning document + drafting TOC
      
      Revision 1.8  2009/04/22 16:32:16  eric
      + Change Log