W3C

SPARQL 1.1 Update

W3C Working Draft 1 June 2010

This version:
http://www.w3.org/TR/2010/WD-sparql11-update-20100601/
Latest version:
http://www.w3.org/TR/sparql11-update/
Previous version:
http://www.w3.org/TR/2010/WD-sparql11-update-20100126/
Editors:
Simon Schenk <sschenk@uni-koblenz.de>
Paul Gearon <gearon@computer.org>
Alexandre Passant, DERI Galway at the National University of Ireland, Galway, Ireland <alexandre.passant@deri.org>

Abstract

This document describes SPARQL 1.1 Update, an update language for RDF graphs. It uses a syntax derived from the SPARQL Query Language for RDF. Update operations are performed on a collection of graphs in a Graph Store. Operations are provided to change existing RDF graphs as well as create and remove graphs in the Graph Store.

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 Working Draft.

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 SPARQL Working Group, which is part of the W3C Semantic Web Activity.

Change Summary

the INSERT operation can now create a graph that does not exist. Semicolons separate multiple operations within a request. Multiple operations in a request should be executed atomically. WITH, USING, and USING NAMED clauses added to DELETE/INSERT operations. Updated treatment of results from update requests. Editorial updates.

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. 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 Scope and Limitations
    1.2 Document Conventions
        1.2.1 Language Form
        1.2.2 Terminology
2 Working Group Outstanding issues
    2.1 Basic Federated Query
3 The Graph Store
    3.1 Graph Store and SPARQL Query Services
    3.2 SPARQL 1.1 Update Services
4 SPARQL 1.1 Update Language
    4.1 Graph Update
        4.1.1 INSERT DATA
        4.1.2 DELETE DATA
        4.1.3 DELETE/INSERT
        4.1.4 DELETE
        4.1.5 INSERT
        4.1.6 DELETE WHERE
        4.1.7 LOAD
        4.1.8 CLEAR
    4.2 Graph Management
        4.2.1 CREATE
        4.2.2 DROP
5 SPARQL 1.1 Update Definition
6 Conformance

Appendices

A Security Considerations
B SPARQL 1.1 Update Grammar
C References
    C.1 Normative References
    C.2 Other References
D CVS History


1 Introduction

SPARQL 1.1 Update is a language to express updates to an RDF store. It is intended to be a standard language for specifying and executing updates to RDF graphs in a Graph Store. SPARQL 1.1 Update is a companion language to SPARQL and is envisaged to be used in conjunction with the SPARQL query language. The reuse of the SPARQL syntax, in both style and detail, reduces the learning curve for developers and reduces implementation costs.

SPARQL 1.1 Update provides the following facilities:

For the rationale behind this language, see the original SPARQL New Features and Rationale document.

This document is related to these other specification documents:

The SPARQL 1.1 Uniform HTTP Protocol for Managing RDF graphs specification employs the HTTP protocol to perform update operations using standard HTTP methods, such as PUT and DELETE. While providing a simple and well known API, it is necessarily restricted in its operations due to the limited set of methods in the HTTP protocol. In contrast, SPARQL 1.1 Update permits multiple modifications in a single operation, and can use complex SPARQL queries for constructing data to be inserted, or choosing data to be deleted. Also, the use of an update language facilitates operations over proprietary APIs and connections that may not involve HTTP.

The SPARQL 1.1 Protocol for RDF specification describes a means of conveying SPARQL 1.1 Query and SPARQL 1.1 Update operations from clients to SPARQL endpoints, and for returning appropriate results. Together with the SPARQL 1.1 Query and SPARQL 1.1 Update (this document) specifications, these form an alternative to the SPARQL 1.1 Uniform HTTP Protocol for Managing RDF graphs with comprehensive, though more complex functionality.

1.1 Scope and Limitations

SPARQL 1.1 Update is not:

  • a replacement for RSS or Atom, which may be used to advertise changes.
  • a mechanism to exchange changes to RDF graphs between applications.
  • a general web-wide approach to update and distribution of RDF-based information.

1.2 Document Conventions

1.2.1 Language Form

Language forms are show as:

INSERT { ConstructTriples } [ WHERE GroupGraphPattern ]

[] indicates an optional part of the syntax. [] are still used for blank nodes in SPARQL Update requests.

