W3C

SPARQL 1.1 Update

W3C Working Draft 26 January 2010

This version:
http://www.w3.org/TR/2010/WD-sparql11-update-20100126/
Latest version:
http://www.w3.org/TR/sparql11-update/
Previous version:
http://www.w3.org/TR/2009/WD-sparql11-update-20091022/
Editors:
Simon Schenk <sschenk@uni-koblenz.de>
Paul Gearon <gearon@computer.org>

Abstract

This document describes SPARQL 1.1 Update, an update language for RDF graphs. It uses a syntax derived from SPARQL. 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

Compared to the FPWD mainly the MODIFY clause has been removed in the generic DELETE/INSERT construct, and shortcuts for DELETE and INSERT have been defined in case the WHERE part is identical to the DELETE or INSERT clause. In DELETE and INSERT clauses, as opposed to FPWD, not only BGPs are allowed, but also GRAPH graph patterns in order to model insertion/deletion into/from different graphs in a single DELETE/INSERT construct. The respective examples in Section 3 have been updated.

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 BGP extensions of different entailment regimes
    2.2 Basic Federated Query
3 The Graph Store
    3.1 Graph Store and SPARQL Query Services
    3.2 SPARQL 1.1 Update Services
4 Syntax
    4.1 Graph Update
        4.1.1 INSERT DATA
        4.1.2 DELETE DATA
        4.1.3 INSERT/DELETE
        4.1.4 DELETE
        4.1.5 INSERT
        4.1.6 LOAD
        4.1.7 CLEAR
    4.2 Graph Management
        4.2.1 Graph Creation
        4.2.2 Graph Removal
5 SPARQL 1.1 Update Definition

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 mechanism by which updates to a remote RDF Store can be described, communicated and stored. 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 query processors, 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 requests.

Italics indicate an item is some syntax element derived from SPARQL. 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 BGP extensions of different entailment regimes

There are issues around what it means to delete triples under an entailment regime - triples can be deleted but are still present.

Issue (ISSUE-28):

Entailment regimes vs. update?

Source: ISSUE-28

Resolution:

None recorded.

2.2 Basic Federated Query

Basic federated update could allow the moving of triples between stores.

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. 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 default graph and no named graphs, SPARQL 1.1 Update is a language for the update of a single graph.

Issue (ISSUE-20):

Difference between an empty graph and a non-existent graph?

Source: ISSUE-20

Resolution:

None recorded.

Issue (ISSUE-51):

Shall dataset clauses be allowed in SPARQL/update?

Source: ISSUE-51

Resolution:

None recorded.

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

3.1 Graph Store and SPARQL Query Services

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. The dataset of the query service may be formed from graphs managed by the update service but the dataset requested by the query can be a subset of the graphs in the update service dataset and the names of those graphs may be different. The composition of the RDF dataset may also change.

Note:

Can a SELECT and an INSERT be done in the same query? If so, it seems we throw away the security benefit of having a separate query and update language. See section 2.1 for issues related to this question.

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. SPARQL 1.1 Update services are provided over the SPARQL 1.1 Protocol for RDF.

Note:

SPARQL/Update requests need to be defined

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.

Issue (ISSUE-26):

How far do we go with transactions/atomicity?

Source: ISSUE-26

Resolution:

None recorded.

Issue (ISSUE-18):

Concurrency issues?

Source: ISSUE-18

Resolution:

None recorded.

4 Syntax

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

Multiple operations can be packed into requests. The operations of a request are executed in lexical order.

4.1 Graph Update

Graph update operations change existing graphs in the Graph Store but do not create or delete them.

Note:

This behaviour is at risk and may change depending on the outcome of ISSUE-20.

The INSERT DATA operation adds some triples, which are inline in the request, into a graph.

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.

The only results possible from an operation are success or failure. How these results are represented is for the protocol to define.

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.

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.

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" } }

