RDF 1.2 N-Quads

A line-based syntax for RDF datasets

W3C Working Draft

More details about this document
This version:
Latest published version:
Latest editor's draft:
Commit history
Test suite:
Latest Recommendation:
Gregg Kellogg
Dominik Tomaszuk
Former editor:
Gavin Carothers
GitHub w3c/rdf-n-quads (pull requests, new issue, open issues)
public-rdf-star-wg@w3.org with subject line [rdf12-n-quads] … message topic … (archives)


N-Quads is a line-based, plain text format for encoding an RDF dataset.

RDF 1.2 N-Quads introduces triple terms 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. RDF 1.2 N-Quads also adds support for directional language-tagged strings.

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.

This document was published by the RDF-star Working Group as a Working Draft using the Recommendation track.

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 is governed by the 03 November 2023 W3C Process Document.

1. Introduction

This section is non-normative.

This document defines N-Quads, a concrete syntax for RDF [RDF12-CONCEPTS], and an extension of N-Triples [RDF12-N-TRIPLES]. N-Quads is an easy to parse, line-based, concrete syntax for RDF Datasets [RDF12-CONCEPTS].

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

Example 1: Use of comments in N-Quads

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

The RDF dataset represented by an N-Quads document contains exactly each quad matching the N-Quads statement production.

2. N-Quads Language

This section is non-normative.

An N-Quads document allows writing down an RDF dataset in a textual form. An RDF dataset is made up of simple statements consisting of a subject, predicate, object, an optional graph name and optional blank lines. Comments may be given after a # that is not part of another lexical token and continue to the end of the line.

2.1 Simple Statements

A simple statement extends the definition of simple triple in [RDF12-N-TRIPLES] with an optional named graph.

The simplest statement is a sequence of (subject, predicate, object) terms forming an RDF triple and an optional graph name (a blank node identifier or IRI) labeling what named graph in a dataset the triple belongs to. White space (spaces, and/or tabs) 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.

The graph name can be omitted, in which case the triples are considered part of the default graph of the RDF dataset.

Example 2: Simple Statement

<http://example.org/#spiderman> <http://www.perceive.net/schemas/relationship/enemyOf> <http://example.org/#green-goblin> <http://example.org/graphs/spiderman> .

2.2 Triple Terms

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

A triple term is represented as a tripleTerm with subject, predicate, and object preceded by <<, and followed by >>. Note that triple terms may be nested.

Example 3: Triple Term

_:e38                                                <ex:familyName>                  "Smith" .
<< _:e38 <http://example.com/jobTitle> "Designer" >> <http://example.com/accordingTo> _:e22 .

2.3 IRIs

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.4 RDF Literals

As in N-Triples, literals are used to identify values such as strings, numbers, dates.

Literals (Grammar production Literal) have a lexical form followed by either a language tag (possibly including base direction), a datatype IRI, or neither.

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.

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:

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.

Example 4: Blank nodes in N-Quads

_:alice <http://xmlns.com/foaf/0.1/knows> _:bob .
_:bob   <http://xmlns.com/foaf/0.1/knows> _:alice .

3. A Canonical form of N-Quads

This section defines a canonical form of N-Quads which has a completely specified layout. The grammar for the language is unchanged.

Canonical N-Quads extends Canonical N-Triples in [RDF12-N-TRIPLES] to include graphLabel.

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:

4. Conformance

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


N-Quads documents do not provide a way of serializing empty graphs that may be part of an RDF dataset.

A conforming Canonical N-Quads document is an N-Quads document that follows the additional constraints of Canonical N-Quads.

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.

4.1.1 Other Media Types

The original specification, N-Quads: Extending N-Triples with Context, proposed the use of media type text/x-nquads with an encoding using 7-bit US-ASCII.

5. N-Quads Grammar

An N-Quads document is an RDF string encoded in UTF-8 [RFC3629].

5.1 White Space

White space (spaces, and/or tabs) is allowed outside of terminals. Rule names in capitals below indicate where white space is significant.

White space is significant in the production STRING_LITERAL_QUOTE.

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.


As with, N-Triples [RDF12-N-TRIPLES], N-Quads allows only horizontal white space (spaces or tabs).


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.

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.

[1] nquadsDoc ::= statement? (EOL statement)* EOL?
[2] statement ::= subject predicate object graphLabel? '.'
[4] predicate ::= IRIREF
[5] object ::= IRIREF | BLANK_NODE_LABEL | literal | tripleTerm
[6] graphLabel ::= IRIREF | BLANK_NODE_LABEL
[7] literal ::= STRING_LITERAL_QUOTE (('^^' IRIREF) | LANG_DIR)?
[8] tripleTerm ::= '<<(' subject predicate object ')>>'

Productions for terminals

