Do
not
attempt
to
implement
this
version
of
the
specification.
Do
not
reference
this
version
as
authoritative
in
any
way.
Instead,
see
https://w3c.github.io/rdf-n-quads/spec/
for
the
Editor's
draft.
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
standards
and
drafts
index
.
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
an
Editor's
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
a
work
in
progress.
Future
updates
to
this
upcoming
Recommendation
may
incorporate
new
features
.
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
,
and/or
tabs
).
This
sequence
is
terminated
by
a
period
(
.
),
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> .
This
specification
extends
the
original
N-Quads
syntax,
as
defined
in
RDF
1.1
N-Quads
[
N-QUADS
],
to
support
the
new
features
introduced
by
RDF
1.2
Concepts
and
Abstract
Data
Model
[
RDF12-CONCEPTS
].
This
extension
is
fully
backward
compatible:
any
document
complying
with
the
old
version
complies
with
the
new
version,
and
parses
to
the
same
graph.
Furthermore,
any
document
complying
with
the
new
version
and
containing
only
RDF
1.1
features
is
also
compliant
with
the
older
version
(with
the
exception
of
the
VERSION
directive;
see
2.2
Version
Announcement
).
Finally,
none
of
the
new
syntactic
constructs
are
valid
in
the
old
syntax.
This
means
that
any
N-Quads
document
using
RDF
1.2
features
does
not
comply
with
the
previous
version
of
this
specification
and
cannot
be
interpreted
as
a
different
graph
under
it.
The
N-Quads
language
has
evolved
since
its
origin,
and
RDF
1.2
adds
new
syntax.
RDF
1.2
N-Quads
introduces
the
VERSION
directive
along
with
an
optional
version
Media
Type
parameter
.
When
respectively
serializing
and
parsing
N-Quads
with
new
features
such
as
initial
text
directions
or
triple
terms
,
authors
and
parsers
can
announce
and
detect
the
use
of
the
new
syntax
forms
using
these
directives;
similarly,
HTTP
clients
and
servers
can
use
the
version
Media
Type
parameter
.
As
with
N-Triples,
the
version
declaration
is
case-sensitive.
As
in
N-Triples,
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.5
RDF
Literals
As
in
N-Triples,
literals
are
used
to
identify
values
such
as
strings,
numbers,
dates.
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.
Informally,
the
digit
characters
first
character
after
0
_:
–
is
either
a
character
matched
by
9
PN_CHARS_U
may
appear
anywhere
in
or
a
blank
node
label.
The
character
digit.
Any
following
characters,
if
present,
are
matched
by
.
PN_CHARS
may
appear
anywhere
except
the
first
or
last
character.
The
characters
by
-
.
,
except
that
·
.
,
is
not
permitted
as
the
last
character.
‿
,
Note
⁀
,
and
This
paragraph
is
explanatory;
the
combining
diacritical
marks
(
U+0300
to
U+036F
)
are
permitted
anywhere
except
normative
definition
is
the
first
character.
grammar
production
BLANK_NODE_LABEL
.
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
.
A
Canonical
N-Quads
document
MUST
NOT
include
a
VERSION
directive.
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
HEX
es.
All
characters
not
required
to
be
represented
by
ECHAR
or
UCHAR
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
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-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.
Comments
in
N-Quads
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.
A
text
version
of
this
grammar
is
available
here
.
5.4
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.
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
z
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
greater-than
sign
characters,
each
having
the
code
point
U+003E
^^
two
concatenated
circumflex
accent
characters,
each
having
the
code
point
U+005E
Map[string
->
blank
node
]
bnodeLabels
—
A
mapping
from
string
to
blank
node.
xsd:string
curVersion
–
The
RDF
version
used
for
parsing
the
document
into
Quads
.
If
specified
as
part
of
a
Media
Type
,
the
default
value
for
curVersion
is
taken
from
the
version
parameter.
Acceptable
values
for
version
are
defined
in
2.1
Version
Labels
in
[
RDF12-CONCEPTS
].
The
version
announcement
is
only
a
hint;
this
specification
does
not
mandate
any
parser
behavior
based
on
curVersion
,
but
a
parser
MAY
signal
an
error
or
a
warning
when
it
encounters
a
feature
that
does
not
match
the
value
of
curVersion
.
The
characters
between
<
and
>
are
taken,
with
escape
sequences
unescaped,
to
form
the
IRI.
The
resulting
IRI
MUST
comply
with
the
syntactic
restrictions
of
generic
IRI
syntax,
and
SHOULD
conform
to
section
3.3
of
[
RFC3986
]
and
comply
with
any
narrower
restrictions
imposed
by
the
corresponding
IRI
scheme
specification.
As
processors
which
detect
errors
on
input
can
result
in
datasets
which
contain
fewer
triples
than
are
described
in
the
input
(including
no
triples
whatsoever),
consumers
should
consider
information
of
any
errors
signaled
when
using
the
resulting
dataset,
which
may
be
incomplete
and/or
include
ill-typed
or
ill-formed
terms.
The
N-Quads
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-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.
Internet
Media
Type,
File
Extension
and
Macintosh
File
Type
The
Internet
Media
Type
(formerly
known
as
MIME
Type)
for
N-Quads
is
"application/n-quads".
The
information
that
follows
has
been
submitted
to
the
Internet
Engineering
Steering
Group
(IESG)
for
review,
approval,
and
registration
with
IANA.
Type
name:
application
Subtype
name:
n-quads
Required
parameters:
None
Optional
parameters:
version
—
this
parameter
is
optional
but
SHOULD
be
present
when
using
RDF
1.2-specific
features.
If
present,
acceptable
values
of
version
are
defined
in
2.1
Version
Labels
in
[
RDF12-CONCEPTS
].
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+0000
to
U+FFFF
)
or
\UXXXXXXXX
syntax
(for
code
points
up
to
U+10FFFF
)
where
X
is
a
hexadecimal
digit
[0-9A-F]
N-Quads
is
used
widely
for
representing
RDF
data.
There
are
implementations
available
in
most
common
programming
languages.
Additional
information:
Magic
number(s):
None.
File
extension(s):
.nq
Macintosh
file
type
code(s):
TEXT
Person
&
email
address
to
contact
for
further
information:
RDF
&
SPARQL
Working
Group
<public-rdf-star-wg@w3.org>
Intended
usage:
Common
Restrictions
on
usage:
None
Author(s):
The
N-Quads
specification
is
the
product
of
the
RDF
&
SPARQL
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:
Andy
Seaborne,
Denis
Ah-Kang,
Jim
Smart,
Niklas
Lindström,
Peter
F.
Patel-Schneider,
Pierre-Antoine
Champin,
and
Ted
Thibodeau
Jr
Members
of
the
RDF
&
SPARQL
Working
Group
Group
included
Vladimir
Alexiev,
James
Anderson,
Amin
Anjomshoaa,
Julián
Arenas-Guerrero,
Dörthe
Arndt,
Bilal
Ben
Mahria,
Erich
Bremer,
Dan
Brickley,
Kurt
Cagle,
Sarven
Capadisli,
Rémi
Ceres,
Pierre-Antoine
Champin,
David
Chaves-Fraga,
Souripriya
Das,
Daniil
Dobriy,
Enrico
Franconi,
Jeffrey
Phillips
Freeman,
Fabien
Gandon,
Benjamin
Goering,
Damien
Graux,
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,
Alan
Snyder,
Stuart
Sutton,
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.
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
.