INSERT DATA
{ GRAPH <http://example/bookStore> { <http://example/book3>  dc:title  "Fundamentals of Compiler Design" } }

4.1.3 INSERT/DELETE

# UPDATE outline syntax : general form:
[ WITH <uri> ]
DELETE { modify_template [ modify_template ]* }
INSERT { modify_template [ modify_template ]* }
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.

Note:

There is ongoing discussion over the meaning of blank nodes in the modify_template for DELETE, including whether or not blank nodes should even be allowed in this template.

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 provdided, then the unnamed graph 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 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 unnamed graph if no WITH clause is present.

If the operation is on a graph that does not exist, an error is generated. Graphs are not created by the graph update operations. The graph management operations have to be used to create new graphs.

Note:

This behavior is under discussion. A future revision may permit insertions to create a new graph.

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

Note:

The syntax of this operation can be ambiguous when juxtaposed with INSERT/DELETE. Alternatives are to include an optional semicolon at the end of each operation, and to change this operation to "DELETE WHERE". This is under active discussion.
[ WITH <uri> ]
DELETE { modify_template [ modify_template ]* }
[ WHERE GroupGraphPattern ]

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

If the WHERE clause is not present, then the delete template is also treated as the pattern for the effective WHERE clause. Because a template used in this way must also be a valid pattern, it may not contain blank nodes.

If the 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 unnamed 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 unnamed graph if no other specifications are used.

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 { ?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 ]* }
WHERE GroupGraphPattern

The INSERT operation is equivalent to the INSERT/DELETE 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 unnamed 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 unnamed graph if no other specifications are used.

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 LOAD

The LOAD operation copies all the triples of a remote graph into the specified graph, or if not specified, the default graph of the Graph Store.

LOAD <documentURI> [ INTO <uri> ]

Note:

Some mention of partial loads should be made.

4.1.7 CLEAR

The CLEAR operations removes all the triples of the specified graph or if not specified, the default graph of the Graph Store. This operation does not remove the graph from the Graph Store.

Note:

This behaviour is at risk and depends on the outcome of ISSUE-20
# Remove all triples.
  CLEAR [ GRAPH <uri> ]

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

Note:

The behaviour described in this section is at risk and depends on the outcome of ISSUE-20.

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

The default graph in a Graph Store always exists.

4.2.1 Graph Creation

CREATE [ SILENT ] GRAPH <uri>

This operation creates a new named graph with a name as specified by the URI. After the successful completion of this operation, the new named graph is available for any further graph update operations with INSERT and DELETE operators.

The SPARQL 1.1 Update service generates an error if the graph referred to by the URI already exists unless the keyword SILENT is present, in which case no error is generated and execution of the sequence of SPARQL 1.1 Update operations continues.

4.2.2 Graph Removal

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 more available for further graph update operations.

The SPARQL 1.1 Update service, by default, is expected to generate an error if the specified named graph does not exist. If SILENT is present, this error is ignored and execution of a sequence of SPARQL 1.1 Update operations continues.

5 SPARQL 1.1 Update Definition

Graph matching in SPARQL 1.1 Update is taken over from SPARQL/Query. Analogous to CONSTRUCT queries in SPARQL/Query, the result of graph pattern matching is converted into triples for the actual update operation. Refer to Substitute in the SPARQL 1.1 Query documentation for the definition of conversion from a solution for graph pattern matching into triples.

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

TODO

Note:

Recent changes have made the latest version of the grammar out of sync with the rest of this document. This section will be left offline until it is back in sync.

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.1  2010/01/27 16:24:11  bertails
sparql

Revision 1.14  2010/01/27 01:17:35  apollere2
Removed broken link inCVS log section.

Revision 1.13  2010/01/24 20:39:42  apollere2
Removed "Editors' working draft", now "Working Draft".

Revision 1.12  2010/01/22 01:47:16  apollere2
Added change summary.

Revision 1.11  2010/01/22 01:43:50  apollere2
Shortname fixed in one more place.

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

Revision 1.9  2010/01/22 01:39:28  apollere2
Added no-endorsement boilerplate.

Revision 1.8  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