Italics indicate an item is some syntax element derived from SPARQL Query. BOLD indicates literal text.

Examples are shown as:

PREFIX dc: <http://purl.org/dc/elements/1.1/>
INSERT { <http://example/egbook3> dc:title  "This is an example title" }

1.2.2 Terminology

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

The following terms are also in use throughout this document:

  • Operation - A single activity to be performed that results in the modification of data in a graph store. e.g. INSERT or DELETE.
  • Request - A sequence of one or more operations that are sent to a graph store. When using the SPARQL 1.1 Protocol for RDF a request will be one HTTP POST.

The following terms are also used in this document, and are defined in the SPARQL 1.1 Query Language

  • TriplesBlock - A syntactic construct that refers to a set of triples.
  • ConstructTriples - Identical to a TriplesBlock, but with an emphasis on defining a particular set of triples, rather than finding them.
  • GroupGraphPattern - A syntactic construct for refering to a set of triples, possibly with complex constraints.

2 Working Group Outstanding issues

Issues related to SPARQL 1.0 - Query or features proposed in this document are listed inline with the corresponding features. Issues related to potential new features in SPARQL 1.1 - Query are listed in this section.

2.1 Basic Federated Query

Basic federated update allows the moving of triples between stores. This is provided by the use of federated query constructs in the GroupGraphPattern of INSERT and DELETE statements.

Note:

See SPARQL Federation Extensions 1.1 for details on federated queries.

Issue (ISSUE-37):

How does basic federated query interact with SPARQL/Update?

Source: ISSUE-37

Resolution:

None recorded.

3 The Graph Store

A Graph Store is a repository of RDF graphs managed by a single service. Like an RDF Dataset operated on by SPARQL, a Graph Store contains one unnamed graph and zero or more named graphs. Operations may specify graphs to work with, or they may rely on a default graph for that operation. Unless overridden (for instance, by the SPARQL protocol), then the unnamed graph for the store will be the default graph for any operations on that store. Depending on implementation, the unnamed graph may refer to a separate graph, or it could be a representation of a union of other graphs.

Unlike an RDF dataset, named graphs can be added to or deleted from a graph store. A Graph Store need not be authoritative for the graphs it contains.

In the simple case, where there is one unnamed graph and no named graphs, SPARQL 1.1 Update is a language for the update of a single graph.

A formal definition for graph stores and how SPARQL 1.1 Update affects them is described in the SPARQL 1.1 Update Definition section.

Note:

A formal model for the SPARQL 1.1 Update language is to be defined.

3.1 Graph Store and SPARQL Query Services

A service (often referred to as an endpoint) that accepts and processes update operations is referred to as an update service. If an update service is managing some graph store, then there is no presumption that this exactly corresponds to any RDF dataset offered by some query service. A query service may offer an RDF dataset formed from graphs that are part of an update service's Graph Store. The graphs in the query service's RDF dataset MAY be a subset of the graphs in the update service's Graph Store. Furthermore, the query service's RDF dataset and the update service's Graph Store may use different names for the same graphs.

3.2 SPARQL 1.1 Update Services

SPARQL 1.1 Update requests are a sequence of operations.

Each request should be treated atomically by a SPARQL 1.1 Update service. Any resulting concurrency issues will be a matter for each implementation to consider according to its own architecture.

In the case of two different update services, whose respective graph stores contain graphs with the same names, there is no presumption that the updates done through one service will be propagated to the other. The behaviour of these services with respect to each other is implementation dependent. It is recommended that such deployment scenarios are avoided.

An implementation must target SPARQL queries on updated graphs if the SPARQL and SPARQL 1.1 Update end points are the same.

3.2.1 Entailment and Consistency

If the store is capable of calculating entailed statements, then it is possible for update operations to interact with entailed data. In particular, a DELETE operation may remove entailed statements. If this is the case, then entailment may generate these statements again, resulting in the statements not being affected.

After an update is completed, a store that performs consistency checking may check the new state of the data for consistency. If an inconsistency is detected, the store should raise an exception.

4 SPARQL 1.1 Update Language

SPARQL 1.1 Update supports two categories of update operations on a Graph Store:

Multiple operations can be packed into requests. Multiple operations must be separated by a ; (semicolon) character. A sequence of operations is terminated by either a semicolon or EOF (End of File). The operations of a request are executed in lexical order.

Operations all result either in success or failure. A failure result may be accompanied by extra information, indicating that some portion of the operation was successful. This document does not stipulate the exact form of the result, as that will be dependent on the interface being used, for instance HTTP or a programatic API. If multiple operations are present in a single request, then a result of failure from any operation must abort the sequence of operations, causing the subsequent operations to be ignored.

4.1 Graph Update

Graph update operations change existing graphs in the Graph Store but do not explicitly delete nor create them. An implementation must create graphs that do not exist before triples were inserted into them, and may remove graphs that are left empty after triples are removed from them.

The INSERT DATA operation adds some triples, which are inline in the request, into a graph. This will create the destination graph if it does not exist.

The DELETE DATA operation removes some triples, which are inline in the request, from a graph.

The fundamental pattern-based operations for graph updates are INSERT and DELETE. These operations consist of groups of triples to be deleted and groups of triples to be added. The specification of the triples is based on query patterns.

The difference between INSERT / DELETE and INSERT DATA / DELETE DATA is that INSERT DATA and DELETE DATA do not take a template and pattern. The DATA forms require concrete data (no named variables).  Having specific operations means that a request can be streamed so that large, pure-data, updates can be done.

The LOAD operation reads the contents of a document representing a graph into a graph in the graph store.

The CLEAR operation removes all the triples in a graph.

4.1.1 INSERT DATA

Insert data into a graph:

INSERT DATA { graph_triples }

Graph triples are defined as:

  graph_triples :: = TriplesBlock | GRAPH <graph_uri> { TriplesBlock }

If no graph is described in the graph_triples, then the default graph is presumed. If a graph is described, but it does not exist, then it will be created.

Note that a triple may be considered to be "processed" with no action if that triple already exists in the graph.

Example:

Adding some triples to a graph. This snippet describes two RDF triples to be inserted into the default graph of the RDF store.

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

4.1.2 DELETE DATA

Delete data from a graph:

DELETE DATA { graph_triples }

graph_triples are described in INSERT DATA.

Note that a triple may be considered to be "processed" with no action if that triple did not exist in the graph.

Example:

Removing undesired triples from a graph. This operation describes 2 triples to be removed from the default graph of the RDF store.

PREFIX dc: <http://purl.org/dc/elements/1.1/>

DELETE DATA
{ <http://example/bookx> dc:title    "David Copperfield" ;
                         dc:creator  "Edmund Wells" .
}

Example:

This SPARQL 1.1 Update request expands on the previous examples, by including a triple to be deleted and a triple to be added (used here to correct a book title). Also, instead of using the default graph, the requested change happens in the named graph identified by the URI http://example/bookStore.

PREFIX dc: <http://purl.org/dc/elements/1.1/>
DELETE DATA
{ GRAPH <http://example/bookStore> { <http://example/book3>  dc:title  "Fundamentals of Compiler Desing" } } ;

PREFIX dc: <http://purl.org/dc/elements/1.1/>
INSERT DATA
{ GRAPH <http://example/bookStore> { <http://example/book3>  dc:title  "Fundamentals of Compiler Design" } }

4.1.3 DELETE/INSERT

[ WITH <uri> ]
DELETE { modify_template [ modify_template ]* }
INSERT { modify_template [ modify_template ]* }
[ USING [NAMED] <uri> ]*
[ WHERE ] GroupGraphPattern

The modify_template has the following form:

  modify_template :: = ConstructTriples | graph_template
  graph_template ::= GRAPH VarOrIRIRef { ConstructTriples }

The template and pattern forms are as defined in SPARQL for construct templates and graph patterns.

This operation identifies data with the WHERE clause, binding values to a set of variables. These bindings are then used in the DELETE template to remove triples, and then in the INSERT template to create new triples.

The WITH uri defines the graph that will be modified or matched against for any of the subsequent elements that do not specify a graph explicitly. If not provided, then the default graph of the store will be assumed.

Following the optional WITH clause are the INSERT and DELETE directives. The deletion of the triples happens before the insertion. The pattern in the WHERE clause is evaluated only once, before the delete part of the operation is performed. The overall processing model is that the pattern is executed, the results used to instantiate the DELETE template, the deletes performed, the results used again to instantiate the INSERT template, and the inserts performed.

The USING <uri> and USING NAMED <uri> clauses affect the graphs and named graphs used in the WHERE clause. This is identical manner to how FROM <uri> and FROM NAMED <uri> clauses affect the graphs and named graphs in a SPARQL SELECT query. The use of USING in this instance is to avoid possible ambiguity of where statements being DELETEd from. If a USING clause appears, then this will override any effect that WITH may have on the WHERE clause, and only the WHERE clause.

As with SELECT queries, the GroupGraphPattern in the WHERE clause will be matched against any graphs described explicitly in that GroupGraphPattern, and any portions which do not specify a graph will be matched against the datasets described with USING or USING NAMED. Any remaining portions of the GroupGraphPattern which are not assigned a dataset will be matched against the graph specified in the WITH clause, if present, or the default graph otherwise.

The GroupGraphPattern is evaluated as in a SPARQL query "SELECT * WHERE GroupGraphPattern" and all the named variables are made available to the preceding templates for defining the triples to be inserted or deleted.

The GRAPH <uri> clause in a graph_template names the graph in the graph store to be updated; if omitted, the directive applies to the graph specified by the WITH clause, or the default graph if no WITH clause is present.

To illustrate the use of the WITH clause, an operation of the general form:

WITH <g1> INSERT { x y z } DELETE { a b c } WHERE { ... }

Is considered equivalent to:

INSERT { GRAPH <g1> { x y z } } DELETE { GRAPH <g1> { a b c } } USING <g1> WHERE { ... }

Note that WITH will be ignored for any section that stipulates a GRAPH or for the entire WHERE clause if a USING is present.

Deleting triples that are not present, or from a graph that is not present will have no effect and will result in success. If an operation tries to insert into a graph that does not exist, then that graph must be created. If no data is to be inserted, then no graph will be created, even if another dataset would result in data being inserted. If a graph must be created regardless of the data to be inserted, then the graph management operations (CREATE/LOAD) may be used prior to aniy insertion operations.

Example:

An example to update the graph http://example/addresses to rename all people with the name "Bill" to "William".

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

WITH <http://example/addresses>
DELETE { ?person foaf:firstName 'Bill' }
INSERT { ?person foaf:firstName 'William' }
WHERE
  { ?person a foaf:Person .
    ?person foaf:firstName 'Bill'
  } 

4.1.4 DELETE

[ WITH <uri> ]
DELETE { modify_template [ modify_template ]* }
[ USING [NAMED] <uri> ]*
WHERE GroupGraphPattern

The DELETE operation is similar to the DELETE/INSERT operation without an INSERT section.

If any DELETE template specifies a GRAPH then this will be the graph affected. Otherwise, the operation will be applied to the graph specified in the WITH clause, if one was specified, or the default graph otherwise.

The WHERE clause identifies data in existing graphs, and creates bindings to be used by the template. The graphs to apply the GroupGraphPattern to follow the same rules as for DELETE/INSERT.

Example:

The example below has a request to delete all records of old books (with date before year 2000) from the store's default graph

PREFIX dc:  <http://purl.org/dc/elements/1.1/>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>

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

The pattern in WHERE is matched against the graph store analogously to SPARQL - Query. The resulting variable bindings are used to instantiate the triple patterns in the DELETE template analogously to CONSTRUCT. The resulting triples are then removed from the graph store. If the pattern matching fails, no changes occur.

Example:

An example to remove all statements about anything with a first name of "Fred" from the graph http://example/addresses. No WHERE clause is present, meaning that the template also serves as the pattern to be matched.

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

WITH <http://example/addresses>
DELETE WHERE { ?person foaf:firstName 'Fred';
                       ?property      ?value }

Refer also to the final INSERT example, which demonstrates multiple operations, including a DELETE.

4.1.5 INSERT

[ WITH <uri> ]
INSERT { modify_template [ modify_template ]* }
[ [ USING [NAMED] <uri> ]*
  WHERE GroupGraphPattern ]

The INSERT operation is equivalent to the DELETE/INSERT operation without a specified DELETE section.

If the INSERT template specifies a GRAPH then this will be the graph affected. Otherwise, the operation will be applied to the graph specified in the WITH clause, if one was specified, or the default graph otherwise. If no WHERE clause is present, then the pattern will be matched in the same way: operating on the GRAPH if one is specified, or else the graph in the WITH clause, or the default graph if no other specifications are used.

The WHERE clause identifies data in existing graphs, and creates bindings to be used by the template. The graphs to apply the GroupGraphPattern to follow the same rules as for DELETE/INSERT.

Example:

This example copies records from one named graph to another named graph based on a pattern.

PREFIX dc:  <http://purl.org/dc/elements/1.1/>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>

INSERT 
  { GRAPH <http://example/bookStore2> { ?book ?p ?v } }
WHERE
  { GRAPH  <http://example/bookStore>
       { ?book dc:date ?date .
         FILTER ( ?date < "2000-01-01T00:00:00-2:00"^^xsd:dateTime )
         ?book ?p ?v
  } }	

Example:

An example to copy records from one named graph to another named graph based on a pattern. All the copied objects that are also classified as Physical Objects are then deleted. This demonstrates two operations in a single request, both of which share common PREFIX definitions.

PREFIX dc:  <http://purl.org/dc/elements/1.1/>
PREFIX dcmitype: <http://purl.org/dc/dcmitype/>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>

INSERT
  { GRAPH <http://example/bookStore2> { ?book ?p ?v } }
WHERE
  { GRAPH  <http://example/bookStore>
     { ?book dc:date ?date . 
       FILTER ( ?date < "2000-01-01T00:00:00-2:00"^^xsd:dateTime )
       ?book ?p ?v
     }
  } ;

WITH <http://example/bookStore>
DELETE
 { ?book ?p ?v }
WHERE
 { ?book dc:date ?date ;
         dc:type dcmitype:PhysicalObject .
   FILTER ( ?date < "2000-01-01T00:00:00-2:00"^^xsd:dateTime ) 
   ?book ?p ?v
 } 

4.1.6 DELETE WHERE

DELETE WHERE { modify_template [ modify_template ]* }

The DELETE WHERE operation is similar to the DELETE/INSERT operation where the triples matched by the WHERE clause will be the triples deleted.

The modify_template is used both as a GroupGraphPattern and as the template for deletion. The form for modify_template is described in DELETE/INSERT. If any modify_template specifies a GRAPH then this will be the graph that that template is matched on, and also the graph from which any matching triples will be removed. Any templates without a GRAPH statement will be applied to the default graph.

Example:

An example to remove all statements about anything with a first name of "Fred" from the default graph.

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

DELETE WHERE { ?person foaf:firstName 'Fred';
                       ?property      ?value }

Example:

Find and remove statements naming something "Fred" in the graph http://example.com/names, and also remove all statements about that resource from the graph http://example/addresses.

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

DELETE WHERE {
  GRAPH <http://example.com/names> {
    ?person foaf:firstName 'Fred'
  } .
  GRAPH <http://example.com/addresses> {
    ?person ?property ?value
  }
}

4.1.7 LOAD

The LOAD operation copies all the triples of a remote graph into the specified graph.

LOAD <documentURI> [ INTO GRAPH <uri> ]

The documentURI specifies the URI of a document such that a store will be able to identify, locate and read the document. Common forms will be URLs with the http or file protocols. Once the document has been read, the resulting triples will be inserted into the destination graph.

If no destination graph URI is provided to load the triples into, then the data will be loaded into the default graph.

4.1.8 CLEAR

The CLEAR operations removes all the triples of the specified graph or the default graph of the Graph Store if the DEFAULT keyword is used. This operation is not required to remove the empty graph from the Graph Store, but an implementation may decide to do so.

# Remove all triples.
CLEAR GRAPH ( <uri> | DEFAULT )

It has the same effect as:

# Remove all triples.
WITH <uri> DELETE { ?s ?p ?o } WHERE { ?s ?p ?o }

but is a clearer expression of emptying a graph. If the GRAPH is not specified then this will clear the default graph.

Note:

For services which form the default graph from the unions of other graphs then this may have far reaching implications.

4.2 Graph Management

Graph management operations create and destroy named graphs in the Graph Store. These operations are not required to result in any actions, since graph stores are not required to support named graphs.

The default graph in a Graph Store always exists.

4.2.1 CREATE

CREATE [ SILENT ] GRAPH <uri>

For stores that record empty graphs, this will create a new empty graph in the store with a name specified by the URI. If the graph already exists, then a failure may be returned, except when the SILENT keyword is used.

Stores that do not record empty graphs will always return success.

4.2.2 DROP

DROP [ SILENT ] GRAPH <uri>

This operation removes the specified named graph from the Graph Store associated with the SPARQL 1.1 Update service endpoint. After successful completion of this operation, the named graph is no longer available for further graph update operations.

If the store records the existence of empty graphs, then the SPARQL 1.1 Update service, by default, is expected to return failure if the specified named graph does not exist. If SILENT is present, the result of the operation will always be success.

Stores that do not record empty graphs will always return success.

5 SPARQL 1.1 Update Definition

Graph matching in SPARQL 1.1 Update is taken over from SPARQL/Query. The result of graph pattern matching is converted into triples for the actual update operation, in a way that is analogous to CONSTRUCT queries in SPARQL/Query. This is referred to in this document as a template. Refer to Substitute in the SPARQL 1.1 Query documentation for the definition of conversion from a solution for graph pattern matching into triples.

Data sets are defined in SPARQL 1.1 Update wuth USING and USING NAMED. This has precisely the same meaning as data sets specified with FROM and FROM NAMED in SPARQL 1.1 Query.

The model describing Update operations is as follows:

6 Conformance

See appendix B SPARQL 1.1 Update Grammar regarding conformance of SPARQL Update strings.

This specification is intended for use in conjunction with: the SPARQL 1.1 Uniform HTTP Protocol for Managing RDF graphs and the SPARQL 1.1 Protocol for RDF.

A Security Considerations

Exposing RDF data for update creates many security issues which any deployment must be aware of, and consider the risks involved. This submission does not describe such issues.

In addition to exposing update services over web technologies, implementers of both systems using SPARQL 1.1 Update and servers providing a graph store, must be aware that a string-based language is susceptible to insertion attacks in the construction of SPARQL 1.1 Update requests.

Issue (ISSUE-19):

Security issues on SPARQL/Update

Source: ISSUE-19

Resolution:

None recorded.

B SPARQL 1.1 Update Grammar

The operations described in this document are indicative only. The formal definition for the SPARQL 1.1 Update grammar is provided with the SPARQL 1.1 Query grammar. This is because the grammar for SPARQL 1.1 Update shares most of its structure with SPARQL 1.1 Query.

C References

C.1 Normative References

IANA-CHARSETS
(Internet Assigned Numbers Authority) Official Names for Character Sets, ed. Keld Simonsen et al. (See http://www.iana.org/assignments/character-sets.)

C.2 Other References

Aho/Ullman
Aho, Alfred V., Ravi Sethi, and Jeffrey D. Ullman. Compilers: Principles, Techniques, and Tools. Reading: Addison-Wesley, 1986, rpt. corr. 1988.
Brüggemann-Klein
Brüggemann-Klein, Anne. Formal Models in Document Processing. Habilitationsschrift. Faculty of Mathematics at the University of Freiburg, 1993. (See ftp://ftp.informatik.uni-freiburg.de/documents/papers/brueggem/habil.ps.)
Brüggemann-Klein and Wood
Brüggemann-Klein, Anne, and Derick Wood. Deterministic Regular Languages. Universität Freiburg, Institut für Informatik, Bericht 38, Oktober 1991. Extended abstract in A. Finkel, M. Jantzen, Hrsg., STACS 1992, S. 173-184. Springer-Verlag, Berlin 1992. Lecture Notes in Computer Science 577. Full version titled One-Unambiguous Regular Languages in Information and Computation 140 (2): 229-253, February 1998.
Clark
James Clark. Comparison of SGML and XML. (See http://www.w3.org/TR/NOTE-sgml-xml-971215.)
IANA-LANGCODES
(Internet Assigned Numbers Authority) Registry of Language Tags (See http://www.iana.org/assignments/language-subtag-registry.)
IETF RFC 2141
IETF (Internet Engineering Task Force). RFC 2141: URN Syntax, ed. R. Moats. 1997. (See http://www.ietf.org/rfc/rfc2141.txt.)
IETF RFC 3023
IETF (Internet Engineering Task Force). RFC 3023: XML Media Types. eds. M. Murata, S. St.Laurent, D. Kohn. 2001. (See http://www.ietf.org/rfc/rfc3023.txt.)
IETF RFC 2781
IETF (Internet Engineering Task Force). RFC 2781: UTF-16, an encoding of ISO 10646, ed. P. Hoffman, F. Yergeau. 2000. (See http://www.ietf.org/rfc/rfc2781.txt.)
ISO 639
(International Organization for Standardization). ISO 639:1988 (E). Code for the representation of names of languages. [Geneva]: International Organization for Standardization, 1988.
ISO 3166
(International Organization for Standardization). ISO 3166-1:1997 (E). Codes for the representation of names of countries and their subdivisions — Part 1: Country codes [Geneva]: International Organization for Standardization, 1997.
ISO 8879
ISO (International Organization for Standardization). ISO 8879:1986(E). Information processing — Text and Office Systems — Standard Generalized Markup Language (SGML). First edition — 1986-10-15. [Geneva]: International Organization for Standardization, 1986.
ISO/IEC 10744
ISO (International Organization for Standardization). ISO/IEC 10744-1992 (E). Information technology — Hypermedia/Time-based Structuring Language (HyTime). [Geneva]: International Organization for Standardization, 1992. Extended Facilities Annexe. [Geneva]: International Organization for Standardization, 1996.
WEBSGML
ISO (International Organization for Standardization). ISO 8879:1986 TC2. Information technology — Document Description and Processing Languages. [Geneva]: International Organization for Standardization, 1998. (See http://www.sgmlsource.com/8879/n0029.htm.)
XML Names
Tim Bray, Dave Hollander, and Andrew Layman, editors. Namespaces in XML. Textuality, Hewlett-Packard, and Microsoft. World Wide Web Consortium, 1999. (See http://www.w3.org/TR/xml-names/.)

D CVS History

$Log: Overview.html,v $
Revision 1.2  2010/06/01 17:49:04  bertails
(bertails) Changed through Jigsaw on edit.w3.org

Revision 1.2  2010/06/01 17:06:18  lfeigenb
link fixes

Revision 1.1  2010/06/01 15:41:02  lfeigenb
initial checkin

Revision 1.23  2010/05/25 16:52:03  lfeigenb
for publication

Revision 1.22  2010/05/25 16:34:22  lfeigenb
for publication

Revision 1.21  2010/05/25 15:10:01  lfeigenb
for publication

Revision 1.47  2010/05/18 21:34:42  pgearon
Updated DELETE WHERE to remove WITH and specify templates instead of a full GroupGraphPattern

Revision 1.46  2010/05/18 21:13:01  pgearon
Updated following Lee's review. Also added DELETE WHERE section

Revision 1.45  2010/05/18 14:20:21  pgearon
Removed result descriptions from individual operations

Revision 1.44  2010/05/17 09:28:33  apassant
Updated document following Lee's review

Revision 1.43  2010/05/06 17:29:54  pgearon
Updated LOAD and CLEAR to explicitly refer to the DEFAULT graph

Revision 1.42  2010/05/06 02:43:24  pgearon
Added a link to the Query grammar in Appendix B, for the update grammar. USING/USING-NAMED has been added to DELETE-WHERE and INSERT-WHERE. Return codes have been added to each operation.

Revision 1.41  2010/04/30 16:15:21  pgearon
Reverted last change. WITH duplicates GRAPH for DATA updates

Revision 1.40  2010/04/30 15:02:04  pgearon
Added WITH to INSERT DATA and DELETE DATA

Revision 1.39  2010/04/28 03:12:43  pgearon
Added statement on model of update. Provided example of equivalence to the use of WITH. Mentioned semicolon terminators. Changed the name of INSERT/DELETE to DELETE/INSERT to reflect usage. Removed ISSUE 51, and introduced USING/USING NAMED.

Revision 1.38  2010/03/29 21:05:21  pgearon
- Commented that CREATE/DROP may be at risk.
- Multiple commands require ; separator.
- CLEAR can now be used on the default graph.
- Cleared up usage of "default graph" and "unnamed graph".
- Added explanation that multiple operations in a request SHOULD be
  executed atomically. Provided examples where this may not be feasible.
- Comment on the relationship between atomicity and concurrency.
- Added comment on deleting entailed data.
- Added comment on needing to perform consistency checking at the end of
  and update operation.

Revision 1.37  2010/03/16 18:27:25  pgearon
Added comment allowing anonymous blank nodes in short-form delete

Revision 1.36  2010/03/16 05:20:05  pgearon
Added a comment about not using blank nodes in the short-form DELETE operation

Revision 1.35  2010/03/16 05:01:48  pgearon
INSERT operations may now create a graph

Revision 1.34  2010/01/27 01:23:31  apollere2
Removed div2 in CVS history that had a problematic effect on the generated TOC.

Revision 1.33  2010/01/22 01:42:05  apollere2
Adapted shortname.

Revision 1.32  2010/01/22 01:37:25  apollere2
Changed date to 26.

Revision 1.31  2010/01/19 15:24:10  pgearon
Added ISSUE-51

Revision 1.30  2010/01/19 15:05:03  pgearon
Fixed typo

Revision 1.29  2010/01/19 01:41:43  pgearon
Removed extra ; character from DELETE/INSERT example in 4.1.2

Revision 1.28  2010/01/18 20:30:00  pgearon
Removed duplicate reference to ISSUE-19 and reference to ISSUE-21 as it has now been closed

Revision 1.27  2010/01/18 20:15:07  pgearon
updated a duplicated ID

Revision 1.26  2010/01/18 20:12:46  pgearon
Removed semicolon from DELETE/INSERT statements

Revision 1.25  2010/01/15 19:15:35  pgearon
Added a Terminology section.
Removed Property Paths now that issue 38 has been resolved.
Included reference to RFC 2119 terminology and added emphasized SHOULD and OPTIONAL comments.
Added note on discussion of blank nodes in DELETE templates.
Added note on discussion of INSERTs creating new graphs.
Added note on ambiguity around DELETE/INSERT and DELETE statements.
Added note on need to mention partially completed LOAD operations.
Added OPTIONAL description for graph management operations.

Revision 1.24  2010/01/07 22:17:44  pgearon
Finished updates recommended by AxelP

Revision 1.23  2010/01/07 18:34:12  pgearon
Finished updates recommended by AndyS

Revision 1.22  2010/01/05 01:33:43  pgearon
Some up the cleanups requested by Andy, including commenting out the grammar

Revision 1.21  2009/12/19 03:36:00  pgearon
Updated the date

Revision 1.20  2009/12/19 03:30:20  pgearon
Updated to go from INSERT-INTO/DELETE-FROM to GRAPH {template} constructs

Revision 1.19  2009/12/01 02:02:47  pgearon
Removed extraneous parenthesis

Revision 1.18  2009/12/01 01:47:32  pgearon
Cleaned up syntax a little for INSERT/DELETE

Revision 1.17  2009/11/30 23:14:55  pgearon
First attempt at INSERT/DELETE syntax. Not happy wiht this still

Revision 1.16  2009/10/21 03:35:31  lfeigenb
publication prep

Revision 1.15  2009/10/20 20:50:37  lfeigenb
validation errors

Revision 1.14  2009/10/20 19:45:52  lfeigenb
small fixes for naming and cleanup

Revision 1.13  2009/10/20 19:10:19  lfeigenb
Fixed and added support for markup that was previously unsupported by our XSLTs.

Future SPARQL-specific customizations should go in shared/sparql.xsl

Revision 1.12  2009/10/20 14:40:52  pgearon
Removed reference to ISSUE-22

Revision 1.11  2009/10/20 07:45:16  sschenk
turned notes into issues: ISSUES 45-48

Revision 1.10  2009/10/17 15:05:21  pgearon
changed cvs log details as it included some half baked html

Revision 1.9  2009/10/16 21:54:54  pgearon
Updates as per email from Luke Wilson-Mawer on October 16, 2009. Also converted <i> to <em> and removed <span class="prod"> from the grammar.

Revision 1.8  2009/10/15 09:42:40  sschenk
address comments in
http://lists.w3.org/Archives/Public/public-rdf-dawg/2009OctDec/0041.html

Revision 1.7  2009/10/14 10:07:02  sschenk
zero modification commit to fix R1.6 commit message

Revision 1.6  2009/10/14 09:36:53  sschenk
convert all @@todos into issue or note

Revision 1.5  2009/10/13 10:20:40  sschenk
restructuring and section renaming

Revision 1.4  2009/10/11 19:53:47  sschenk
Add dtd, xsls for update, update grammar

Revision 1.1  2009/09/14 21:17:28  eric
CREATED