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 part of the RDF 1.2 document suite.
The N-Triples format is a line-based RDF syntax
based on a subset of Turtle [RDF12-TURTLE].
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 N-Triples, a concrete syntax for
RDF [RDF12-CONCEPTS].
N-Triples is an easy to parse line-based subset of
Turtle [RDF12-TURTLE].
The syntax is a revised version of N-Triples as originally defined in
the RDF Test Cases [RDF-TESTCASES] document.
Its original intent was for writing test cases,
but it has proven to be popular as an exchange format for RDF data.
N-Triples triples are a sequence of RDF terms representing the
subject,
predicate, and
object
of an RDF Triple.
These may be separated by white space (spaces, and/or tabs).
This sequence is terminated by a .
(optionally followed by white space and/or a comment),
and a new line (optional at the end of a document).
<http://one.example/subject1> <http://one.example/predicate1> <http://one.example/object1> . # comments here
# or on a line by themselves
_:subject1 <http://an.example/predicate1> "object1" .
_:subject2 <http://an.example/predicate2> "object2" .
N-Triples triples are also Turtle simple triples,
but Turtle includes other representations of RDF terms and
abbreviations of RDF Triples.
When parsed by a Turtle parser,
data in the N-Triples format will produce exactly the same triples as a parser for the N-Triples language.
The RDF graph represented by an N-Triples document contains
exactly each triple matching the N-Triples
triple production.
The simplest triple statement is a sequence of
(subject,
predicate, and
object) terms,
and terminated by ..
White space (spaces U+0020 or tabs U+0009) may surround terms,
except where significant as noted in the grammar.
Comments are treated as white space, and may be given after a #
that is not part of
another lexical token and continue to the end of the line.
IRIs may be written only as resolved IRIs.
IRIs are preceded by < and
followed by >,
and may contain numeric escape sequences (described below).
For example <http://example.org/#green-goblin>.
2.4 RDF Literals
Literals
are used to identify values such as strings, numbers, dates.
The representation of the lexical form consists of an
initial delimiter ",
a sequence of permitted characters or numeric escape sequence or string escape sequence,
and a final delimiter.
Literals may not contain the characters ",
LF, or
CR
except in their escaped forms.
In addition \
may not appear in any quoted literal except as part of an escape sequence
and a " character
can only be included in a quoted literal using an escape sequence.
The corresponding lexical form
is the characters between the delimiters, after processing any escape sequences.
If present, the LANG_DIR
terminal matches the language tag
and optionally the base direction.
The language tag
is preceded by an @,
and, if present, the base direction
is separated from the language tag
by --.
If there is no language tag, there may be a datatype IRI,
preceded by ^^.
If there is no datatype IRI and no language tag, then
it is a simple literal
and the datatype is http://www.w3.org/2001/XMLSchema#string.
<http://example.org/show/218> <http://www.w3.org/2000/01/rdf-schema#label> "That Seventies Show"^^<http://www.w3.org/2001/XMLSchema#string> . # literal with XML Schema string datatype
<http://example.org/show/218> <http://www.w3.org/2000/01/rdf-schema#label> "That Seventies Show" . # same as above
<http://example.org/show/218> <http://example.org/show/localName> "That Seventies Show"@en . # literal with a language tag
<http://example.org/show/218> <http://example.org/show/localName> "That Seventies Show"@en-ltr . # literal with a language tag and base direction
<http://example.org/show/218> <http://example.org/show/localName> "Cette Série des Années Septante"@fr-be . # literal outside of ASCII range with a region subtag
<http://example.org/#spiderman> <http://example.org/text> "This is a multi-line literal with many quotation marks (""""") and two apostrophes ('')." .
<http://en.wikipedia.org/wiki/Helium> <http://example.org/elements/atomicNumber> "2"^^<http://www.w3.org/2001/XMLSchema#integer> . # xsd:integer
<http://en.wikipedia.org/wiki/Helium> <http://example.org/elements/specificGravity> "1.663E-4"^^<http://www.w3.org/2001/XMLSchema#double> . # xsd:double
2.5 RDF Blank Nodes
As in N-Triples,
RDF blank nodes are expressed as _:
followed by a blank node label which is a series of name characters.
The characters in the label are built upon PN_CHARS_BASE,
liberalized as follows:
The characters _ and
the digit characters 0–9, inclusive
may appear anywhere in a blank node label.
The character . may appear anywhere except the first or last character.
The characters
-,
·,
‿,
⁀,
and
the combining diacritical marks (U+0300
to U+036F)
are permitted anywhere except the first character.
This section defines a canonical form of N-Triples which has
a completely specified layout.
The grammar for the language is unchanged.
While the N-Triples syntax allows choices for the representation and layout of RDF data,
the canonical form of N-Triples provides a unique syntactic representation of any triple.
Each code point
can be represented by only one of
UCHAR,
ECHAR,
or unencoded character,
where the relevant production allows for a choice in representation.
Each triple is represented entirely on a single line with specified white space.
Canonical N-Triples has the following additional constraints on layout:
White space MUST NOT be used except after
subject,
predicate, and
object,
any of which MUST be a single space.
Characters in the range from U+0000 to U+0007,
VT,
characters in the range from U+000E to U+001F,
DEL,
and characters not matching the Char production from [XML11]
MUST be represented by UCHAR
using a lowercase \u with 4 HEXes.
All characters not required to be represented by
ECHAR or
UCHARMUST be represented by their native [UNICODE] representation.
As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.
The key words MAY, MUST, MUST NOT, and SHOULD in this document
are to be interpreted as described in
BCP 14
[RFC2119] [RFC8174]
when, and only when, they appear in all capitals, as shown here.
This specification defines conformance criteria for:
A conforming N-Triples parser is a system capable of
reading N-Triples documents on behalf of an application.
It makes the serialized RDF graph,
as defined in 6. Parsing,
available to the application, usually through some form of API.
The IRI that identifies the N-Triples language is: http://www.w3.org/ns/formats/N-Triples
4.1 Media Type and Content Encoding
The media type of N-Triples is application/n-triples.
The content encoding of N-Triples is always UTF-8.
See N-Triples Media Type for the media type
registration form.
4.1.1 Other Media Types
N-Triples has been historically provided with other media types.
N-Triples may also be provided as text/plain.
When used in this way N-Triples MUST use the escaped form of any character outside US-ASCII.
As N-Triples is a subset of Turtle an N-Triples documentMAY also be provided as text/turtle.
In both of these cases the document is not an N-Triples document as an N-Triples document is only provided as application/n-triples.
A blank line, consisting of only white space and/or a comment,
may appear wherever a triple production is allowed,
and are treated as white space.
Note
N-Triples allows only horizontal white space (spaces or tabs)
as compared to Turtle [RDF12-TURTLE] which also treats
LF
and CR
as white space.
5.2 Comments
Comments in N-Triples start at #
outside an IRIREF or STRING_LITERAL_QUOTE,
and continue to the end of line
— marked by character
CR or
LF —
or to the end of file, if there is no end of line after the comment marker.
Comments are treated as white space.
5.3 Grammar
The EBNF used
here is defined in XML 1.0 [EBNF-NOTATION].
Escape sequence rules are the same as Turtle [RDF12-TURTLE].
However, as only the STRING_LITERAL_QUOTE
production is allowed new lines in literals MUST be escaped.
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+0008
BS
Backspace
U+0009
HT
Horizontal tab
U+000A
LF
Line feed
U+000B
VT
Vertical tab
U+000C
FF
Form feed
U+000D
CR
Carriage return
U+0022
"
Quotation mark
U+0023
#
Number sign
U+002D
-
Hyphen
U+002E
.
Full stop
U+0030
0
Digit zero
U+0039
9
Digit nine
U+003B
:
Colon
U+003C
<
Less-than sign
U+003E
>
Greater-than sign
U+0040
@
At sign
U+0041
A
Latin capital letter A
U+0046
F
Latin capital letter F
U+005C
\
Backslash
U+005F
_
Underscore
U+0061
a
Latin small letter A
U+007A
F
Latin small letter Z
U+007F
DEL
Delete
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
<<(
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
The N-Triples 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.
B. Security Considerations
This section is non-normative.
The STRING_LITERAL_QUOTE
production allows 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.
N-Triples 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 N-Triples 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 N-Triples documents.
Security/privacy protocols must be imposed which reflect the sensitivity of the embedded information.
N-Triples can express data which is presented to the user, such as RDF Schema labels.
Applications rendering strings retrieved from untrusted N-Triples 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 "о" may appear similar to a Latin "o").
A character followed by combining characters may have the same visual representation
as another character (for example, LATIN SMALL LETTER "E" followed by COMBINING ACUTE
ACCENT has the same visual representation as LATIN SMALL LETTER "E" WITH ACUTE).
Any person or application that is writing or interpreting data in N-Triples
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.
C. N-Triples Internet Media Type, File Extension and Macintosh File Type
The Internet Media Type (formerly known as MIME Type) for N-Triples is "application/n-triples".
It is recommended that N-Triples files have the extension ".nt" (all lowercase) on all platforms.
It is recommended that N-Triples files stored on Macintosh HFS file systems be given a file type of "TEXT".
This information that follows will be submitted to the IESG for review, approval, and registration with IANA.
Type name:
application
Subtype name:
n-triples
Required parameters:
None
Optional parameters:
None
Encoding considerations:
The syntax of N-Triples is expressed over code points in Unicode [UNICODE]. The encoding is always UTF-8 [UTF-8].
Unicode code points may also be expressed using an \uXXXX (U+0 to U+FFFF) or \UXXXXXXXX syntax (for U+10000 onwards) where X is a hexadecimal digit [0-9A-F]
No widely deployed applications are known to use this media type. It may be used by some web services and clients consuming their data.
Additional information:
Magic number(s):
None.
File extension(s):
".nt"
Macintosh file type code(s):
"TEXT"
Person & email address to contact for further information:
Eric Prud'hommeaux <eric@w3.org>
Intended usage:
COMMON
Restrictions on usage:
None
Author/Change controller:
The N-Triples specification is the product of the RDF WG. The W3C reserves change control over this specifications.
D. Acknowledgments
This section is non-normative.
D.1 Acknowledgments for RDF 1.1
This section is non-normative.
The editor of the RDF 1.1 edition acknowledges valuable contributions from Gregg Kellogg, Eric Prud'hommeaux, Dave Beckett, David Robillard, Gregory Williams, Pat Hayes, Richard Cyganiak, Henry S. Thompson,
Peter Ansell, Evan Patton and David Booth.
This specification is a product of extended deliberations by the
members of the RDF Working Group.
It draws upon the earlier specification in [RDF-TESTCASES], edited by Dave Beckett.
D.2 Acknowledgments for RDF 1.2
This section is non-normative.
The editors of the RDF 1.2 edition acknowledge valuable contributions from Andy Seaborne.
In addition to the editors, the following people have contributed to this specification:
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.
Editor's note
Recognize members of the Task Force? Not an easy to find list of contributors.
E. Changes between RDF 1.1 and RDF 1.2
This section is non-normative.
Better align the use of white space and comments with [RDF12-TURTLE].
Removed language about white space use between terminals that would otherwise
be (mis-)recognized, is this can't happen in N-Triples.
Clarify the use of blank lines, including those composed of white space
and/or comments.
Comments can appear at the end of a triple before the newline as
was already evident from Example 1.