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 [[[SPARQL12-QUERY]]] 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 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]].

Introduction

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.

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 [[[?SPARQL12-QUERY]]] [[?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.

Turtle Language

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.

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.

Predicate Lists

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.

Object Lists

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.

IRIs

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 .

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:

  1. Define a prefix label for the vocabulary IRI http://www.perceive.net/schemas/relationship/ as somePrefix
  2. 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:

or SPARQL's syntax for prefix declarations:

Prefixed names are a superset of XML QNames. They differ in that the local part of prefixed names may include:

The following Turtle document contains examples of all the different ways of writing IRIs in Turtle.

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.

RDF Literals

Literals are used to identify values such as strings, numbers, dates.

Quoted Literals

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:

  • Literals delimited by ' may not contain unescaped ', LF, nor CR characters.
  • Literals delimited by " may not contain unescaped ", LF, nor CR characters.
  • Literals delimited by ''' may not contain such a sequence.
  • Literals delimited by """ may not contain such a sequence.

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]".

Booleans

Boolean values may be written as either true or false (case-sensitive) and represent RDF literals with the datatype xsd:boolean [[XMLSCHEMA11-2]].

RDF Blank Nodes

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:

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.

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.

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.

The use of predicateObjectList within a blankNodePropertyList is a common idiom for representing a series of properties of a node.

Abbreviated: Corresponding simple triples:

Collections

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.

Triple Terms

A triple term may be the object of an RDF triple.

A triple term is represented as a tripleTerm with ttSubject, predicate, and ttObject, all preceded by <<(, and all followed by )>>. Note that triple terms may be nested.

Reifying Triples

In RDF, triple terms are rarely used directly, as they are generally restricted to be used only as the object of a triple using the `rdf:reifies` predicate. Such a triple is called a reifying triple. Turtle provides a shorthand notation for writing reifying triples using the reifiedTriple production.

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.

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 ~ >>`.

reifiedTriples 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 IRI or blank node, a fresh RDF blank node is allocated and used to identify this relationship.
For instance, the syntactic sugar of the above example is equivalent to:

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.

A reifiedTriple is syntactic sugar relating a reifier to a tripleTerm using the rdf:reifies predicate.

Annotation Syntax

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.

The annotation syntax is a syntactic shortcut in Turtle, and the RDF Abstract Syntax [[RDF11-CONCEPTS]] does not distinguish how the triples were written.

is the same set of triples as:

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:

An annotation can include any number of reifiers.

Examples

This example is a Turtle translation of example 7 in [[[RDF12-XML]]] (example1.ttl): 



  
An example of an RDF collection of two literals.

  
    
  


  
which is short for (example2.ttl):


  


  
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):


  


  
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,


  
    
  


  
is syntactic sugar for (noting that the 
    blank nodes 
    b0, b1, and b2
    do not occur anywhere else in the RDF graph):


  
    
  


  
RDF collections can be nested and can involve other syntactic forms:


  
    
  


  
is syntactic sugar for:

  
    
  






  
Turtle compared to SPARQL


  
The [[[SPARQL12-QUERY]]]
    (SPARQL) [[SPARQL12-QUERY]]
    uses a Turtle style syntax for its
    TriplesBlock production.
    This production differs from the Turtle language in that:
  


  
    
    
  1. SPARQL permits RDF Literals
      as the subject of Triple Patterns.
    2. 
    
  2. SPARQL permits variables (?name or $name)
      in any part of the triple of the form.
    3. 
    
  3. 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).
    4. 
    
  4. 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.
    5. 
    
  5. true and false are case insensitive in SPARQL
      and case sensitive in Turtle.
      TrUe is not a valid boolean value in Turtle.
    6. 
  


  
For further information see the
  Syntax for IRIs
  and SPARQL Grammar
  sections of the SPARQL query document [[SPARQL12-QUERY]].
  






  
This specification defines conformance criteria for:


  

  
A conforming Turtle document is an RDF string that conforms to the grammar and additional constraints defined in , 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 ,
    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.


  

    
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  for the media type
    registration form.
    

  






  
Turtle Grammar


  
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


    
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


    
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.

  


  

    
IRI References

    

      Relative IRI references are resolved with base IRIs
      as per [[[RFC3986]]] [[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 [[[RFC3987]]] [[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.
    

  


  

    
Escape Sequences


    
There are three forms of escapes used in turtle documents:


    

    

      Context where each kind of escape sequence can be used
      
        

          
          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.

  


  

    
Grammar

    
The EBNF used here is defined in XML 1.0
      [[!EBNF-NOTATION]].
    


    

      
Notes:

      
    
        
  1. 
          Keywords in single quotes
          ('@base',
          '@prefix',
          'a',
          'true',
          'false')
          are case-sensitive.
          Keywords in quotation marks
          ("BASE",
          "PREFIX")
          are case-insensitive.
        
    2. 
        
  2. 
          Escape sequences UCHAR
          and ECHAR
          are case sensitive.
        
    3. 
        
  3. 
          When tokenizing the input and choosing grammar rules, the longest match is chosen.
        
    4. 
        
  4. 
          The Turtle grammar is LL(1) and LALR(1) when the rules with uppercased names
          are used as terminals.
        
    5. 
        
  5. 
          The entry point into the grammar is turtleDoc.
        
    6. 
        
  6. 
          In signed numbers, no white space is allowed between the sign and the number.
        
    7. 
        
  7. 
          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.
        
    8. 
      

    


    

    
A text version of this grammar is available here.

  


  

    
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.


    
    

      
        
CodeGlyphDescription

      
      
        

          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)

      
_:

      
_ followed by :

      
--

      
two concatenated - characters

    

  






  
Parsing


  
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 
    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.
  


  

    
Parser State


    
Parsing Turtle requires a state of eight items:


    

    
Term Constructors can create a stack of these values indicated by
      using language such as "records the |curSubject| and |curPredicate|."

  


  

    
RDF Term Constructors


    
This table maps productions and lexical tokens to RDF terms
      or components of RDF terms
      listed in :


    

      
        
                                                                       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 into which the expanded second argument is stored for future lookup.

      
                                                                                                                                                                                     IRI          When used in a PrefixedName production; the namespaces map MUST have a corresponding namespace, which forms the RDF string of the IRI.

      
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.

      
reifier                                   IRI          
                                                                                                                                                                                                                                    |    blank node   
        
          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.
        
      

      
tripleTerm                        triple term  
        
          The triple term
          is composed of the terms constructed from
          the ttSubject,
          predicate, and
          ttObject productions.
        
      

      
reifiedTriple                   IRI | blank node
        
          The term is taken from the matched reifier, if any,
          or from a fresh RDF blank node.
        
      

      
annotationBlock                 IRI | blank node
        
          The term is taken from a previously matched reifier, if any,
          or from a fresh RDF blank node.
        
      

    
    


  


  

    
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 object N
      in the document produces an RDF triple:
      |curSubject|
        |curPredicate| N .
    


    
Reifiers


    
Beginning the reifier production,
      the |curReifier| is taken from the reifier term constructor.
      Then yield the RDF triple |curReifier| rdf:reifies |curTripleTerm|.


    
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|.


    
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|.


    
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|.

    
If the |curReifier| was already set, the
      reifying triple |curReifier| rdf:reifies |curTripleTerm|
      was emitted in .


    
Property Lists


    

      Beginning the blankNodePropertyList
      production records the |curSubject| and |curPredicate|,
      and sets the |curSubject| to a novel blank node |B|.
      Finishing the blankNodePropertyList
      production restores the |curSubject| and |curPredicate|.
      The node produced by matching blankNodePropertyList
      is the blank node |B|.
    


    
Collections


    

      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 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 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.
    

  


  

    
Parsing Example


    
The following informative example shows the semantic actions performed when  parsing this Turtle document with an LALR(1) parser:

    
      
    


    
  






  
Embedding Turtle in HTML documents


  
HTML [[HTML5]] script tags
    
    can be used to embed data blocks in documents. Turtle can be easily embedded in HTML this way.


  
    
  


  
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.


  

    
XHTML


    

    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.

  


  

    
Parsing Turtle in HTML


    
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.

  






  
Privacy Considerations

  
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.






  
Security Considerations


  
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
    [[[RFC3987]]] [[RFC3987]] Section 8, as well as
    [[[RFC3986]]] [[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]]] [[UNICODE-SECURITY]] and
    [[[RFC3987]]] [[RFC3987]] Section 8.






  
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]`

    
Security considerations:

    
See .

    
Interoperability considerations:

    
There are no known interoperability issues.

    
Published specification:

    
This specification.

    
Applications which use this media type:


    
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-star 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-star WG. The W3C reserves change control over this specifications.

  






  
Acknowledgments


  

    
Acknowledgments for RDF 1.1


    
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.

  


  

    
Acknowledgments for RDF 1.2


    
In addition to the editors, the following people have contributed to this specification:
      
    


    


    
Recognize members of the Task Force? Not an easy to find list of contributors.

  







  
Changes between RDF 1.1 and RDF 1.2