[10] IRIREF ::= '<' ([^#x00-#x20<>"{}|^`\] | UCHAR)* '>'
[11] BLANK_NODE_LABEL ::= '_:' (PN_CHARS_U | [0-9]) ((PN_CHARS | '.')* PN_CHARS)?
[12] LANG_DIR ::= '@' [a-zA-Z]+ ('-' [a-zA-Z0-9]+)* ('--' [a-zA-Z]+)?
[13] STRING_LITERAL_QUOTE ::= '"' ([^#x22#x5C#x0A#x0D] | ECHAR | UCHAR)* '"'
[15] ECHAR ::= '\' [tbnrf"']
[16] PN_CHARS_BASE ::= [A-Z]
| [a-z]
| [#xC0-#xD6]
| [#xD8-#xF6]
| [#xF8-#x02FF]
| [#x0370-#x037D]
| [#x037F-#x1FFF]
| [#x200C-#x200D]
| [#x2070-#x218F]
| [#x2C00-#x2FEF]
| [#x3001-#xD7FF]
| [#xF900-#xFDCF]
| [#xFDF0-#xFFFD]
| [#x00010000-#x000EFFFF]
[17] PN_CHARS_U ::= PN_CHARS_BASE | '_'
[18] PN_CHARS ::= PN_CHARS_U | '-' | [0-9] | #xB7 | [#x0300-#x036F] | [#x203F-#x2040]
[19] HEX ::= [0-9] | [A-F] | [a-f]
[20] EOL ::= [#x0D#x0A]+

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.

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:

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 circumflex accent characters, each having the code point U+005E
_ followed by :
two concatenated - characters

6. Parsing

Parsing N-Quads requires a state of one item:

6.1 RDF Term Constructors

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

BLANK_NODE_LABEL blank node The string after _:, is a key in bnodeLabels. If there is no corresponding blank node in the map, one is allocated.
IRIREF IRI The characters between < and > are taken, with escape sequences unescaped, to form the IRI.
LANG_DIR language tag The characters following the @ form the language tag and optionally the base direction, if the matched characters include --.
STRING_LITERAL_QUOTE RDF lexical form The characters between the outermost quotation marks (") are taken, with escape sequences unescaped, to form the string of the lexical form.
literal literal The literal has a lexical form of the first rule argument, STRING_LITERAL_QUOTE, and either a language tag with optional base direction from LANG_DIR or a datatype IRI of iri, depending on which rule matched the input. If the LANG_DIR rule 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 LANG_DIR nor datatype IRI match, the literal has a datatype of xsd:string.
tripleTerm triple term The triple term is composed of the terms constructed from the subject, predicate, and object productions.

6.2 RDF Dataset Construction

An N-Quads document defines an RDF dataset composed of RDF graphs composed of a set of RDF triples. The statement production produces a triple defined by the terms constructed for subject, predicate, and object. This RDF triple is added to the graph labeled by the production graphLabel, if no graphLabel is present the triple is added to the RDF dataset's default graph.

A. Privacy Considerations

This section is non-normative.

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.

N-Quads uses IRIs as term identifiers. Applications interpreting data expressed in N-Quads SHOULD address the security issues of Internationalized Resource Identifiers (IRIs) [RFC3987] Section 8, as well as Uniform Resource Identifier (URI): Generic Syntax [RFC3986] Section 7.

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

Eric Prud'hommeaux
See also:
How to Register a Media Type for a W3C Specification
Internet Media Type registration, consistency of use
TAG Finding 3 June 2002 (Revised 4 September 2002)

The Internet Media Type (formerly known as 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:
Subtype name:
Required parameters:
Optional parameters:
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]
Security considerations:
See B. Security Considerations.
Interoperability considerations:
There are no known interoperability issues.
Published specification:
This specification.
Applications which use this media type:
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):
File extension(s):
Macintosh file type code(s):
Person & email address to contact for further information:
Eric Prud'hommeaux <eric@w3.org>
Intended usage:
Restrictions on usage:
Author/Change controller:
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: Andy Seaborne, 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.

F. Index

This section is non-normative.

F.1 Terms defined by this specification

F.2 Terms defined by reference

G. Issue summary

This section is non-normative.

There are no issues listed in this specification.

H. References

H.1 Normative references

EBNF Notation. Tim Bray; Jean Paoli; Michael Sperberg-McQueen; Eve Maler; François Yergeau et al. W3C. W3C Recommendation. URL: https://www.w3.org/TR/xml/#sec-notation
Internationalization Glossary. Richard Ishida; Addison Phillips. W3C. 21 March 2024. W3C Working Group Note. URL: https://www.w3.org/TR/i18n-glossary/
RDF 1.2 Concepts and Abstract Syntax. Olaf Hartig; Pierre-Antoine Champin; Gregg Kellogg; Andy Seaborne. W3C. 16 April 2024. W3C Working Draft. URL: https://www.w3.org/TR/rdf12-concepts/
RDF 1.2 N-Triples. Gregg Kellogg; Dominik Tomaszuk. W3C. 21 March 2024. W3C Working Draft. URL: https://www.w3.org/TR/rdf12-n-triples/
RDF 1.2 Turtle. Gregg Kellogg; Dominik Tomaszuk. W3C. 8 February 2024. W3C Working Draft. URL: https://www.w3.org/TR/rdf12-turtle/
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119
UTF-8, a transformation format of ISO 10646. F. Yergeau. IETF. November 2003. Internet Standard. URL: https://www.rfc-editor.org/rfc/rfc3629
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc8174
The Unicode Standard. Unicode Consortium. URL: https://www.unicode.org/versions/latest/
Extensible Markup Language (XML) 1.1 (Second Edition). Tim Bray; Jean Paoli; Michael Sperberg-McQueen; Eve Maler; François Yergeau; John Cowan et al. W3C. 16 August 2006. W3C Recommendation. URL: https://www.w3.org/TR/xml11/

H.2 Informative references

What’s New in RDF 1.2. David Wood. W3C. DNOTE. URL: https://w3c.github.io/rdf-new/spec/
RDF 1.2 Primer. Guus Schreiber; Yves Raimond. W3C. DNOTE. URL: https://w3c.github.io/rdf-primer/spec/
RDF 1.2 Schema. Dominik Tomaszuk; Timothée Haudebourg. W3C. 28 September 2023. W3C Working Draft. URL: https://www.w3.org/TR/rdf12-schema/
RDF 1.2 Semantics. Peter Patel-Schneider; Dörthe Arndt; Timothée Haudebourg. W3C. 25 January 2024. W3C Working Draft. URL: https://www.w3.org/TR/rdf12-semantics/
RDF 1.2 TriG. Gregg Kellogg; Dominik Tomaszuk. W3C. 4 November 2023. W3C Working Draft. URL: https://www.w3.org/TR/rdf12-trig/
RDF 1.2 XML Syntax. Gregg Kellogg. W3C. 21 September 2023. W3C Working Draft. URL: https://www.w3.org/TR/rdf12-xml/
XML Media Types. M. Murata; S. St. Laurent; D. Kohn. IETF. January 2001. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc3023
Uniform Resource Identifier (URI): Generic Syntax. T. Berners-Lee; R. Fielding; L. Masinter. IETF. January 2005. Internet Standard. URL: https://www.rfc-editor.org/rfc/rfc3986
Internationalized Resource Identifiers (IRIs). M. Duerst; M. Suignard. IETF. January 2005. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc3987
SPARQL 1.2 Concepts. The W3C RDF-star Working Group. W3C. W3C Working Draft. URL: https://w3c.github.io/sparql-concepts/spec/
SPARQL 1.2 Entailment Regimes. Peter Patel-Schneider. W3C. 15 June 2023. W3C Working Draft. URL: https://www.w3.org/TR/sparql12-entailment/
SPARQL 1.2 Federated Query. Ruben Taelman; Gregory Williams. W3C. 21 March 2024. W3C Working Draft. URL: https://www.w3.org/TR/sparql12-federated-query/
SPARQL 1.2 Graph Store Protocol. Andy Seaborne; Thomas Pellissier Tanon. W3C. 16 June 2023. W3C Working Draft. URL: https://www.w3.org/TR/sparql12-graph-store-protocol/
What’s New in SPARQL 1.2. The W3C RDF-star Working Group. W3C. W3C Working Draft. URL: https://w3c.github.io/sparql-new/spec/
SPARQL 1.2 Protocol. Andy Seaborne; Ruben Taelman; Gregory Williams; Thomas Pellissier Tanon. W3C. 14 December 2023. W3C Working Draft. URL: https://www.w3.org/TR/sparql12-protocol/
SPARQL 1.2 Query Language. Olaf Hartig; Andy Seaborne; Ruben Taelman; Gregory Williams; Thomas Pellissier Tanon. W3C. 21 March 2024. W3C Working Draft. URL: https://www.w3.org/TR/sparql12-query/
SPARQL 1.2 Query Results CSV and TSV Formats. Ruben Taelman; Gregory Williams; Thomas Pellissier Tanon. W3C. 10 November 2023. W3C Working Draft. URL: https://www.w3.org/TR/sparql12-results-csv-tsv/
SPARQL 1.2 Query Results JSON Format. Andy Seaborne; Ruben Taelman; Gregory Williams; Thomas Pellissier Tanon. W3C. 8 February 2024. W3C Working Draft. URL: https://www.w3.org/TR/sparql12-results-json/
SPARQL 1.2 Query Results XML Format. Ruben Taelman; Dominik Tomaszuk; Thomas Pellissier Tanon. W3C. 30 November 2023. W3C Working Draft. URL: https://www.w3.org/TR/sparql12-results-xml/
SPARQL 1.2 Service Description. Ruben Taelman; Gregory Williams. W3C. 14 December 2023. W3C Working Draft. URL: https://www.w3.org/TR/sparql12-service-description/
SPARQL 1.2 Update. Ruben Taelman; Andy Seaborne; Thomas Pellissier Tanon. W3C. 28 September 2023. W3C Working Draft. URL: https://www.w3.org/TR/sparql12-update/
Unicode Security Considerations. Mark Davis; Michel Suignard. Unicode Consortium. 19 September 2014. Unicode Technical Report #36. URL: https://www.unicode.org/reports/tr36/tr36-15.html