Warning:
This wiki has been archived and is now read-only.

Diff SPARQL Turtle

From RDF Working Group Wiki
Jump to: navigation, search

This page gathers together difference between SPARQL 1.0 and Turtle.

See also:

Relevant RDF WG Decisions

See also:

Decimals

18. 

is changed to

18.0

bNode property lists

[ :p 1 ; :q 2 ] .

is valid SPARQL, including SPARQL 1.0, but not Turtle (and is legal in N3) - in Turtle only explicit subject forms are legal.

Turtle allows forms like:

[] :p 1 ; :q 2 .
[ :p 1 ] :q 2 .

Legal SPARQL:

INSERT DATA
{
  [  :p 1 ; :q 2 ] .
  [  :p 3 ; :q 4 ]
}
SELECT * { [ :p 1 ; :q 2 ] }

RDF Collections

A less frequent case is a free-standing lists and subject lists.

(1 2 3 4) .
SELECT * { (1 ?x 3 4) . }
SELECT * { (1 2) rdfs:comment "List" }

Turtle allows

(1 2 3 4) rdfs:comment "List" .

but not

(1 2 3 4) .

Trailing dots

A final DOT is not required in SPARQL:

INSERT DATA { :s :p :o }
SELECT *
WHERE
{
   ?z a foaf:Person ;
      foaf:name ?name ;
      foaf:knows [ foaf:name ?name2 ]
}

This is more significant when TriG is considered.

Strings

Using ' and ''' for string quoting is legal in SPARQL. Because SPARQL queries can be embedded in programs, allowing a character that does not require programming language quoting is useful.

Added in the Turtle working draft (v 1.13): String production.

Local part of prefix names can begin with a number

This was a change made to SPARQL during the per-LC development phase due to user feedback. Groups found that it was inconvenient in situations where all numeric identifiers from non-RDF data arose naturally

e.g.

employee:00154337

Added in the Turtle working draft (v 1.13): PN_LOCAL token.

Escape Processing

Turtle and SPARQL treat \u escape processing differently.

SPARQL Codepoint Escape Sequences defines \u processing to happen on the input stream charcater stream before the grammar is applied. \u esacpes are converted to the codepoint and any significant characters (e.g. delimiter ") apply as usual.

Turtle String Escapes happen after parsing, and only in strings and IRI references. Significant characters do not delimit. Does not apply to prefixed names.

Legal and the same in both (for different reasons):

"\u03B1"            # "α" Codepoint x03B1 is Greek small alpha
<ab\u00E9xy>        # Codepoint 00E9 is Latin small e with acute - é

Legal in both but different:

#\u0020Comment

Legal SPARQL, illegal in Turtle (see extension below):

a:\u03B1

Legal SPARQL, illegal in Turtle: uses a syntax-significant character.

a\u003Ab            # a:b -- codepoint x3A is colon

Legal in Turtle, illegal in SPARQL

"ab\u0022cd"        # x22 is "

Possible extension to Turtle

Adding a UCHAR to the qname characters enables \u03B1:a, per yacker results for

 @prefix α: <> .
 <ab\u00E9xy> \u03B1:p "ab\u0022cd" .