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.
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].
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 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.
Comments may follow a # that is not part of
another lexical token, and continue to the end of the line.
2.1 Simple Triples
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.
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.
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.
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 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:
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 original Turtle syntax for prefix declarations:
Example 7: Original 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.5 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 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 --.
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 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 many quotes (""""")
and up to two sequential apostrophes ('').''' . # literal with embedded new lines and quotes
2.5.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.7 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.
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 blankNodePropertyLists
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.
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.
A reifying triple is represented using the
reifiedTriple production
starting with <<,
followed by a rtSubject,
a predicate, and
a rtObject,
followed by an optional reifier,
composed of a ~
followed by an optional iri production
or BlankNode production,
and ending with >>.
For example, << :subject :predicate :object ~ :IRIREF >>.
If no reifiers are present,
or a reifier
is not immediately followed by an iri
or BlankNode,
a fresh RDF blank node is allocated,
as with << :subject :predicate :object >>,
or << :subject :predicate :object ~ >>.
Note
reifiedTriples may be nested,
like
<< :subject1 :predicate1 << :subject2 :predicate2 :object2 >> ~:IRIREF1 >>
or << :subject4 :predicate4 << :subject3 :predicate3 :object3 ~:IRIREF3 >> >>.
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 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 permits variables (?name or $name)
in any part of the triple of the form.
Turtle allows prefix and base declarations
anywhere outside of a triple.
In SPARQL, they are only allowed in the
Prologue
(at the start of the SPARQL query).
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 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 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.
6.2 Comments
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.
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.
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.
%-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.
6.5 Grammar
The EBNF used here is defined in XML 1.0
[EBNF-NOTATION].
Notes:
Keywords in single quotes
('@base',
'@prefix',
'a',
'true',
'false')
are case-sensitive.
Keywords in quotation marks
("BASE",
"PREFIX")
are case-insensitive.
Escape sequences UCHAR
and ECHAR
are case sensitive.
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'
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.
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 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.
7.1 Parser State
Parsing Turtle requires a state of eight items:
IRI baseURI
— When the
base production is reached, the second rule argument,
IRIREF, is the base URI used for relative
IRI resolution.
Map[prefix
-> IRI]
namespaces — The second and third rule arguments
(PNAME_NS and IRIREF)
in the prefixID production
assign a namespace name (IRIREF) for the prefix
(PNAME_NS).
Outside of a
prefixID or
sparqlPrefix production,
any PNAME_NS is substituted with the namespace from the current state of the namespaces map.
Note that the prefix may be an empty string, per the
PNAME_NS production: PN_PREFIX? ':'.
Map[string
-> blank node] bnodeLabels
— A mapping from string to blank node.
RDF TermcurPredicate
— 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.
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.
A potentially empty prefix is identified by the first sequence, PNAME_NS. The namespaces mapMUST 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 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 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.
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.
The term is taken from a previously matched reifier, if any,
or from a fresh RDF blank node.
7.3 RDF Triples Constructors
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 objectN
in the document produces an RDF triple:
curSubjectcurPredicateN .
7.3.1 Reifiers
Beginning the reifier production,
the curReifier is taken from the reifier term constructor.
Then yield the RDF triple curReifierrdf:reifiescurTripleTerm.
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 curReifierrdf:reifiescurTripleTerm,
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 curSubjectcurPredicatecurObject,
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 curReifierrdf:reifiescurTripleTerm.
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 curReifierrdf:reifiescurTripleTerm
was emitted in 7.3.1 Reifiers.
7.3.5 Property Lists
Beginning the blankNodePropertyList
production records the curSubject and curPredicate,
and sets the curSubject to a novel blank nodeB.
Finishing the blankNodePropertyList
production restores the curSubject and curPredicate.
The node produced by matching blankNodePropertyList
is the blank node B.
7.3.6 Collections
Beginning the collection production records the curSubject and curPredicate.
Each object in the collection production has curSubject set to a novel blank nodeB and curPredicate set to rdf:first.
For each object objectn after the first produces a triple:objectn-1rdf:restobjectn .
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.
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:
The Turtle specification is the product of the RDF-star 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 Seaborn, 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, Mirek Kratochvil, Peter F. Patel-Schneider, Pierre-Antoine Champin, Ted Thibodeau Jr, and William Van Woensel
Members of the RDF-star Working Group Group included
Vladimir Alexiev,
Amin Anjomshoaa,
Julián Arenas-Guerrero,
Dörthe Arndt,
Bilal Ben Mahria,
Erich Bremer,
Kurt Cagle,
Rémi Ceres,
Pierre-Antoine Champin,
Souripriya Das,
Daniil Dobriy,
Enrico Franconi,
Jeffrey Phillips Freeman,
Fabien Gandon,
Benjamin Goering,
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,
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.