Copyright © 2009 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This document describes SPARQL-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.
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 the First Public Working Draft of the "SPARQL 1.1 Update" specification for review by W3C members and other interested parties.
If you wish to make comments regarding this document, please send them to public-rdf-dawg-comments@w3.org (subscribe, archives)
Implementors should be aware that this specification is not stable. Implementors who are not taking part in the discussions are likely to find the specification changing out from under them in incompatible ways. Vendors interested in implementing this specification before it eventually reaches the Candidate Recommendation stage should join the aforementioned mailing lists and take part in the discussions.
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.
The publication of this document by the W3C as a W3C Working Draft does not imply that all of the participants in the W3C SPARQL working group endorse the contents of the specification. Indeed, for any section of the specification, one can usually find many members of the working group or of the W3C as a whole who object strongly to the current text, the existence of the section at all, or the idea that the working group should even spend time discussing the concept of that section.
The W3C SPARQL Working Group is the W3C working group responsible for this specification's progress along the W3C Recommendation track.
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.
1 Introduction
1.1 Scope and Limitations
1.2 Document Conventions
2 Relation to new features in SPARQL 1.1
2.1 SubQueries
2.2 BGP extensions of different entailment regimes
2.3 Basic Federated Query
2.4 Property Paths
3 Examples
4 The Graph Store
4.1 Graph Store and SPARQL Query Services
4.2 SPARQL-Update Services
5 Syntax
5.1 Graph Update
5.1.1 INSERT DATA
5.1.2 DELETE DATA
5.1.3 MODIFY
5.1.4 DELETE
5.1.5 INSERT
5.1.6 LOAD
5.1.7 CLEAR
5.2 Graph Management
5.2.1 Graph Creation
5.2.2 Graph Removal
6 SPARQL-Update Definition
A Security Considerations
B SPARQL-Update Grammar
C References
C.1 Normative References
C.2 Other References
D CVS History
D.1
SPARQL-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-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-Update provides the following facilities:
Related work:
SPARQL-Update is not:
Language forms are show as:
INSERT { template } [ WHERE { pattern } ][] 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.
Examples are shown as:
PREFIX dc: <http://purl.org/dc/elements/1.1/>
INSERT { <http://example/egbook3> dc:title "This is an example title" }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.
Can subqueries (ASK, SELECT etc.) be nested inside update queries?
Source: ISSUE-27
Resolution:
None recorded.
Can INSERTS, DELETES, and other 'subupdates' be nested inside SELECT queries?
Source: ISSUE-45
Resolution:
None recorded.
Can INSERTS, DELETES, and other 'subupdates' be nested inside update language queries?
Source: ISSUE-46
Resolution:
None recorded.
Can data be SELECTed from one graph and INSERTed into another (moved)?
Source: ISSUE-24
Resolution:
None recorded.
There are issues around what it means to delete triples under an entailment regime - triples can be deleted but are still present.
Basic federated update could allow the moving of triples between stores.
How does basic federated query interact with SPARQL/Update?
Source: ISSUE-37
Resolution:
None recorded.
Using property paths in Update seems to lead to quite a lot of complexity quite quickly.
This section gives some example snippets in the Update language.
(a) Adding some triples to a graph. The 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" .
}(b) This SPARQL-Update request contains a triple to be deleted and a triple
to be added (used here to correct a book title). 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 FROM <http://example/bookStore>
{ <http://example/book3> dc:title "Fundamentals of Compiler Desing" }
INSERT DATA INTO <http://example/bookStore>
{ <http://example/book3> dc:title "Fundamentals of Compiler Design" }
(c) The example below has a request to delete all records of old books (with date before year 2000)
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 are done.
(d) This snippet 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 INTO <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
} } (e) An example to move 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 INTO <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
}
}
DELETE FROM <http://example/bookStore>
{ ?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
}
} (f) An example to update people with the name "Bill" to "William".
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
MODIFY <http://example/addresses>
DELETE { ?person foaf:firstName 'Bill' }
INSERT { ?person foaf:firstName 'William' }
WHERE
{ ?person a foaf:Person .
?person foaf:firstName 'Bill'
} 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-Update is a language for the update of a single graph.
Source: ISSUE-20
Resolution:
None recorded.
Note:
Depending on the outcome of ISSUE-20, the number of unnamed graphs might be fixed to one or be zero or one.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.SPARQL-Update requests are a sequence of operations. Each request should be treated atomically by a SPARQL-Update service.
Note:
SPARQL/Update requests need to be definedIn 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-Update end points are the same.
SPARQL-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.
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 operation of a graph update is MODIFY. There are two
restricted forms for INSERT and DELETE of triples by
pattern; both are special cases of the
MODIFY operation. A modify operation consists of a group of triples to be deleted and a
group of triples to be added. The specification of the triples is based on a
query pattern.
The difference between MODIFY / 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.
Insert data into a graph:
INSERT DATA [ INTO <uri> ]*
{ triples }
An example query is shown in example 3(a).
Delete data from a graph:
DELETE DATA [ FROM <uri> ]*
{ triples }
An example query is shown in example 3(b).
# UPDATE outline syntax : general form:
MODIFY [ <uri> ]*
DELETE { template }
INSERT { template }
[ WHERE { pattern } ]The template and pattern forms are as defined in SPARQL for construct templates and graph patterns.
The deletion of the triples happens before the insertion. The pattern in
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 pattern is evaluated as in a SPARQL query SELECT * WHERE { pattern }
and all the named variables are made available to the INSERT template
and the DELETE template for defining the triples to be inserted or
deleted.
The <uri> clause names the graph in the graph store to be
updated; if omitted, the MODIFY applies to the unnamed graph.
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.
The DELETE operation is similar to the MODIFY operation with
an empty INSERT template. The graph
URI, if present, must be a valid named graph in the Graph Store.
DELETE [ FROM <uri> ]* { template } [ WHERE { pattern } ]# Equivalent to
MODIFY [ <uri> ]*
DELETE { template }
INSERT { }
[ WHERE { pattern } ]
An example query is shown in example 3(c).
The INSERT operation is similar to the MODIFY operation with
an empty DELETE template. The graph
URI, if present, must be a valid named graph in the Graph Store. The
CREATE graph management operator should be used to create a new named
graph in the Graph Store.
INSERT [ INTO <uri> ]* { template } [ WHERE { pattern } ]#Equivalent to
MODIFY [ GRAPH <uri> ]*
DELETE { }
INSERT { template }
[ WHERE { pattern } ]
An example query is shown in example 3(d).
Note:
The Working group also considers a different syntax fortemplate, which is not based on CONSTRUCT Syntax, but on GraphGraphPatterns:
INSERT {GRAPH graphname {template} }Can the graph to insert data into be dynamically set based on a variable's bindings?
Source: ISSUE-25
Resolution:
None recorded.
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> ]
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.
DELETE [ <uri> ] { ?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.i
Note:
For services which form the default graph from the unions of other graphs then this may have far reaching implications.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.
The default graph in a Graph Store always exists.
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 MODIFY, INSERT and DELETE operators.
The SPARQL-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-Update operations continues.
DROP [ SILENT ] GRAPH <uri>
This operation removes the specified named graph from the Graph Store associated with the SPARQL-Update service endpoint. After successful completion of this operation, the named graph is no more available for further graph update operations.
The SPARQL-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-Update operations continues.
Note:
We need to define an algebra operator for conversion of bindings to triples. The operator depends on syntax decision for INSERT based on CONSTRUCT or GroupGraphPattern.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-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-Update requests.
Rules from rule 16, Prologue, are taken from the SPARQL grammar.
Note: This grammar does not use special rules for parsing INSERT DATA/DELETE DATA where only triples, not triple patterns (allowing named variables) are allowed. It assumes the update processor will check template contains only ground triples.
[1] | Prologue | ::= | (BaseDecl)? (PrefixDecl)* |
[2] | BaseDecl | ::= | "BASE" IRI_REF |
[3] | PrefixDecl | ::= | "PREFIX" PNAME_NS IRI_REF |
[4] | UpdateUnit | ::= | Prologue (( Update | Manage ))* |
[5] | Update | ::= | Modify |
[6] | Modify | ::= | "MODIFY" (GraphIRI)* "DELETE" ConstructTemplate "INSERT" ConstructTemplate (UpdatePattern)? |
[7] | Delete | ::= | "DELETE" ( DeleteData | DeleteTemplate ) |
[8] | DeleteData | ::= | "DATA" (( ("FROM")? IRIref ))* ConstructTemplate |
[9] | DeleteTemplate | ::= | (( ("FROM")? IRIref ))* ConstructTemplate (UpdatePattern)? |
[10] | Insert | ::= | "INSERT" ( InsertData | InsertTemplate ) |
[11] | InsertData | ::= | "DATA" (( ("INTO")? IRIref ))* ConstructTemplate |
[12] | InsertTemplate | ::= | (( ("INTO")? IRIref ))* ConstructTemplate (UpdatePattern)? |
[13] | GraphIRI | ::= | "GRAPH" IRIref |
[14] | Load | ::= | "LOAD" (IRIref)+ (( "INTO" IRIref ))? |
[15] | Clear | ::= | "CLEAR" (GraphIRI)? |
[16] | Manage | ::= | Create |
[17] | Create | ::= | "CREATE" ("SILENT")? GraphIRI |
[18] | Drop | ::= | "DROP" ("SILENT")? GraphIRI |
[19] | UpdatePattern | ::= | ("WHERE")? GroupGraphPattern |
[20] | GroupGraphPattern | ::= | "{" ( SubSelect | GroupGraphPatternSub ) "}" |
[21] | GroupGraphPatternSub | ::= | (TriplesBlock)? (( ( GraphPatternNotTriples | Filter ) (".")? (TriplesBlock)? ))* |
[22] | TriplesBlock | ::= | TriplesSameSubjectPath (( "." (TriplesBlock)? ))? |
[23] | GraphPatternNotTriples | ::= | OptionalGraphPattern |
[24] | OptionalGraphPattern | ::= | "OPTIONAL" GroupGraphPattern |
[25] | GraphGraphPattern | ::= | "GRAPH" VarOrIRIref GroupGraphPattern |
[26] | ExistsElt | ::= | "EXISTS" GroupGraphPattern |
[27] | NotExistsElt | ::= | ( "UNSAID" | "NOT EXISTS" ) GroupGraphPattern |
[28] | GroupOrUnionGraphPattern | ::= | GroupGraphPattern (( "UNION" GroupGraphPattern ))* |
[29] | Filter | ::= | "FILTER" Constraint |
[30] | Constraint | ::= | BrackettedExpression |
[31] | FunctionCall | ::= | IRIref ArgList |
[32] | ArgList | ::= | ( NIL | "(" Expression (( "," Expression ))* ")" ) |
[33] | TriplesSameSubject | ::= | VarOrTerm PropertyListNotEmpty |
[34] | PropertyListNotEmpty | ::= | Verb ObjectList (( ";" (( Verb ObjectList ))? ))* |
[35] | PropertyList | ::= | (PropertyListNotEmpty)? |
[36] | ObjectList | ::= | Object (( "," Object ))* |
[37] | Object | ::= | GraphNode |
[38] | Verb | ::= | VarOrIRIref |
[39] | TriplesSameSubjectPath | ::= | VarOrTerm PropertyListNotEmptyPath |
[40] | PropertyListNotEmptyPath | ::= | ( VerbPath | VerbSimple ) ObjectList (( ";" (( ( VerbPath | VerbSimple ) ObjectList ))? ))* |
[41] | PropertyListPath | ::= | (PropertyListNotEmpty)? |
[42] | VerbPath | ::= | Path |
[43] | VerbSimple | ::= | Var |
[44] | PathUnit | ::= | Path |
[45] | Path | ::= | PathAlternative |
[46] | PathAlternative | ::= | PathSequence (( "|" PathSequence ))* |
[47] | PathSequence | ::= | PathEltOrReverse (( "/" PathEltOrReverse | "^" PathElt ))* |
[48] | PathElt | ::= | PathPrimary (PathMod)? |
[49] | PathEltOrReverse | ::= | PathElt |
[50] | PathMod | ::= | ( "*" | "?" | "+" | "{" ( Integer ( "," ( "}" | Integer "}" ) | "}" ) ) ) |
[51] | PathPrimary | ::= | ( IRIref | "a" | "(" Path ")" ) |
[52] | Integer | ::= | INTEGER |
[53] | TriplesNode | ::= | Collection |
[54] | BlankNodePropertyList | ::= | "[" PropertyListNotEmpty "]" |
[55] | Collection | ::= | "(" (GraphNode)+ ")" |
[56] | GraphNode | ::= | VarOrTerm |
[57] | VarOrTerm | ::= | Var |
[58] | VarOrIRIref | ::= | Var |
[59] | Var | ::= | VAR1 |
[60] | GraphTerm | ::= | IRIref |
[61] | Expression | ::= | ConditionalOrExpression |
[62] | ConditionalOrExpression | ::= | ConditionalAndExpression (( "||" ConditionalAndExpression ))* |
[63] | ConditionalAndExpression | ::= | ValueLogical (( "&&" ValueLogical ))* |
[64] | ValueLogical | ::= | RelationalExpression |
[65] | RelationalExpression | ::= | NumericExpression (( "=" NumericExpression | "!=" NumericExpression | "<" NumericExpression | ">" NumericExpression | "<=" NumericExpression | ">=" NumericExpression ))? |
[66] | NumericExpression | ::= | AdditiveExpression |
[67] | AdditiveExpression | ::= | MultiplicativeExpression (( "+" MultiplicativeExpression | "-" MultiplicativeExpression | ( NumericLiteralPositive | NumericLiteralNegative ) (( ( "*" UnaryExpression ) | ( "/" UnaryExpression ) ))? ))* |
[68] | MultiplicativeExpression | ::= | UnaryExpression (( "*" UnaryExpression | "/" UnaryExpression ))* |
[69] | UnaryExpression | ::= | "!" PrimaryExpression |
[70] | PrimaryExpression | ::= | BrackettedExpression |
[71] | BrackettedExpression | ::= | "(" Expression ")" |
[72] | BuiltInCall | ::= | "STR" "(" Expression ")" |
[73] | RegexExpression | ::= | "REGEX" "(" Expression "," Expression (( "," Expression ))? ")" |
[74] | ExistsFunc | ::= | "EXISTS" GroupGraphPattern |
[75] | NotExistsFunc | ::= | ( "UNSAID" | "NOT EXISTS" ) GroupGraphPattern |
[76] | Aggregate | ::= | ( "COUNT" "(" ( "*" | Var | "DISTINCT" ( "*" | Var ) ) ")" | "SUM" "(" Expression ")" | "MIN" "(" Expression ")" | "MAX" "(" Expression ")" | "AVG" "(" Expression ")" ) |
[77] | IRIrefOrFunction | ::= | IRIref (ArgList)? |
[78] | RDFLiteral | ::= | String (( LANGTAG | ( "^^" IRIref ) ))? |
[79] | NumericLiteral | ::= | NumericLiteralUnsigned |
[80] | NumericLiteralUnsigned | ::= | INTEGER |
[81] | NumericLiteralPositive | ::= | INTEGER_POSITIVE |
[82] | NumericLiteralNegative | ::= | INTEGER_NEGATIVE |
[83] | BooleanLiteral | ::= | "true" |
[84] | String | ::= | STRING_LITERAL1 |
[85] | IRIref | ::= | IRI_REF |
[86] | PrefixedName | ::= | PNAME_LN |
[87] | BlankNode | ::= | BLANK_NODE_LABEL |
[88] | <IRI_REF> | ::= | "<" (( [^<>\"{}|^`\\] - [#0000- ] ))* ">" |
[89] | <PNAME_NS> | ::= | (PN_PREFIX)? ":" |
[90] | <PNAME_LN> | ::= | PNAME_NS PN_LOCAL |
[91] | <BLANK_NODE_LABEL> | ::= | "_:" PN_LOCAL |
[92] | <VAR1> | ::= | "?" VARNAME |
[93] | <VAR2> | ::= | "$" VARNAME |
[94] | <LANGTAG> | ::= | "@" ([a-zA-Z])+ (( "-" ([a-zA-Z0-9])+ ))* |
[95] | <INTEGER> | ::= | ([0-9])+ |
[96] | <DECIMAL> | ::= | ([0-9])+ "." ([0-9])* |
[97] | <DOUBLE> | ::= | ([0-9])+ "." ([0-9])* EXPONENT |
[98] | <INTEGER_POSITIVE> | ::= | "+" INTEGER |
[99] | <DECIMAL_POSITIVE> | ::= | "+" DECIMAL |
[100] | <DOUBLE_POSITIVE> | ::= | "+" DOUBLE |
[101] | <INTEGER_NEGATIVE> | ::= | "-" INTEGER |
[102] | <DECIMAL_NEGATIVE> | ::= | "-" DECIMAL |
[103] | <DOUBLE_NEGATIVE> | ::= | "-" DOUBLE |
[104] | <EXPONENT> | ::= | [eE] ([+-])? ([0-9])+ |
[105] | <STRING_LITERAL1> | ::= | "'" (( ( [^'\\\n\r] ) | ECHAR ))* "'" |
[106] | <STRING_LITERAL2> | ::= | '"' (( ( [^\"\\\n\r] ) | ECHAR ))* '"' |
[107] | <STRING_LITERAL_LONG1> | ::= | "'''" (( (( "'" | "''" ))? ( [^'\\] | ECHAR ) ))* "'''" |
[108] | <STRING_LITERAL_LONG2> | ::= | '"""' (( (( '"' | '""' ))? ( [^\"\\] | ECHAR ) ))* '"""' |
[109] | <ECHAR> | ::= | "\\" [tbnrf\\\"'] |
[110] | <NIL> | ::= | "(" (WS)* ")" |
[111] | <WS> | ::= | " " |
[112] | <ANON> | ::= | "[" (WS)* "]" |
[113] | <PN_CHARS_BASE> | ::= | [A-Z] |
[114] | <PN_CHARS_U> | ::= | PN_CHARS_BASE |
[115] | <VARNAME> | ::= | ( PN_CHARS_U | [0-9] ) (( PN_CHARS_U | [0-9] | #00B7 | [#0300-#036F] | [#203F-#2040] ))* |
[116] | <PN_CHARS> | ::= | PN_CHARS_U |
[117] | <PN_PREFIX> | ::= | PN_CHARS_BASE (( (( PN_CHARS | "." ))* PN_CHARS ))? |
[118] | <PN_LOCAL> | ::= | ( PN_CHARS_U | [0-9] ) (( (( PN_CHARS | "." ))* PN_CHARS ))? |
[119] | PASSED TOKENS | ::= | ([ \t\r\n])+ |
$Log: Overview.html,v $ Revision 1.5 2018/10/09 13:28:22 denis fix validation of xhtml documents Revision 1.4 2017/10/02 10:39:34 denis add fixup.js to old specs Revision 1.3 2009/10/23 14:16:51 ivan *** empty log message *** Revision 1.2 2009/10/22 07:22:09 ivan *** empty log message *** Revision 1.1 2009/10/21 14:26:23 ivan *** empty log message *** Revision 1.6 2009/10/21 12:57:48 lfeigenb remove broken links to grammar pieces Revision 1.5 2009/10/21 12:50:22 lfeigenb fix broken grammar links Revision 1.4 2009/10/21 03:36:18 lfeigenb version order fix Revision 1.3 2009/10/21 03:35:31 lfeigenb publication prep Revision 1.2 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