Copyright © 2008-2024 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.
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.
RDF 1.2 Turtle introduces triple terms
as a fourth kind of RDF term
which can be used as the
object of another
triple,
making it possible to make statements about other statements.
Triple terms are typically not used explicitly
as the reifiedTriple
construction is generally preferred.
RDF 1.2 Turtle also adds support for
directional language-tagged strings.
In addition, RDF 1.2 Turtle introduces an annotation syntax which allows triple terms to also be asserted.
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 technical reports index at https://www.w3.org/TR/.
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].
This document was published by the RDF-star Working Group as a Working Draft using the Recommendation track.
Publication as a Working 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 work in progress. Future updates to this specification may incorporate new features.
This document was produced by a group operating under the 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.
This document is governed by the 03 November 2023 W3C Process Document.
This section is non-normative.
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.
BASE <http://example.org/>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX rel: <http://www.perceive.net/schemas/relationship/>
<#green-goblin>
rel:enemyOf <#spiderman> ;
a foaf:Person ; # in the context of the Marvel universe
foaf:name "Green Goblin" .
<#spiderman>
rel:enemyOf <#green-goblin> ;
a foaf:Person ;
foaf:name "Spiderman", "Человек-паук"@ru .
This example introduces many of features of the Turtle language:
BASE and Relative IRI references,
PREFIX and prefixed names,
predicate lists separated by ;
,
object lists separated by ,
,
the token a
,
and literals.
The Turtle grammar for
triples
is a subset of SPARQL 1.2 Query Language [SPARQL12-QUERY] grammar
for TriplesBlock
.
The two grammars share production and terminal names where possible.
The construction of an RDF graph from a Turtle document is defined in Turtle Grammar and Parsing.
This section is non-normative.
A Turtle document allows writing down an RDF graph in a compact textual form. An RDF graph is made up of triples consisting of a subject, predicate and object.
Comments may follow a #
that is not part of
another lexical token, and continue to the end of the line.
The simplest triple statement is a sequence of (subject, predicate, object) terms,
separated by white space
(spaces
, and/or tabs
)
and terminated by .
after the object.
<http://example.org/#spiderman>
<http://www.perceive.net/schemas/relationship/enemyOf>
<http://example.org/#green-goblin> .
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.
<http://example.org/#spiderman> <http://www.perceive.net/schemas/relationship/enemyOf> <http://example.org/#green-goblin> ;
<http://xmlns.com/foaf/0.1/name> "Spiderman" .
<http://example.org/#spiderman> <http://www.perceive.net/schemas/relationship/enemyOf> <http://example.org/#green-goblin> .
<http://example.org/#spiderman> <http://xmlns.com/foaf/0.1/name> "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.
<http://example.org/#spiderman> <http://xmlns.com/foaf/0.1/name> "Spiderman", "Человек-паук"@ru .
<http://example.org/#spiderman> <http://xmlns.com/foaf/0.1/name> "Spiderman" .
<http://example.org/#spiderman> <http://xmlns.com/foaf/0.1/name> "Человек-паук"@ru .
There are four RDF terms defined in RDF Concepts: IRIs (Internationalized Resource Identifiers), literals, blank nodes, and triple terms; Turtle provides a number of ways of writing each.
IRIs may be written as resolved IRIs,
Relative IRI references,
or prefixed names.
Relative and resolved IRIs are preceded by <
,
followed by >
, and
may contain numeric escape sequences (described below).
For example, <http://example.org/#green-goblin>
.
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.
The Turtle language originally permitted only the syntax including
the @
character for writing prefix and base directives.
The case-insensitive PREFIX
and BASE
forms were added to align Turtle's syntax with that of SPARQL.
The original directives @prefix
and @base
may also be used.
Using PREFIX
and BASE
may make it easier
to copy declarations to SPARQL queries.
To write http://www.perceive.net/schemas/relationship/enemyOf
using a prefixed name:
http://www.perceive.net/schemas/relationship/
as somePrefix
somePrefix:enemyOf
which is equivalent to writing
<http://www.perceive.net/schemas/relationship/enemyOf>
This can be written using either the original Turtle syntax for prefix declarations:
@prefix somePrefix: <http://www.perceive.net/schemas/relationship/> .
<http://example.org/#green-goblin> somePrefix:enemyOf <http://example.org/#spiderman> .
or SPARQL's syntax for prefix declarations:
PREFIX somePrefix: <http://www.perceive.net/schemas/relationship/>
<http://example.org/#green-goblin> somePrefix:enemyOf <http://example.org/#spiderman> .
Prefixed names are a superset of XML QNames. They differ in that the local part of prefixed names may include:
leg:3032571
or isbn13:9780136019701
og:video:height
wgs:lat\-long
The following Turtle document contains examples of all the different ways of writing IRIs in Turtle.
# 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 .
Literals are used to identify values such as strings, numbers, dates.
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
<http://example.org/#green-goblin> foaf:name "Green Goblin" .
<http://example.org/#spiderman> foaf:name "Spiderman" .
Quoted Literals (Grammar production
RDFLiteral
) have a lexical form
followed by a language tag
(possibly including a base direction),
a datatype IRI, or neither.
The representation of the lexical form consists of an initial delimiter
(e.g.,
"
,
'
,
"""
, or
'''
);
a sequence of permitted characters, numeric escapes,
and/or string escapes; and a final delimiter (matching the initial delimiter).
The corresponding RDF lexical form
is the characters between the delimiters,
after processing any escape sequences.
If present, the language tag is preceded by
an @
and may be followed by a base direction
separated from the language tag by --
.
If there is no language tag, there may be a datatype IRI,
preceded by ^^
.
A datatype IRI in Turtle may be written using either a
resolved IRI,
a relative IRI reference,
or a prefixed name.
If there is no datatype IRI and no language tag,
the datatype is xsd:string
.
A \
may not appear in any quoted literal except as part of an escape sequence.
Other restrictions depend on the delimiter:
'
may not contain unescaped
'
,
LF
, nor
CR
characters."
may not contain unescaped
"
,
LF
, nor
CR
characters.'''
may not contain such a sequence."""
may not contain such a sequence.
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 "That Seventies Show"@en--ltr . # literal with a language tag and base direction
show:218 show:localName "That Seventies Show"@en-us--ltr . # literal with a language tag, region subtag, and base 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 embedded new lines and quotes
literal with many quotes (""""")
and up to two sequential apostrophes ('').''' .
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] ". |
PREFIX : <http://example.org/elements/>
<http://en.wikipedia.org/wiki/Helium>
:atomicNumber 2 ; # xsd:integer
:atomicMass 4.002602 ; # xsd:decimal
:specificGravity 1.663E-4 . # xsd:double
Boolean values may be written as either true
or false
(case-sensitive)
and represent RDF literals with the datatype xsd:boolean [XMLSCHEMA11-2].
PREFIX : <http://example.org/stats/>
<http://somecountry.example/census2007>
:isLandlocked false . # xsd:boolean
RDF blank nodes in Turtle are expressed
as _:
followed by a blank node identifier which is a series of characters.
The characters in the identifier are built upon
PN_CHARS_BASE
,
liberalized as follows:
_
and
the digit characters 0
–9
, inclusive)
may appear anywhere in a
blank node identifier..
may appear anywhere except the first or last character.-
,
·
,
‿
,
⁀
,
and
the combining diacritical marks (U+0300
to U+036F
)
are permitted anywhere except the first character.A fresh RDF blank node is allocated for each unique blank node identifier in a document. Repeated use of the same blank node identifier identifies the same blank node.
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
_:alice foaf:knows _:bob .
_:bob foaf:knows _:alice .
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.
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
# Someone knows someone else, who has the name "Bob".
[] foaf:knows [ foaf:name "Bob" ] .
The Turtle grammar allows blankNodePropertyList
s
to be nested.
In this case, each inner [
establishes a new subject blank node which reverts to the outer node
at the ]
, and serves as the current subject
for predicate object lists.
The use of predicateObjectList
within a blankNodePropertyList
is a common idiom for representing a series of properties of a node.
Abbreviated: | Corresponding simple triples: |
---|---|
|
|
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 reified triple may be the subject or object of an RDF triple.
A reified triple is syntactic sugar for 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.
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.
A reified triple is represented using the
reifiedTriple
production
starting with <<
,
followed by subject
,
predicate
, and
ttObject
,
optionally follwed by a reifier
(IRIREF
or BlankNode
),
and ending with >>
.
For example, << :subject :predicate :object ~ :IRIREF >>
.
If the optional reifier is not present, a fresh RDF blank node is allocated,
as with << :subject :predicate :object >>
.
Reified Triples may be nested,
like << :subject1 :predicate1 << :subject2 :predicate2 :object2 >> ~:IRIREF1 >>
or << :subject4 :predicate4 << :subject3 :predicate3 :object3 ~:IRIREF3 >> >>
.
If a reifiedTriple
is not identified by an IRIREF
or BlankNode
,
a fresh RDF blank node is allocated
and used to identify this relationship.
PREFIX : <http://www.example.org/>
:employee38 :familyName "Smith" .
<< :employee38 :jobTitle "Assistant Designer" >> :accordingTo :employee22 .
PREFIX : <http://www.example.org/>
:employee38 :familyName "Smith" .
<< :employee38 :jobTitle "Assistant Designer" ~ _:id >> :accordingTo :employee22 .
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 reified triple.
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 reified triple.
A reified triple is syntactic sugar relating an
reifier to a tripleTerm
using the rdf:reifies
predicate.
Turtle also defines an annotation syntax
to both reify and assert a triple,
which provides a convenient shortcut.
An annotation can be used to both assert a triple,
via an explicit or implicit identifier,
and have that triple be the
subject of further triples.
If explicitly identified, the same reifier can then be used as the
object of additional
triples and/or triple terms.
As with a reified triple,
the annotation syntax allows the definition of
an reifier as either an IRIREF
or BlankNode
preceded by ~
,
which proceeds the annotation block.
The delimiters {|
and |}
subject
,
predicate
,
object
.
The annotation syntax is a syntactic shortcut in Turtle, and the RDF Abstract Syntax [RDF11-CONCEPTS] does not distinguished how the triples were written.
PREFIX : <http://example.com/>
:a :name "Alice" ~ :t {| :statedBy :bob ; :recorded "2021-07-07"^^xsd:date |} .
is the same set of triples as:
PREFIX : <http://example.com/> :a :name "Alice" . << :a :name "Alice" ~ :t >> :statedBy :bob ; :recorded "2021-07-07"^^xsd:date .
and the graph contains three triples.
The reifier is identified by :t
.
Fully expanding to use triple terms, instead of reifiers, results in the following:
PREFIX : <http://example.com/> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> :a :name "Alice" . :t rdf:reifies <<( :a :name "Alice" )>> . :t :statedBy :bob . :t :recorded "2021-07-07"^^xsd:date .
This section is non-normative.
This example is a Turtle translation of example 7 in RDF 1.2 XML Syntax (example1.ttl):
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX dc: <http://purl.org/dc/elements/1.1/>
PREFIX ex: <http://example.org/stuff/1.0/>
<http://www.w3.org/TR/rdf-syntax-grammar>
dc:title "RDF/XML Syntax Specification (Revised)" ;
ex:editor [
ex:fullname "Dave Beckett";
ex:homePage <http://purl.org/net/dajobe/>
] .
An example of an RDF collection of two literals.
PREFIX : <http://example.org/stuff/1.0/>
:a :b ( "apple" "banana" ) .
which is short for (example2.ttl):
PREFIX : <http://example.org/stuff/1.0/>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
:a :b
[ rdf:first "apple";
rdf:rest [ rdf:first "banana";
rdf:rest rdf:nil ]
] .
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.
For example,
PREFIX : <http://example.org/stuff/1.0/>
(1 2.0 3E1) :p "w" .
is syntactic sugar for (noting that the
blank nodes
b0
, b1
, and b2
do not occur anywhere else in the RDF graph):
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX : <http://example.org/stuff/1.0/>
_:b0 rdf:first 1 ;
rdf:rest _:b1 .
_:b1 rdf:first 2.0 ;
rdf:rest _:b2 .
_:b2 rdf:first 3E1 ;
rdf:rest rdf:nil .
_:b0 :p "w" .
RDF collections can be nested and can involve other syntactic forms:
PREFIX : <http://example.org/stuff/1.0/>
(1 [:p :q] ( 2 ) ) :p2 :q2 .
is syntactic sugar for:
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX : <http://example.org/stuff/1.0/>
_:b0 :p2 :q2 .
_:b0 rdf:first 1 ;
rdf:rest _:b1 .
_:b1 rdf:first _:b2 .
_:b2 :p :q .
_:b1 rdf:rest _:b3 .
_:b3 rdf:first _:b4 .
_:b4 rdf:first 2 ;
rdf:rest rdf:nil .
_:b3 rdf:rest rdf:nil .
This section is non-normative.
The SPARQL 1.2 Query Language (SPARQL) [SPARQL12-QUERY] uses a Turtle style syntax for its TriplesBlock production. This production differs from the Turtle language in that:
?
name or $
name)
in any part of the triple of the form.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.For further information see the Syntax for IRIs and SPARQL Grammar sections of the SPARQL query document [SPARQL12-QUERY].
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 MUST 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 document is an RDF string that conforms to the grammar and additional constraints defined in 6. Turtle Grammar, starting with the turtleDoc
production. A Turtle document serializes an RDF graph.
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
This specification does not define how Turtle parsers handle non-conforming input documents.
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.
A Turtle document is an RDF string
encoded in UTF-8 [RFC3629].
Only Unicode code points
in the range U+0000
to U+10FFFF
inclusive are allowed.
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
.
Comments in Turtle start with a #
outside an
IRIREF
or String
,
and continue to the end of line (marked by
LF
, or
CR
),
or end of file if there is no end of line after the comment marker.
Comments are treated as white space.
Relative IRI references are resolved with base IRIs as per Uniform Resource Identifier (URI): Generic Syntax [RFC3986] using only the basic algorithm in section 5.2. Neither Syntax-Based Normalization nor Scheme-Based Normalization (described in sections 6.2.2 and 6.2.3 of RFC3986) are performed. Characters additionally allowed in IRI references are treated in the same way that unreserved characters are treated in URI references, per section 6.5 of Internationalized Resource Identifiers (IRIs) [RFC3987].
The @base
or BASE
directive
defines the Base IRI used to resolve relative IRI references
per [RFC3986] section 5.1.1, "Base URI Embedded in Content".
Section 5.1.2, "Base URI from the Encapsulating Entity"
defines how the In-Scope Base IRI may come from an encapsulating document,
such as a SOAP envelope with an xml:base
directive or a MIME multipart document with a
Content-Location
header.
The "Retrieval URI" identified in 5.1.3, Base "URI from the Retrieval URI",
is the URL from which a particular Turtle document was retrieved.
If none of the above specifies the Base URI, the default
Base URI (section 5.1.4, "Default Base URI") is used.
Each @base
or BASE
directive sets a new In-Scope Base URI,
relative to the previous one.
There are three forms of escapes used in turtle documents:
numeric escape sequences represent Unicode code points:
Escape sequence | Unicode code point |
---|---|
\u hex
hex
hex
hex |
A Unicode code point
in the range U+0000 to U+FFFF inclusive
corresponding to the value encoded by the four hexadecimal digits interpreted
from most significant to least significant digit. |
\U hex
hex
hex
hex
hex
hex
hex
hex |
A Unicode code point
in the range U+0000 to U+0010FFFF inclusive
corresponding to the value encoded by the eight hexadecimal digits
interpreted from most significant to least significant digit. |
where hex
is a hexadecimal character
HEX
::= [0-9] | [A-F] | [a-f]
string escape sequences represent the characters 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 |
reserved character escape sequences consist of
a \
followed by one of ~.-!$&'()*+,;=/?#@%_
and represent the character to the right of the \
.
numeric escapes |
string escapes |
reserved character escapes |
|
---|---|---|---|
IRIs,
used as RDF terms
or as in @prefix ,
PREFIX ,
@base ,
or BASE declarations |
yes | no | no |
local names | no | no | yes |
Strings | yes | yes | no |
%-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
.
The EBNF used here is defined in XML 1.0 [EBNF-NOTATION].
Notes:
@base
',
'@prefix
',
'a
',
'true
',
'false
')
are case-sensitive.
Keywords in quotation marks
("BASE
",
"PREFIX
")
are case-insensitive.
UCHAR
and ECHAR
are case sensitive.
turtleDoc
.
@prefix
'
and '@base
'
match the pattern for LANG_DIR
,
though neither prefix
nor base
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.
[1] | turtleDoc |
::= | statement* |
[2] | statement |
::= | directive | ( triples '. ') |
[3] | directive |
::= | prefixID | base | sparqlPrefix | sparqlBase |
[4] | prefixID |
::= | '@prefix ' PNAME_NS IRIREF '. ' |
[5] | base |
::= | '@base ' IRIREF '. ' |
[6] | sparqlPrefix |
::= | "PREFIX " PNAME_NS IRIREF |
[7] | sparqlBase |
::= | "BASE " IRIREF |
[8] | triples |
::= | ( subject predicateObjectList) | ( blankNodePropertyList predicateObjectList? ) |
[9] | predicateObjectList |
::= | verb objectList ( '; ' ( verb objectList) ? ) * |
[10] | objectList |
::= | object annotation ( ', ' object annotation) * |
[11] | verb |
::= | predicate | 'a ' |
[12] | subject |
::= | iri | BlankNode | collection | reifier |
[13] | predicate |
::= | iri |
[14] | object |
::= | iri | BlankNode | collection | blankNodePropertyList | literal | tripleTerm | reifiedTriple |
[15] | literal |
::= | RDFLiteral | NumericLiteral | BooleanLiteral |
[16] | blankNodePropertyList |
::= | '[ ' predicateObjectList '] ' |
[17] | collection |
::= | '( ' object* ') ' |
[18] | NumericLiteral |
::= | INTEGER | DECIMAL | DOUBLE |
[19] | RDFLiteral |
::= | String ( LANG_DIR | ( '^^ ' iri) ) ? |
[20] | BooleanLiteral |
::= | 'true ' | 'false ' |
[21] | String |
::= | STRING_LITERAL_QUOTE | STRING_LITERAL_SINGLE_QUOTE | STRING_LITERAL_LONG_SINGLE_QUOTE | STRING_LITERAL_LONG_QUOTE |
[22] | iri |
::= | IRIREF | PrefixedName |
[23] | PrefixedName |
::= | PNAME_LN | PNAME_NS |
[24] | BlankNode |
::= | BLANK_NODE_LABEL | ANON |
[25] | reifier |
::= | '~ ' ( iri | BlankNode) |
[26] | reifiedTriple |
::= | '<< ' subject predicate object reifier? '>> ' |
[27] | tripleTerm |
::= | '<<( ' ttSubject predicate ttObject ')>> ' |
[28] | ttSubject |
::= | iri | BlankNode |
[29] | ttObject |
::= | iri | BlankNode | literal | tripleTerm |
[30] | annotation |
::= | ( reifier | ( '{| ' predicateObjectList '|} ') ) * |
[32] | IRIREF |
::= | '< ' ( [ ^ #x00 - #x20 <>"{}|^`\ ] | UCHAR) * '> '
/* #x00=NULL #x01-#x1F=control codes #x20=space */ |
[33] | PNAME_NS |
::= | PN_PREFIX? ': ' |
[34] | PNAME_LN |
::= | PNAME_NS PN_LOCAL |
[35] | BLANK_NODE_LABEL |
::= | '_: ' ( PN_CHARS_U | [ 0-9 ] ) ( ( PN_CHARS | '. ') * PN_CHARS) ? |
[36] | LANG_DIR |
::= | '@ ' [ a-zA-Z ] + ( '- ' [ a-zA-Z0-9 ] + ) * ( '-- ' [ a-zA-Z ] + ) ? |
[37] | INTEGER |
::= | [ +- ] ? [ 0-9 ] + |
[38] | DECIMAL |
::= | [ +- ] ? ( [ 0-9 ] * '. ' [ 0-9 ] + ) |
[39] | DOUBLE |
::= | [ +- ] ? ( ( [ 0-9 ] + '. ' [ 0-9 ] * EXPONENT) | ( '. ' [ 0-9 ] + EXPONENT) | ( [ 0-9 ] + EXPONENT) ) |
[40] | EXPONENT |
::= | [ eE ] [ +- ] ? [ 0-9 ] + |
[41] | STRING_LITERAL_QUOTE |
::= | '" ' ( [ ^ #x22 #x5C #x0A #x0D ] | ECHAR | UCHAR) * '" ' |
[42] | STRING_LITERAL_SINGLE_QUOTE |
::= | "' " ( [ ^ #x27 #x5C #x0A #x0D ] | ECHAR | UCHAR) * "' " |
[43] | STRING_LITERAL_LONG_SINGLE_QUOTE |
::= | "''' " ( ( "' " | "'' ") ? ( [ ^'\ ] | ECHAR | UCHAR) ) * "''' " |
[44] | STRING_LITERAL_LONG_QUOTE |
::= | '""" ' ( ( '" ' | '"" ') ? ( [ ^"\ ] | ECHAR | UCHAR) ) * '""" ' |
[45] | UCHAR |
::= | ( '\u ' HEX HEX HEX HEX) | ( '\U ' HEX HEX HEX HEX HEX HEX HEX HEX) |
[46] | ECHAR |
::= | '\ ' [ tbnrf\"' ] |
[47] | WS |
::= | #x20 | #x09 | #x0D | #x0A |
[48] | ANON |
::= | '[ ' WS* '] ' |
[49] | PN_CHARS_BASE |
::= | [ A-Z ] |
| |
[ a-z ] |
||
| |
[ #xC0 - #xD6 ] |
||
| |
[ #xD8 - #xF6 ] |
||
| |
[ #xF8 - #x02FF ] |
||
| |
[ #x0370 - #x037D ] |
||
| |
[ #x037F - #x1FFF ] |
||
| |
[ #x200C - #x200D ] |
||
| |
[ #x2070 - #x218F ] |
||
| |
[ #x2C00 - #x2FEF ] |
||
| |
[ #x3001 - #xD7FF ] |
||
| |
[ #xF900 - #xFDCF ] |
||
| |
[ #xFDF0 - #xFFFD ] |
||
| |
[ #x00010000 - #x000EFFFF ] |
||
[50] | PN_CHARS_U |
::= | PN_CHARS_BASE | '_ ' |
[51] | PN_CHARS |
::= | PN_CHARS_U | '- ' | [ 0-9 ] | #xB7 | [ #x0300 - #x036F ] | [ #x203F - #x2040 ] |
[52] | PN_PREFIX |
::= | PN_CHARS_BASE ( ( PN_CHARS | '. ') * PN_CHARS) ? |
[53] | PN_LOCAL |
::= | ( PN_CHARS_U | ': ' | [ 0-9 ] | PLX) ( ( PN_CHARS | '. ' | ': ' | PLX) * ( PN_CHARS | ': ' | PLX) ) ? |
[54] | PLX |
::= | PERCENT | PN_LOCAL_ESC |
[55] | PERCENT |
::= | '% ' HEX HEX |
[56] | HEX |
::= | [ 0-9 ] | [ A-F ] | [ a-f ] |
[57] | PN_LOCAL_ESC |
::= | '\ ' ( '_ ' | '~ ' | '. ' | '- ' | '! ' | '$ ' | '& ' | "' " | '( ' | ') ' | '* ' | '+ ' | ', ' | '; ' | '= ' | '/ ' | '? ' | '# ' | '@ ' | '% ') |
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 |
| |
Verticle bar |
U+007E |
~ |
Tilda |
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
"""
U+0022
'''
U+0027
<<
U+003C
>>
U+003E
^^
U+005E
{|
{
(left curly bracket, code point U+007B
) followed by
|
(verticle bar, code point U+007C
)|}
|
(verticle bar, code point U+007C
) followed by
}
(right curly bracket, code point U+007D
)_:
_
followed by :
--
-
charactersThe 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 a base 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.
Parsing Turtle requires a state of six items:
Describe parser state for tracking reifier to associated with an annotation block.
base
production is reached, the second rule argument,
IRIREF
, is the base URI used for relative
IRI resolution.
PNAME_NS
and IRIREF
)
in the prefixID
production
assign a namespace name (IRIREF
) for the prefix
(PNAME_NS
).
Outside of a prefixID
production,
any PNAME_NS
is substituted with the namespace.
Note that the prefix may be an empty string, per the
PNAME_NS
production: PN_PREFIX? ':'
.
subject
production.verb
production.
If token matched was a
,
curPredicate is bound to the IRI
http://www.w3.org/1999/02/22-rdf-syntax-ns#type
.
object
and
ttObject
productions.This table maps productions and lexical tokens to RDF terms or components of RDF terms listed in 7. Parsing:
production | type | procedure |
---|---|---|
IRIREF | IRI | The characters between < and > are taken, with the numeric escape sequences unescaped, to form the IRI. Relative IRI reference resolution is performed per Section 6.3. |
PNAME_NS | prefix | 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. |
IRI | When used in a PrefixedName production, the iri is the value in the namespaces map corresponding to the first argument of the rule. | |
PNAME_LN | IRI | 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 . |
STRING_LITERAL_SINGLE_QUOTE | lexical form | 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. |
STRING_LITERAL_QUOTE | lexical form | The characters between the outermost " s are taken, with numeric and string escape sequences unescaped, to form the RDF string of a lexical form. |
STRING_LITERAL_LONG_SINGLE_QUOTE | lexical form | The characters between the outermost ''' s are taken, with numeric and string escape sequences unescaped, to form the RDF string of a lexical form. |
STRING_LITERAL_LONG_QUOTE | 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. |
LANG_DIR | language tag | The characters following the @ form the language tag and optionally the base direction, if the matched characters include -- . |
RDFLiteral | literal | 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 base direction are taken from LANG_DIR . If there is no base direction, the datatype is rdf:langString . If there is a base direction, the datatype is rdf:dirLangString . If neither matched, the datatype is xsd:string , and the literal has no language tag. |
INTEGER | literal | The literal has a lexical form of the input string, and a datatype of xsd:integer . |
DECIMAL | literal | The literal has a lexical form of the input string, and a datatype of xsd:decimal . |
DOUBLE | literal | The literal has a lexical form of the input string, and a datatype of xsd:double . |
BooleanLiteral | literal | The literal has a lexical form of the true or false , depending on which matched the input, and a datatype of xsd:boolean . |
BLANK_NODE_LABEL | blank node | The string matching the second argument, PN_LOCAL , is a key in bnodeLabels. If there is no corresponding blank node in the map, one is allocated. |
ANON | blank node | A blank node is generated. |
blankNodePropertyList | blank node | A blank node is generated. Note the rules for blankNodePropertyList in the next section. |
collection | blank node | For non-empty lists, a blank node is generated. Note the rules for collection in the next section. |
IRI | For empty lists, the resulting IRI is rdf:nil . Note the rules for collection in the next section. | |
tripleTerm | triple term |
The triple term
is composed of the terms constructed from
the subject ,
predicate , and
ttObject productions.
|
reifiedTriple | IRI | blank node |
The reifiedTriple production
defines an RDF term in addition to a triple term.
The term constructed from this production
is composed of an identifier from either the iri
or BlankNode productions,
if present, otherwise from a fresh RDF blank node.
|
annotation | IRI | blank node |
The annotation production
defines an RDF term in addition to a triple term.
The term constructed from this production
is composed of an identifier from either the iri
or BlankNode productions,
if present, otherwise from a fresh RDF blank node.
Editor's note Requires state to recall any previously defined reifier . |
A Turtle document defines an RDF graph composed of set of RDF triples.
The subject
production sets the curSubject.
The verb
production sets the curPredicate.
The object
and ttObject
productions set the curObject.
Each object
N
in the document produces an RDF triple:
curSubject
curPredicate N .
Beginning the tripleTerm
production
records the curSubject and curPredicate.
Finishing the tripleTerm
production
and restores the recorded values of curSubject and curPredicate.
Beginning the reifiedTriple
production
records the curSubject and curPredicate.
curSubject is taken from the
reifiedTriple
term constructor.
A new tripleTerm
instance TT
is composed from
the subject
,
predicate
, and
object
productions.
Finishing the reifier
production
yields the RDF triple curSubject rdf:reifies
TT
and restores the recorded values of curSubject and curPredicate.
Beginning the annotation
production
records the curSubject and curPredicate.
A new tripleTerm
instance TT
is created using curSubject curPredicate curObject.
The identifier TI is taken from the
annotation
term constructor.
Finishing the annotation
production
yields the RDF triple TI rdf:reifies
TT
and restores the recorded values of curSubject and curPredicate.
Describe parser state for recording and assigning any reifier.
Beginning the blankNodePropertyList
production records the curSubject
and curPredicate,
and sets curSubject
to a novel blank node B.
Finishing the blankNodePropertyList
production restores curSubject
and curPredicate.
The node produced by matching blankNodePropertyList
is the blank node B.
Beginning the collection
production records the curSubject and curPredicate.
Each object
in the collection
production has a curSubject set to a novel blank node B and a curPredicate set to rdf:first
.
For each object objectn after the first produces a triple:objectn-1 rdf:rest
objectn .
Finishing the collection
production creates an additional triple curSubject rdf:rest rdf:nil
. and restores 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.
This section is non-normative.
The following informative example shows the semantic actions performed when parsing this Turtle document with an LALR(1) parser:
PREFIX ericFoaf: <http://www.w3.org/People/Eric/ericP-foaf.rdf#>
PREFIX : <http://xmlns.com/foaf/0.1/>
ericFoaf:ericP :givenName "Eric" ;
:knows <http://norman.walsh.name/knows/who/dan-brickley> ,
[ :mbox <mailto:timbl@w3.org> ] ,
<http://getopenid.com/amyvdh> .
ericFoaf
to the IRI http://www.w3.org/People/Eric/ericP-foaf.rdf#
.http://xmlns.com/foaf/0.1/
.http://www.w3.org/People/Eric/ericP-foaf.rdf#ericP
.http://xmlns.com/foaf/0.1/givenName
.<...rdf#ericP>
<.../givenName>
"Eric"
.http://xmlns.com/foaf/0.1/knows
.<...rdf#ericP>
<.../knows>
<...who/dan-brickley>
.<...rdf#ericP>
<.../knows>
_:1
._:1
.http://xmlns.com/foaf/0.1/mbox
._:1
<.../mbox>
<mailto:timbl@w3.org>
.<...rdf#ericP>
, <.../knows>
).<...rdf#ericP>
<.../knows>
<http://getopenid.com/amyvdh>
.This section is non-normative.
HTML [HTML5] script
tags
can be used to embed data blocks in documents. Turtle can be easily embedded in HTML this way.
<script type="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.
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.
<script type="text/turtle">
# <![CDATA[
PREFIX frbr: <http://purl.org/vocab/frbr/core#>
<http://books.example.com/works/45U8QJGZSQKDH8N> a frbr:Work .
# ]]>
</script>
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.
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.
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.
This section is non-normative.
The STRING_LITERAL_SINGLE_QUOTE
,
STRING_LITERAL_QUOTE
,
STRING_LITERAL_LONG_SINGLE_QUOTE
, and
STRING_LITERAL_LONG_QUOTE
,
productions allow the use of unescaped control characters.
Although this specification does not directly expose this content to an end user,
it might be presented through a user agent, which may cause the presented text to
be obfuscated due to presentation of such characters.
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.
Turtle uses IRIs as term identifiers. Applications interpreting data expressed in Turtle SHOULD address the security issues of Internationalized Resource Identifiers (IRIs) [RFC3987] Section 8, as well as Uniform Resource Identifier (URI): Generic Syntax [RFC3986] Section 7.
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.
The Internet Media Type (formerly known as MIME Type) for Turtle is "text/turtle".
It is recommended that Turtle files have the extension ".ttl" (all lowercase) on all platforms.
It is recommended that Turtle files stored on Macintosh HFS file systems be given a file type of "TEXT".
This information that follows has been submitted to the IESG for review, approval, and registration with IANA.
charset
— this parameter is required when transferring non-ASCII data. If present, the value of charset
is always UTF-8
.\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]
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).
This work was started during the Semantic Web Advanced Development Europe (SWAD-Europe) project funded by the EU IST-7 programme IST-2001-34732 (2002-2004) and further development supported by the Institute for Learning and Research Technology at the University of Bristol, UK (2002-Sep 2005).
Valuable contributions to this version were made by Gregg Kellogg, Andy Seaborn, Sandro Hawke and the members of the RDF Working Group.
The document was improved through the review process by the wider community.
This section is non-normative.
In addition to the editors, the following people have contributed to this specification: Andrew Louis, Mirek Kratochvil, Peter F. Patel-Schneider, Pierre-Antoine Champin, and Ted Thibodeau Jr
Members of the RDF-star Working Group Group included Achille Zappa, Adrian Gschwend, Alan Snyder, Amin Anjomshoaa, Andy Seaborne, Antoine Zimmermann, Dan Brickley, Dave Raggett, Dominik Tomaszuk, Dörthe Arndt, Enrico Franconi, Erich Bremer, Fabien Gandon, Felix Sasaki, Gregg Kellogg, Gregory Williams, Jean-Yves Rossi, Jose Emilio Labra Gayo, Julián Arenas-Guerrero, Kurt Cagle, Niklas Lindström, Olaf Hartig, Ora Lassila, Pasquale Lisena, Peter Patel-Schneider, Pierre-Antoine Champin, Raphaël Troncy, Richard Lea, Ruben Taelman, Rémi Ceres, Souripriya Das, Ted Thibodeau Jr, Thomas Lörtsch, Thomas Pellissier Tanon, Timothée Haudebourg, and Vladimir Alexiev.
Recognize members of the Task Force? Not an easy to find list of contributors.
This section is non-normative.
STRING_LITERAL_QUOTE
and STRING_LITERAL_SINGLE_QUOTE
.LANGTAG
terminal production to
LANG_DIR
to include
an optional base direction.Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in: