The
Resource
Description
Framework
(
RDF
)
is
a
general-purpose
language
for
representing
information
in
the
Web.
This
document
defines
a
textual
syntax
for
RDF
called
Turtle
that
allows
an
RDF
graph
to
be
completely
written
in
a
compact
and
natural
text
form,
with
abbreviations
for
common
usage
patterns
and
datatypes.
Turtle
provides
levels
of
compatibility
with
the
N-Triples
[
RDF12-N-TRIPLES
]
format
as
well
as
the
triple
pattern
syntax
of
SPARQL
1.2
Query
Language
W3C
Recommendation.
Do
not
attempt
to
implement
this
version
of
the
specification.
Do
not
reference
this
version
as
authoritative
in
any
way.
Instead,
see
https://w3c.github.io/rdf-turtle/spec/
for
the
Editor's
draft.
This
section
describes
the
status
of
this
document
at
the
time
of
its
publication.
A
list
of
current
W3C
publications
and
the
latest
revision
of
this
technical
report
can
be
found
in
the
W3C
standards
and
drafts
index
.
This
document
is
a
part
of
the
RDF
1.2
document
suite.
The
document
defines
Turtle,
the
Terse
RDF
Triple
Language,
a
concrete
syntax
for
RDF
[
RDF12-CONCEPTS
].
Publication
as
an
Editor's
Draft
does
not
imply
endorsement
by
W3C
and
its
Members.
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
a
work
in
progress.
Future
updates
to
this
specification
may
incorporate
new
features
.
This
document
defines
Turtle,
the
Terse
RDF
Triple
Language,
a
concrete
syntax
for
RDF
[
RDF12-CONCEPTS
].
A
Turtle
document
is
a
textual
representations
of
an
RDF
graph
.
The
following
Turtle
document
describes
the
relationship
between
Green
Goblin
and
Spiderman.
Often
the
same
subject
will
be
referenced
by
a
number
of
predicates.
The
predicateObjectList
production
matches
a
series
of
predicates
and
objects,
separated
by
;
,
following
a
subject.
This
expresses
a
series
of
RDF
Triples
with
that
subject
and
each
predicate
and
object
allocated
to
one
triple.
Thus,
the
;
is
used
to
repeat
the
subject
of
triples
that
vary
only
in
predicate
and
object
RDF
terms
.
These
two
examples
are
equivalent
ways
of
writing
the
triples
about
Spiderman.
As
with
predicates,
the
same
subject
and
predicate
often
repeat
with
different
objects.
The
objectList
production
matches
a
series
of
objects
separated
by
,
following
a
predicate.
This
expresses
a
series
of
RDF
Triples
with
the
same
subject
and
predicate
and
each
object
allocated
to
one
triple.
Thus,
the
,
is
used
to
repeat
the
subject
and
predicate
of
triples
that
only
differ
in
the
object
RDF
term
.
These
two
examples
are
equivalent
ways
of
writing
Spiderman's
name
in
two
languages.
The
Turtle
language
has
evolved
since
its
origin,
and
RDF
1.2
adds
new
syntax.
RDF
1.2
Turtle
introduces
the
VERSION
and
@version
directives
along
with
an
optional
version
Media
Type
parameter
.
When
serializing
Turtle
with
new
features
such
as
initial
text
direction
or
triple
terms
,
authors
can
announce
the
use
of
the
new
syntax
forms
using
these
directives.
GET /document.ttl HTTP/1.1
Host: example.com
Accept: text/turtle; version=1.2
Note
When
using
RDF
1.2-specific
features,
such
as
initial
text
direction
,
the
specific
RDF
version
should
be
announced
using
either
VERSION
or
@version
directives
early
in
the
document.
This
allows
parsers
that
do
not
support
these
features
to
detect
the
presense
of
such
features
early,
and
potentially
inform
the
user,
giving
them
an
opportunity
to
stop
the
job
or
otherwise
act
on
the
fact
that
some
amount
of
the
input
data
will
not
be
processed
as
desired.
Note
Version
numbers
other
than
"1.2"
are
not
defined
by
this
specification.
Processors
may
treat
this
as
an
error
or
warning.
Relative
IRI
references
like
<#green-goblin>
are
resolved
relative
to
the
current
base
IRI.
A
new
base
IRI
can
be
defined
using
the
@base
or
BASE
directive.
Specifics
of
this
operation
are
defined
in
6.3
IRI
References
.
The
token
a
in
the
predicate
position
of
a
Turtle
triple
represents
the
IRI
http://www.w3.org/1999/02/22-rdf-syntax-ns#type
.
A
prefixed
name
is
a
prefix
label
and
a
local
part,
separated
by
a
:
.
A
prefixed
name
is
turned
into
an
IRI
by
concatenating
the
IRI
associated
with
the
prefix
and
the
local
part.
The
@prefix
or
PREFIX
directive
associates
a
prefix
label
with
an
IRI.
Subsequent
@prefix
or
PREFIX
directives
may
re-map
the
same
prefix
label.
Note
The
Turtle
language
originally
permitted
only
the
syntax
including
the
@
character
for
writing
prefix
and
base
directives.
The
case-insensitive
PREFIX
,
BASE
,
and
VERSION
forms
were
added
to
align
Turtle's
syntax
with
that
of
SPARQL
.
The
original
directives
@prefix
,
@base
,
or
@version
may
also
be
used.
Using
PREFIX
,
BASE
,
and
VERSION
may
make
it
easier
to
copy
declarations
to
SPARQL
queries.
To
write
http://www.perceive.net/schemas/relationship/enemyOf
using
a
prefixed
name:
Define
a
prefix
label
for
the
vocabulary
IRI
http://www.perceive.net/schemas/relationship/
as
somePrefix
Then
write
somePrefix:enemyOf
which
is
equivalent
to
writing
<http://www.perceive.net/schemas/relationship/enemyOf>
This
can
be
written
using
either
the
SPARQL
-style
syntax
for
prefix
declarations:
Example
10
:
SPARQL
syntax
for
prefix
declarations
# A triple with all resolved IRIs
<http://one.example/subject1> <http://one.example/predicate1> <http://one.example/object1> .
@base <http://one.example/> .
<subject2> <predicate2> <object2> . # relative IRI references, e.g., http://one.example/subject2
BASE <http://one.example/>
<subject2> <predicate2> <object2> . # relative IRI references, e.g., http://one.example/subject2
@prefix p: <http://two.example/> .
p:subject3 p:predicate3 p:object3 . # prefixed name, e.g., http://two.example/subject3
PREFIX p: <http://two.example/>
p:subject3 p:predicate3 p:object3 . # prefixed name, e.g., http://two.example/subject3
@prefix p: <path/> . # prefix p: now stands for http://one.example/path/
p:subject4 p:predicate4 p:object4 . # prefixed name, e.g., http://one.example/path/subject4
PrEfIx : <http://another.example/> # empty prefix
:subject5 :predicate5 :object5 . # prefixed name, e.g., http://another.example/subject5
:subject6 a :subject7 . # same as :subject6 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> :subject7 .
<http://伝言.example/?user=أ&channel=R%26D> a :subject8 . # a multi-script subject IRI .
Note
While
the
@prefix
and
@base
directives
require
a
trailing
.
after
the
IRI,
the
equivalent
PREFIX
and
BASE
do
not
have
a
trailing
.
after
the
IRI
part
of
the
directive.
The
PREFIX
and
BASE
are
case-insensitive
and
can
be
written
as
prefix
and
base
or
as
any
blend
of
mixed
case.
2.6
RDF
Literals
Literals
are
used
to
identify
values
such
as
strings,
numbers,
dates.
The
representation
of
the
lexical
form
consists
of
an
initial
delimiter
(e.g.,
"
,
'
,
"""
,
or
'''
);
a
sequence
of
permitted
characters,
numeric
escape
sequences
,
and/or
string
escape
sequences
;
and
a
final
delimiter
matching
the
initial
delimiter.
The
corresponding
RDF
lexical
form
is
the
characters
between
the
delimiters,
after
processing
any
escape
sequences.
VERSION "1.2"
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX show: <http://example.org/vocab/show/>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
show:218 rdfs:label "That Seventies Show"^^xsd:string . # literal with XML Schema string datatype
show:218 rdfs:label "That Seventies Show"^^<http://www.w3.org/2001/XMLSchema#string> . # same as above
show:218 rdfs:label "That Seventies Show" . # same again
show:218 show:localName "That Seventies Show"@en . # literal with a language tag
show:218 show:localName "HTML היא שפת סימון."@he--rtl . # literal with a language tag and initial text direction
show:218 show:localName "That Seventies Show"@en-us--ltr . # literal with a language tag, region subtag, and initial text direction
show:218 show:localName 'Cette Série des Années Soixante-dix'@fr . # literal delimited by single quote
show:218 show:localName "Cette Série des Années Septante"@fr-be . # literal with a region subtag
show:218 show:blurb '''This is a multi-line
literal with many quotes (""""")
and up to two sequential apostrophes ('').''' . # literal with embedded new lines and quotes
2.6.2
Numbers
Numbers
can
be
written
like
other
literals
with
lexical
form
and
datatype
(e.g.,
"-5.0"^^xsd:decimal
).
Turtle
has
a
shorthand
syntax
for
writing
integer
values,
arbitrary
precision
decimal
values,
and
double
precision
floating
point
values.
Data
Type
Abbreviated
Lexical
Description
xsd:integer
-5
"-5"^^xsd:integer
Integer
values
may
be
written
as
an
optional
sign
and
a
series
of
digits.
Integers
match
the
regular
expression
"
[+-]?[0-9]+
".
xsd:decimal
-5.0
"-5.0"^^xsd:decimal
Arbitrary-precision
decimals
may
be
written
as
an
optional
sign,
zero
or
more
digits,
a
decimal
point,
and
one
or
more
digits.
Decimals
match
the
regular
expression
"
[+-]?[0-9]*\.[0-9]+
".
xsd:double
4.2E9
"4.2E9"^^xsd:double
Double-precision
floating
point
values
may
be
written
as
an
optionally
signed
mantissa
with
an
optional
decimal
point,
the
letter
e
or
the
letter
E
,
and
an
optionally
signed
integer
exponent.
The
exponent
matches
the
regular
expression
"
[+-]?[0-9]+
"
and
the
mantissa
matches
one
of
these
regular
expressions:
"
[+-]?[0-9]+\.[0-9]+
",
"
[+-]?\.[0-9]+
",
or
"
[+-]?[0-9]
".
2.8
Nesting
of
Blank
Nodes
without
Blank
Node
Identifiers
In
Turtle,
fresh
RDF
blank
nodes
are
also
allocated
when
matching
the
production
blankNodePropertyList
and
the
terminal
ANON
.
Both
of
these
may
appear
in
the
subject
or
object
position
of
a
triple
(see
the
Turtle
Grammar).
That
subject
or
object
is
a
fresh
RDF
blank
node
.
This
blank
node
also
serves
as
the
subject
of
the
triples
produced
by
matching
the
predicateObjectList
production
embedded
in
a
blankNodePropertyList
.
The
generation
of
these
triples
is
described
in
Predicate
Lists
.
Blank
nodes
are
also
allocated
for
collections
described
below.
RDF
provides
a
Collection
[
RDF12-SEMANTICS
]
structure
for
lists
of
RDF
nodes.
The
Turtle
syntax
for
Collections
is
a
possibly
empty
list
of
RDF
terms
enclosed
by
(
)
.
This
collection
represents
an
rdf:first
/
rdf:rest
list
structure
with
the
sequence
of
objects
of
the
rdf:first
statements
being
the
order
of
the
terms
enclosed
by
(
)
.
The
(…)
syntax
MUST
appear
in
the
subject
or
object
position
of
a
triple
(see
the
Turtle
Grammar).
The
blank
node
at
the
head
of
the
list
is
the
subject
or
object
of
the
containing
triple.
PREFIX : <http://example.org/foo/>
# the object of this triple is the RDF collection blank node
:subject :predicate ( :a :b :c ) .
# an empty collection value - rdf:nil
:subject :predicate2 () .
A
reifiedTriple
is
syntactic
sugar
representing
a
reifying
triple
,
which
defines
a
specific
relationship
between
an
identifier
(
reifier
)
and
a
triple
term
.
The
identifier
becomes
a
way
to
indirectly
refer
to
a
triple
term
,
which
may
or
may
not
be
asserted
within
the
graph
corresponding
to
this
input
document.
Note
Reification
in
RDF
1.2
is
a
concept
distinct
from
the
Reification
vocabulary
originally
defined
in
RDF
Semantics
.
While
both
terms
describe
a
representation
of
an
RDF
triple
using
components,
RDF
1.2
uses
the
term
to
identify
a
triple
term
using
the
rdf:reifies
predicate.
Note
the
difference
in
syntax
between
the
syntactic
sugar
of
reifiedTriple
(i.e.,
<<
[...]
>>
)
and
the
regular
tripleTerm
(i.e.,
<<(
[...]
)>>
).
After
declaring
a
prefix
so
that
IRIs
can
be
abbreviated,
the
first
triple
in
this
example
asserts
that
employee38
has
a
familyName
of
"Smith".
Note
that
this
graph
does
not
assert
that
employee38
has
a
jobTitle
of
"Assistant
Designer";
it
says
that
employee22
has
made
that
claim
using
a
reifiedTriple
.
In
other
words,
the
triple
"
employee38
has
a
jobTitle
of
'Assistant
Designer'"
is
not
a
member
of
the
graph,
itself,
as
"employee38
has
a
familyName
of
'Smith'"
is
above;
rather,
it
is
known
as
a
reifying
triple
.
Turtle
also
defines
an
annotation
syntax
to
both
reify
and
assert
a
triple
,
which
provides
a
convenient
shortcut.
An
annotation
can
be
used
to
simultaneously
assert
a
triple,
via
an
explicit
or
implicit
identifier,
and
have
that
triple
be
the
subject
or
object
of
further
triples.
If
explicitly
identified,
the
same
reifier
can
then
be
used
as
the
subject
or
object
of
additional
triples
and/or
triple
terms
.
As
with
a
reifiedTriple
,
the
annotation
syntax
allows
the
definition
of
one
or
more
reifiers
as
either
IRIs
or
blank
nodes
,
each
preceded
by
a
tilde
(
~
),
which
precedes
the
annotation
block.
If
not
followed
by
an
annotation
block,
a
reifier
is
treated
like
a
reifiedTriple
without
annotations.
If
an
annotation
block
is
not
immediately
preceded
by
a
reifier
,
an
RDF
blank
node
is
allocated
to
serve
as
the
reifier
of
the
triple
term
.
Note
The
annotation
syntax
is
a
syntactic
shortcut
in
Turtle,
and
the
RDF
Abstract
Syntax
[
RDF11-CONCEPTS
]
does
not
distinguish
how
the
triples
were
written.
An
example
of
two
identical
triples
containing
literal
objects
containing
newlines,
written
in
plain
and
long
literal
forms.
The
line
breaks
in
this
example
are
LF
.
(
example3.ttl
):
PREFIX :<http://example.org/stuff/1.0/>:a:b"The first line\nThe second line\n more".:a:b"""The first line
The second line
more"
""
.
As
indicated
by
the
grammar,
a
collection
can
be
either
a
subject
or
an
object
.
This
subject
or
object
will
be
the
novel
blank
node
for
the
first
object,
if
the
collection
has
one
or
more
objects,
or
rdf:nil
if
the
collection
is
empty.
SPARQL
uses
case
insensitive
keywords,
except
for
a
.
Turtle's
@prefix
and
@base
declarations
are
case
sensitive,
the
SPARQL
derived
PREFIX
and
BASE
are
case
insensitive.
true
and
false
are
case
insensitive
in
SPARQL
and
case
sensitive
in
Turtle.
TrUe
is
not
a
valid
boolean
value
in
Turtle.
As
well
as
sections
marked
as
non-normative,
all
authoring
guidelines,
diagrams,
examples,
and
notes
in
this
specification
are
non-normative.
Everything
else
in
this
specification
is
normative.
The
key
words
MAY
,
MUST
,
MUST
NOT
,
and
SHOULD
in
this
document
are
to
be
interpreted
as
described
in
BCP
14
[
RFC2119
]
[
RFC8174
]
when,
and
only
when,
they
appear
in
all
capitals,
as
shown
here.
This
specification
defines
conformance
criteria
for:
A
conforming
Turtle
parser
is
a
system
capable
of
reading
Turtle
documents
on
behalf
of
an
application.
It
makes
the
serialized
RDF
graph,
as
defined
in
7.
Parsing
,
available
to
the
application,
usually
through
some
form
of
API.
The
IRI
that
identifies
the
Turtle
language
is:
http://www.w3.org/ns/formats/Turtle
Note
This
specification
does
not
define
how
Turtle
parsers
handle
non-conforming
input
documents.
5.1
Media
Type
and
Content
Encoding
The
media
type
of
Turtle
is
text/turtle
.
The
content
encoding
of
Turtle
content
is
always
UTF-8
[
RFC3629
].
Charset
parameters
on
the
media
type
are
required
until
such
time
as
the
text/
media
type
tree
permits
UTF-8
to
be
sent
without
a
charset
parameter.
See
D.
Internet
Media
Type,
File
Extension
and
Macintosh
File
Type
for
the
media
type
registration
form.
White
space
(production
WS
)
is
used
to
separate
two
terminals
which
would
otherwise
be
(mis-)recognized
as
one
terminal.
Rule
names
below
in
capitals
indicate
where
white
space
is
significant;
these
form
a
possible
choice
of
terminals
for
constructing
a
Turtle
parser.
White
space
is
significant
in
the
production
String
.
A
Unicode
code
point
in
the
ranges
U+0000
to
U+D7FF
and
U+E000
to
U+D7FF
,
corresponding
to
the
value
encoded
by
the
four
hexadecimal
digits
interpreted
from
most
significant
to
least
significant
digit.
A
Unicode
code
point
in
the
ranges
U+0000
to
U+D7FF
and
U+E000
to
U+10FFFF
,
corresponding
to
the
value
encoded
by
the
eight
hexadecimal
digits
interpreted
from
most
significant
to
least
significant
digit.
A
string
escape
sequence
represents
a
character
traditionally
escaped
in
string
literals:
Escape
sequence
Unicode
code
point
\t
U+0009
\b
U+0008
\n
U+000A
\r
U+000D
\f
U+000C
\"
U+0022
\'
U+0027
\\
U+005C
A
reserved
character
escape
sequence
consists
of
a
\
followed
by
one
of
these
characters
~.-!$&'()*+,;=/?#@%_
,
and
represents
the
character
to
the
right
of
the
\
.
Context
where
each
kind
of
escape
sequence
can
be
used
%-encoded
sequences
are
in
the
character
range
for
IRIs
and
are
explicitly
allowed
in
local
names.
These
appear
as
a
%
followed
by
two
hex
characters
and
represent
that
same
sequence
of
three
characters.
These
sequences
are
not
decoded
during
processing.
A
term
written
as
<http://a.example/%66oo-bar>
in
Turtle
designates
the
IRI
http://a.example/%66oo-bar
and
not
IRI
http://a.example/foo-bar
.
A
term
written
as
ex:%66oo-bar
with
a
prefix
PREFIX
ex:
<http://a.example/>
also
designates
the
IRI
http://a.example/%66oo-bar
.
Keywords
in
single
quotes
('
@base
',
'
@prefix
',
'
@version
',
'
a
',
'
true
',
and
'
false
')
are
case-sensitive.
Keywords
in
quotation
marks
("
BASE
",
"
PREFIX
"),
and
"
VERSION
")
are
case-insensitive.
When
tokenizing
the
input
and
choosing
grammar
rules,
the
longest
match
is
chosen.
The
Turtle
grammar
is
LL(1)
and
LALR(1)
when
the
rules
with
uppercased
names
are
used
as
terminals.
The
entry
point
into
the
grammar
is
turtleDoc
.
In
signed
numbers,
no
white
space
is
allowed
between
the
sign
and
the
number.
The
strings
'
@prefix
',
'
@base
',
and
'
@version
'
match
the
pattern
for
LANG_DIR
,
though
neither
prefix
,
base
,
nor
version
are
registered
language
subtags
.
This
specification
does
not
define
whether
a
quoted
literal
followed
by
either
of
these
tokens
(e.g.,
"A"@base
)
is
in
the
Turtle
language.
A
text
version
of
this
grammar
is
available
here
.
6.6
Selected
Terminal
Literal
Strings
This
document
uses
some
specific
terminal
literal
strings
[
EBNF-NOTATION
].
To
clarify
the
Unicode
code
points
used
for
these
terminal
literal
strings,
the
following
table
describes
specific
characters
and
sequences
used
throughout
this
document.
Code
Glyph
Description
U+0009
HT
Horizontal
tab
U+000A
LF
Line
feed
U+000D
CR
Carriage
return
U+0022
"
Quotation
mark
U+0023
#
Number
sign
U+0025
%
Percent
sign
U+0027
'
Apostrophe
U+0028
(
Left
parenthesis
U+0029
)
Right
parenthesis
U+002C
,
Comma
U+002D
-
Hyphen
U+002E
.
Full
stop
U+0030
0
Digit
zero
U+0039
9
Digit
nine
U+003B
:
Colon
U+003B
;
Semicolon
U+003C
<
Less-than
sign
U+003E
>
Greater-than
sign
U+0040
@
At
sign
U+0045
E
Latin
capital
letter
E
U+005B
[
Left
square
bracket
U+005C
\
Backslash
U+005D
[
Right
square
bracket
U+005F
_
Underscore
U+0061
a
Latin
small
letter
A
U+0065
e
Latin
small
letter
E
U+007C
|
vertical
line
U+007E
~
Tilde
U+00B7
·
Middle
dot
U+203F
‿
Undertie
U+2040
⁀
Character
tie
Other
short
terminal
literal
strings
are
composed
of
specific
sequences
of
Unicode
characters:
space
U+0020
"""
three
concatenated
quotation
mark
characters,
each
having
the
code
point
U+0022
'''
three
concatenated
apostrophes
characters,
each
having
the
code
point
U+0027
<<
two
concatenated
less-than
sign
characters,
each
having
the
code
point
U+003C
>>
two
concatenated
greater-than
sign
characters,
each
having
the
code
point
U+003E
<<(
two
concatenated
less-than
sign
characters,
each
having
the
code
point
U+003C
,
followed
by
a
left
parenthesis
character,
having
the
code
point
U+0028
)>>
a
left
parenthesis
character,
having
the
code
point
U+0029
followed
by
two
concatenated
greater-than
sign
characters,
each
having
the
code
point
U+003E
^^
two
concatenated
circumflex
accent
characters,
each
having
the
code
point
U+005E
{|
{
(left
curly
bracket,
code
point
U+007B
)
followed
by
|
(vertical
line,
code
point
U+007C
)
|}
|
(vertical
line,
code
point
U+007C
)
followed
by
}
(right
curly
bracket,
code
point
U+007D
)
The
RDF
1.2
Concepts
and
Abstract
Syntax
specification
[
RDF12-CONCEPTS
]
defines
four
types
of
RDF
terms
:
IRIs
,
literals
,
blank
nodes
,
and
triple
terms
.
Literals
are
composed
of
a
lexical
form
and
an
optional
language
tag
[
BCP47
]
–
possibly
including
an
initial
text
direction
–
or
datatype
IRI
.
An
extra
type,
prefix
,
is
used
during
parsing
to
map
string
identifiers
to
namespace
IRIs.
This
section
maps
a
string
conforming
to
the
grammar
in
6.5
Grammar
to
a
set
of
triples
by
mapping
strings
matching
productions
and
lexical
tokens
to
RDF
terms
or
their
components
(e.g.,
language
tags,
lexical
forms
of
literals).
Grammar
productions
change
the
parser
state
and
emit
triples.
7.1
Parser
State
Parsing
Turtle
requires
a
state
of
nine
items:
IRI
baseURI
—
When
the
base
production
is
reached,
the
second
rule
argument,
IRIREF
,
is
the
base
URI
used
for
relative
IRI
resolution.
RDF
Term
curPredicate
—
The
curPredicate
is
bound
to
the
verb
production.
If
token
matched
was
a
,
curPredicate
is
bound
to
the
IRI
http://www.w3.org/1999/02/22-rdf-syntax-ns#type
.
xsd:string
curVersion
–
The
RDF
version
used
for
parsing
the
document
into
Triples
.
If
specified
as
part
of
a
Media
Type
,
the
default
value
for
curVersion
is
taken
from
the
version
parameter.
Acceptable
values
for
version
are
defined
in
2.1
Version
Lables
in
[
RDF12-CONCEPTS
].
The
version
announcement
is
only
a
hint;
this
specification
does
not
mandate
any
parser
behavior
based
on
curVersion
,
but
a
parser
MAY
signal
an
error
or
a
warning
when
it
encounters
a
feature
that
does
not
match
the
value
of
curVersion
.
Term
Constructors
can
create
a
stack
of
these
values
indicated
by
using
language
such
as
"records
the
curSubject
and
curPredicate
."
When
used
in
a
prefixID
or
sparqlPrefix
production,
the
prefix
is
the
potentially
empty
RDF
string
matching
the
first
argument
of
the
rule
is
a
key
into
the
namespaces
map
into
which
the
expanded
second
argument
is
stored
for
future
lookup.
When
used
in
a
PrefixedName
production;
the
namespaces
map
MUST
have
a
corresponding
namespace
,
which
forms
the
RDF
string
of
the
IRI.
The
resulting
IRI
MUST
comply
with
the
syntactic
restrictions
of
generic
IRI
syntax,
and
SHOULD
comply
with
any
narrower
restrictions
imposed
by
the
corresponding
IRI
scheme
specification.
A
potentially
empty
prefix
is
identified
by
the
first
sequence,
PNAME_NS
.
The
namespaces
map
MUST
have
a
corresponding
namespace
.
The
RDF
string
of
the
IRI
is
formed
by
unescaping
the
reserved
characters
in
the
second
argument,
PN_LOCAL
,
and
concatenating
this
onto
the
namespace
.
The
resulting
IRI
MUST
comply
with
the
syntactic
restrictions
of
generic
IRI
syntax,
and
SHOULD
comply
with
any
narrower
restrictions
imposed
by
the
corresponding
IRI
scheme
specification.
The
characters
between
the
outermost
'
s
are
taken,
after
numeric
and
string
escape
sequences
are
replaced
with
the
characters
that
they
represent,
to
form
the
RDF
string
of
a
lexical
form.
The
characters
between
the
outermost
"""
s
are
taken,
after
numeric
and
string
escape
sequences
are
are
replaced
with
the
characters
that
they
represent,
to
form
the
RDF
string
of
a
lexical
form.
The
literal
has
a
lexical
form
of
the
first
rule
argument,
String
.
If
the
'^^'
iri
rule
is
matched,
the
datatype
IRI
is
derived
from
the
iri
,
and
the
literal
has
no
language
tag.
If
the
LANG_DIR
rule
is
matched,
the
language
tag
and
initial
text
direction
are
taken
from
LANG_DIR
.
If
there
is
no
initial
text
direction
,
the
datatype
is
rdf:langString
.
If
there
is
a
initial
text
direction
,
the
datatype
is
rdf:dirLangString
.
If
neither
matched,
the
datatype
is
xsd:string
,
and
the
literal
has
no
language
tag.
The
curReifier
is
taken
from
term
,
which
is
taken
from
the
matched
iri
production
or
BlankNode
production,
if
any.
If
no
such
production
is
matched,
term
is
taken
from
a
fresh
RDF
blank
node
.
As
processors
which
detect
errors
on
input
can
result
in
graphs
which
contain
fewer
triples
than
are
described
in
the
input
(including
no
triples
whatsoever),
consumers
should
consider
information
of
any
errors
signaled
when
using
the
output
triples,
which
may
be
incomplete
and/or
include
ill-typed
or
ill-formed
terms.
Beginning
the
reifier
production,
the
curReifier
is
taken
from
the
reifier
term
constructor.
Then
yield
the
RDF
triple
curReifier
rdf:reifies
curTripleTerm
.
7.3.2
Reified
Triples
Beginning
the
reifiedTriple
production
records
the
curTripleTerm
.
A
new
tripleTerm
instance
curTripleTerm
is
created
using
the
rtSubject
,
verb
,
and
rtObject
productions.
Finishing
the
reifiedTriple
production,
if
the
curReifier
is
not
set,
it
is
assigned
a
fresh
RDF
blank
node
;
it
next
yields
the
RDF
triple
curReifier
rdf:reifies
curTripleTerm
,
and
then
restores
the
recorded
value
of
the
curTripleTerm
.
The
node
produced
by
matching
reifiedTriple
is
the
the
curReifier
.
7.3.3
Annotations
Beginning
the
annotation
production
records
the
curSubject
and
curPredicate
.
A
new
tripleTerm
instance
curTripleTerm
is
created
using
the
curSubject
curPredicate
curObject
,
and
the
value
of
the
curReifier
is
cleared.
Finishing
the
annotation
production
restores
the
recorded
values
of
the
curSubject
and
curPredicate
.
7.3.4
Annotation
Blocks
Beginning
the
annotationBlock
production
records
the
curTripleTerm
.
If
the
curReifier
is
not
set,
then
it
is
assigned
a
fresh
RDF
blank
node
and
the
production
yields
the
RDF
triple
curReifier
rdf:reifies
curTripleTerm
.
The
curSubject
is
taken
from
the
curReifier
Finishing
the
annotationBlock
production
clears
the
value
of
the
curReifier
and
restores
the
curTripleTerm
.
Note
If
the
curReifier
was
already
set,
the
reifying
triple
curReifier
rdf:reifies
curTripleTerm
was
emitted
in
7.3.1
Reifiers
.
Beginning
the
collection
production
records
the
curSubject
and
curPredicate
.
Each
object
in
the
collection
production
has
curSubject
set
to
a
novel
blank
node
B
and
curPredicate
set
to
rdf:first
.
For
each
object
object
n
after
the
first
produces
a
triple:
object
n-1
rdf:rest
object
n
.
Finishing
the
collection
production
creates
an
additional
triple
curSubject
rdf:rest
rdf:nil
.
and
restores
the
curSubject
and
curPredicate
The
node
produced
by
matching
collection
is
the
first
blank
node
B
for
non-empty
lists
and
rdf:nil
for
empty
lists.
7.4
Parsing
Example
This
section
is
non-normative.
The
following
informative
example
shows
the
semantic
actions
performed
when
parsing
this
Turtle
document
with
an
LALR(1)
parser:
<scripttype="text/turtle">
PREFIX dc: <http://purl.org/dc/terms/>
PREFIX frbr: <http://purl.org/vocab/frbr/core#>
<http://books.example.com/works/45U8QJGZSQKDH8N> a frbr:Work ;
dc:creator "Wil Wheaton"@en ;
dc:title "Just a Geek"@en ;
frbr:realization <http://books.example.com/products/9780596007683.BOOK>,
<http://books.example.com/products/9780596802189.EBOOK> .
<http://books.example.com/products/9780596007683.BOOK> a frbr:Expression ;
dc:type <http://books.example.com/product-types/BOOK> .
<http://books.example.com/products/9780596802189.EBOOK> a frbr:Expression ;
dc:type <http://books.example.com/product-types/EBOOK> .
</script>
Turtle
content
should
be
placed
in
a
script
tag
with
the
type
attribute
set
to
text/turtle
.
<
and
>
symbols
do
not
need
to
be
escaped
inside
of
script
tags.
The
character
encoding
of
the
embedded
Turtle
will
match
the
HTML
documents
encoding.
A.1
XHTML
This
section
is
non-normative.
Like
JavaScript,
Turtle
authored
for
HTML
(
text/html
)
can
break
when
used
in
XHTML
(
application/xhtml+xml
).
The
solution
is
the
same
one
used
for
JavaScript.
When
embedded
in
XHTML
Turtle
data
blocks
must
be
enclosed
in
CDATA
sections.
Those
CDATA
markers
must
be
in
Turtle
comments.
If
the
character
sequence
]]>
occurs
in
the
document
it
must
be
escaped
using
strings
escapes
(
\u005d\u0054\u003e
).
This
will
also
make
Turtle
safe
in
polyglot
documents
served
as
both
text/html
and
application/xhtml+xml
.
Failing
to
use
CDATA
sections
or
escape
]]>
may
result
in
a
non
well-formed
XML
document.
A.2
Parsing
Turtle
in
HTML
This
section
is
non-normative.
There
are
no
syntactic
or
grammar
differences
between
parsing
Turtle
that
has
been
embedded
and
normal
Turtle
documents.
A
Turtle
document
parsed
from
an
HTML
DOM
will
be
a
stream
of
character
data
rather
than
a
stream
of
UTF-8
[
RFC3629
]
code
points.
No
decoding
is
necessary
if
the
HTML
document
has
already
been
parsed
into
DOM.
Each
script
data
block
is
considered
to
be
its
own
Turtle
document.
PREFIX
and
BASE
declarations
in
a
Turtle
data
block
are
scoped
to
that
data
block
and
do
not
effect
other
data
blocks.
The
HTML
lang
attribute
or
XHTML
xml:lang
attribute
have
no
effect
on
the
parsing
of
the
data
blocks.
The
base
URI
of
the
encapsulating
HTML
document
provides
a
"Base
URI
Embedded
in
Content"
per
RFC3986
section
5.1.1.
B.
Privacy
Considerations
This
section
is
non-normative.
The
Turtle
format
is
used
to
express
arbitrary
application
data,
which
may
include
the
expression
of
personally
identifiable
information
(PII)
or
other
information
which
could
be
considered
sensitive.
Authors
publishing
such
information
are
advised
to
carefully
consider
the
needs
and
use
of
publishing
such
information,
as
well
as
the
applicable
regulations
for
the
regions
where
the
data
is
expected
to
be
consumed
and
potentially
revealed
(e.g.,
GDPR
,
CCPA
,
others
),
particularly
whether
authorization
measures
are
needed
for
access
to
the
data.
Turtle
is
a
general-purpose
assertion
language;
applications
may
evaluate
given
data
to
infer
more
assertions
or
to
dereference
IRIs
,
invoking
the
security
considerations
of
the
scheme
for
that
IRI.
Note
in
particular,
the
privacy
issues
in
[
RFC3023
]
section
10
for
HTTP
IRIs.
Data
obtained
from
an
inaccurate
or
malicious
data
source
may
lead
to
inaccurate
or
misleading
conclusions,
as
well
as
the
dereferencing
of
unintended
IRIs.
Care
must
be
taken
to
align
the
trust
in
consulted
resources
with
the
sensitivity
of
the
intended
use
of
the
data;
inferences
of
potential
medical
treatments
would
likely
require
different
trust
than
inferences
for
trip
planning.
The
Turtle
language
is
used
to
express
arbitrary
application
data;
security
considerations
will
vary
by
domain
of
use.
Security
tools
and
protocols
applicable
to
text
(for
example,
PGP
encryption,
checksum
validation,
password-protected
compression)
may
also
be
used
on
Turtle
documents
.
Security/privacy
protocols
must
be
imposed
which
reflect
the
sensitivity
of
the
embedded
information.
Turtle
can
express
data
which
is
presented
to
the
user,
such
as
RDF
Schema
labels.
Applications
rendering
strings
retrieved
from
untrusted
Turtle
documents
,
or
using
unescaped
characters,
SHOULD
use
warnings
and
other
appropriate
means
to
limit
the
possibility
that
malignant
strings
might
be
used
to
mislead
the
reader.
The
security
considerations
in
the
media
type
registration
for
XML
([
RFC3023
]
section
10)
provide
additional
guidance
around
the
expression
of
arbitrary
data
and
markup.
Multiple
IRIs
may
have
the
same
appearance.
Characters
in
different
scripts
may
look
similar
(for
instance,
a
Cyrillic
"о"
(code
point
U+043E
)
may
appear
similar
to
a
Latin
"o"
(code
point
U+006F
)).
A
character
followed
by
combining
characters
may
have
the
same
visual
representation
as
another
character
(for
example,
LATIN
SMALL
LETTER
"E"
(code
point
U+0065
)
followed
by
COMBINING
ACUTE
ACCENT
(code
point
U+0301
)
has
the
same
visual
representation
as
LATIN
SMALL
LETTER
"E"
WITH
ACUTE
(
U+00E9
)).
Any
person
or
application
that
is
writing
or
interpreting
data
in
Turtle
must
take
care
to
use
the
IRI
that
matches
the
intended
semantics,
and
avoid
IRIs
that
may
look
similar.
Further
information
about
matching
visually
similar
characters
can
be
found
in
Unicode
Security
Considerations
[
UNICODE-SECURITY
]
and
Internationalized
Resource
Identifiers
(IRIs)
[
RFC3987
]
Section
8.
D.
Internet
Media
Type,
File
Extension
and
Macintosh
File
Type
The
Internet
Media
Type
(formerly
known
as
MIME
Type)
for
Turtle
is
"text/turtle".
The
information
that
follows
has
been
submitted
to
the
Internet
Engineering
Steering
Group
(IESG)
for
review,
approval,
and
registration
with
IANA.
Type
name:
text
Subtype
name:
turtle
Required
parameters:
None
Optional
parameters:
charset
—
this
parameter
is
required
when
transferring
non-ASCII
data.
If
present,
the
value
of
charset
is
always
UTF-8
.
version
—
this
parameter
is
optional
but
SHOULD
be
present
when
using
RDF
1.2-specific
features.
If
present,
acceptable
values
of
version
are
defined
in
2.1
Version
Lables
in
[
RDF12-CONCEPTS
].
Encoding
considerations:
The
syntax
of
Turtle
is
expressed
over
code
points
in
Unicode
[
UNICODE
].
The
encoding
is
always
UTF-8
[
UTF-8
].
Unicode
code
points
may
also
be
expressed
using
\uXXXX
(
U+0000
to
U+FFFF
)
or
\UXXXXXXXX
syntax
(for
code
points
up
to
U+10FFFF
)
where
X
is
a
hexadecimal
digit
[0-9A-Fa-f]
Turtle
is
used
widely
for
representing
RDF
data.
There
are
implementations
available
in
most
common
programming
languages.
Additional
information:
Magic
number(s):
Turtle
documents
may
have
the
strings
'@prefix'
or
'@base'
(case
sensitive)
or
the
strings
'PREFIX'
or
'BASE'
(case
insensitive)
near
the
beginning
of
the
document.
File
extension(s):
.ttl
Macintosh
file
type
code(s):
TEXT
Base
URI:
The
Turtle
'@base
<IRIref>'
or
'BASE
<IRIref>'
term
can
change
the
current
base
URI
for
relative
IRI
references
in
the
query
language
that
are
used
sequentially
later
in
the
document.
Person
&
email
address
to
contact
for
further
information:
RDF
&
SPARQL
Working
Group
<public-rdf-star-wg@w3.org>
Intended
usage:
Common
Restrictions
on
usage:
None
Author(s):
The
Turtle
specification
is
the
product
of
the
RDF
&
SPARQL
WG.
The
W3C
reserves
change
control
over
this
specifications.
E.
Acknowledgments
E.1
Acknowledgments
for
RDF
1.1
This
section
is
non-normative.
This
work
was
described
in
the
paper
New
Syntaxes
for
RDF
which
discusses
other
RDF
syntaxes
and
the
background
to
the
Turtle
(Submitted
to
WWW2004,
referred
to
as
N-Triples
Plus
there).
Valuable
contributions
to
this
version
were
made
by
Gregg
Kellogg,
Andy
Seaborne,
Sandro
Hawke
and
the
members
of
the
RDF
Working
Group.
The
document
was
improved
through
the
review
process
by
the
wider
community.
E.2
Acknowledgments
for
RDF
1.2
This
section
is
non-normative.
In
addition
to
the
editors,
the
following
people
have
contributed
to
this
specification:
Andrew
Louis,
Andy
Seaborne,
Denis
Ah-Kang,
Mirek
Kratochvil,
Peter
F.
Patel-Schneider,
Pierre-Antoine
Champin,
Ted
Thibodeau
Jr,
and
William
Van
Woensel
Members
of
the
RDF
&
SPARQL
Working
Group
Group
included
Vladimir
Alexiev,
James
Anderson,
Amin
Anjomshoaa,
Julián
Arenas-Guerrero,
Dörthe
Arndt,
Bilal
Ben
Mahria,
Erich
Bremer,
Dan
Brickley,
Kurt
Cagle,
Sarven
Capadisli,
Rémi
Ceres,
Pierre-Antoine
Champin,
David
Chaves-Fraga,
Souripriya
Das,
Daniil
Dobriy,
Enrico
Franconi,
Jeffrey
Phillips
Freeman,
Fabien
Gandon,
Benjamin
Goering,
Damien
Graux,
Adrian
Gschwend,
Olaf
Hartig,
Timothée
Haudebourg,
Ian
Horrocks,
Gregg
Kellogg,
Mark
Kim,
Jose
Emilio
Labra
Gayo,
Ora
Lassila,
Richard
Lea,
Niklas
Lindström,
Pasquale
Lisena,
Thomas
Lörtsch,
Matthew
Nguyen,
Peter
Patel-Schneider,
Thomas
Pellissier
Tanon,
Dave
Raggett,
Jean-Yves
ROSSI,
Felix
Sasaki,
Andy
Seaborne,
Alan
Snyder,
Stuart
Sutton,
Ruben
Taelman,
Ted
Thibodeau
Jr,
Dominik
Tomaszuk,
Raphaël
Troncy,
William
Van
Woensel,
Gregory
Williams,
Jesse
Wright,
Achille
Zappa,
and
Antoine
Zimmermann.
Editor's
note
Recognize
members
of
the
Task
Force?
Not
an
easy
to
find
list
of
contributors.
F.
Changes
between
RDF
1.1
and
RDF
1.2
This
section
is
non-normative.
Update
informative
restrictions
on
included
characters
for
STRING_LITERAL_QUOTE
and
STRING_LITERAL_SINGLE_QUOTE
.
Clarify
that
Unicode
surrogates
are
not
legal
in
Turtle
documents,
nor
as
the
value
of
a
Unicode
escape
sequence.
Added
2.4
Version
Announcement
and
parser
state
and
productions
to
announce
the
RDF
version
associated
with
the
input
document.
Note
that
this
also
includes
a
provision
that
@version
does
not
match
LANG_DIR
;
the
previous
version
of
the
grammar
would
allow
such
a
match,
but
would
result
in
a
literal
with
an
ill-formed
language
tag
according
to
[
BCP47
],
and
form
an
invalid
literal.