N-Quads is a line-based, plain text format for encoding an RDF dataset.
RDF 1.2 N-Quads introduces quoted triples
as a fourth kind of RDF term
which can be used as the
subject or
object of another
triple,
making it possible to make statements about other statements.
Status of This Document
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-Quads format is a line-based RDF syntax,
which is an extension of N-Triples [RDF12-N-TRIPLES].
The main distinction is that N-Quads allows the encoding of multiple graphs
in a single document representing an RDF Dataset.
Publication as a First Public 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.
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.
As with N-Triples, an N-Quads document contains no parsing directives.
N-Quads statements are a sequence of RDF terms representing the
subject,
predicate, and
object
of an RDF Triple
and an optional graph name
identifying a named graph
associated with the triple within an RDF dataset,
also known as a quad.
These may be separated by white space (spaces #x20 or tabs #x9).
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> <http://example.org/graph3> . # comments here
# or on a line by themselves
_:subject1 <http://an.example/predicate1> "object1" <http://example.org/graph1> .
_:subject2 <http://an.example/predicate2> "object2" <http://example.org/graph5> .
As in N-Triples, IRIs may be written only as absolute IRIs.
IRIs are enclosed in '<' and '>' and may contain numeric escape sequences (described below).
For example <http://example.org/#green-goblin>.
2.4 RDF Literals
As in N-Triples,
literals are used to identify values such as strings, numbers, dates.
The representation of the lexical form consists of an
initial delimiter " (U+0022),
a sequence of permitted characters or numeric escape sequence or string escape sequence,
and a final delimiter.
Literals may not contain the characters ",
LF (U+000A), or
CR (U+000D)
except in their escaped forms.
In addition '\' (U+005C)
may not appear in any quoted literal except as part of an escape sequence
and a " (U+0022) character
can only be included in a quote literal using an escape sequence.
The corresponding RDF lexical form
is the characters between the delimiters, after processing any escape sequences.
If present, the language tag
is preceded by a '@' (U+0040).
If there is no language tag, there may be a datatype IRI,
preceded by '^^' (U+005EU+005E).
If there is no datatype IRI and no language tag
it is a simple literal
and the datatype is http://www.w3.org/2001/XMLSchema#string.
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 [0-9] may appear anywhere in a blank node label.
The character . may appear anywhere except the first or last character.
The characters -, U+00B7, U+0300 to U+036F and U+203F to U+2040 are permitted anywhere except the first character.
A fresh RDF blank node is allocated for each unique blank node label in a document.
Repeated use of the same blank node label identifies the same RDF blank node.
While the N-Quads syntax allows choices for the representation and layout of RDF data,
the canonical form of N-Quads provides a unique syntactic representation of any quad.
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 quad is represented entirely on a single line with specified white space.
Canonical N-Quads has the following additional constraints on layout:
White space MUST NOT be used except after
subject,
predicate,
object,
and graphLabel,
any of which MUST be a single space (U+0020).
Literals with the
datatype http://www.w3.org/2001/XMLSchema#stringMUST NOT use the datatype IRI part of the literal,
and are represented using only STRING_LITERAL_QUOTE.
Within STRING_LITERAL_QUOTE,
the characters
U+0008 (BS),
U+0009 (HT),
U+000A (LF),
U+000C (FF),
U+000D (CR),
U+0022 ("), and
U+005C (\)
MUST be encoded using ECHAR.
Characters in the range from U+0000 to U+001F
and U+007F (DEL)
that are not represented using ECHARMUST be represented by UCHAR.
All other characters MUST 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 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-Quads document is a Unicode string that conforms to the grammar and additional constraints defined in 5. N-Quads Grammar,
starting with the nquadsDoc production.
An N-Quads document serializes an RDF dataset.
Note
N-Quads documents do not provide a way of serializing empty graphs that may be part of an RDF dataset.
A conforming N-Quads parser is a system capable of
reading N-Quads documents on behalf of an application.
It makes the serialized RDF dataset,
as defined in 6. Parsing,
available to the application, usually through some form of API.
The IRI that identifies the N-Quads language is: http://www.w3.org/ns/formats/N-Quads
4.1 Media Type and Content Encoding
The media type of N-Quads is application/n-quads.
The content encoding of N-Quads is always UTF-8.
See N-Quads Media Type for the media type
registration form.
A blank line, consisting of only white space and/or a comment,
may appear wherever a statement production is allowed,
and is treated as white space.
Note
As with, N-Triples [RDF12-N-TRIPLES],
N-Quads allows only horizontal white space (tab U+0009 or space U+0020).
5.2 Comments
Comments in N-Quads start at '#'
outside an IRIREF or STRING_LITERAL_QUOTE,
and continue to the end of line
(marked by characters
CR (U+000D or
LF (U+000A))
or 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 N-Triples [RDF12-N-TRIPLES] and Turtle [RDF12-TURTLE].
However, as only the STRING_LITERAL_QUOTE
production is allowed new lines in literals MUST be escaped.
The literal has a lexical form of the first rule argument,
STRING_LITERAL_QUOTE,
and either a language tag of LANGTAG
or a datatype IRI of iri,
depending on which rule matched the input.
If the LANGTAG rule matched,
the datatype is rdf:langString
and the language tag is LANGTAG.
If neither a language tag nor a datatype IRI is provided,
the literal has a datatype of xsd:string.
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-Quads 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-Quads 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-Quads documents.
Security/privacy protocols must be imposed which reflect the sensitivity of the embedded information.
N-Quads can express data which is presented to the user, such as RDF Schema labels.
Applications rendering strings retrieved from untrusted N-Quads 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-Quads
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-Quads Internet Media Type, File Extension and Macintosh File Type
The Internet Media Type / MIME Type for N-Quads is "application/n-quads".
It is recommended that N-Quads files have the extension ".nq" (all lowercase) on all platforms.
It is recommended that N-Quads 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-quads
Required parameters:
None
Optional parameters:
None
Encoding considerations:
The syntax of N-Quads 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]
The N-Quads 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, Andy Seaborne, Eric
Prud'hommeaux, Dave Beckett, David Robillard, Gregory Williams,
Antoine Zimmermann, Sandro Hawke, Richard Cyganiak, Pat Hayes,
Henry S. Thompson, Bob Ferris, Henry Story, Andreas Harth, Lee
Feigenbaum, Peter Ansell, Evan Patton and David Booth.
This specification is a product of extensive deliberations by the
members of the RDF Working Group chaired by Guus Schreiber and David Wood.
It draws upon the earlier specification in N-Quads: Extending N-Triples with Context,
edited by Richard Cyganiak, Andreas Harth, and Aidan Hogan.
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:
Pierre-Antoine Champin
Members of the RDF-star Working Group Group included Adrian Gschwend, Andy Seaborne, Antoine Zimmermann, Dan Brickley, David Chaves-Fraga, Dominik Tomaszuk, Dörthe Arndt, Enrico Franconi, Fabien Gandon, Gregg Kellogg, Gregory Williams, Jesse Wright, Julián Arenas-Guerrero, Olaf Hartig, Ora Lassila, Pasquale Lisena, Peter Patel-Schneider, Pierre-Antoine Champin, Raphaël Troncy, Ruben Taelman, Rémi Ceres, Sarven Capadisli, Souripriya Das, Ted Thibodeau, and Timothée Haudebourg.
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.
N-Quads is now described as an extension of N-Triples [RDF12-N-TRIPLES].
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.
Updated the PN_CHARS_U
grammar production to be consistent with Turtle.
Formerly, PN_CHARS_U
included ":" in N-Triples and N-Quads, but not in Turtle nor TriG.
PN_CHARS_U is a component
of BLANK_NODE_LABEL.