RDF 1.2 N-Quads

RDFデータセットのための行ベース構文

W3C作業草案

この文書の詳細
このバージョン:
https://www.w3.org/TR/2026/WD-rdf12-n-quads-20260612/
最新公開バージョン:
https://www.w3.org/TR/rdf12-n-quads/
最新編集者草案:
https://w3c.github.io/rdf-n-quads/spec/
履歴:
https://www.w3.org/standards/history/rdf12-n-quads/
コミット履歴
テストスイート:
https://w3c.github.io/rdf-tests/rdf/rdf12/rdf-n-quads/
最新の勧告:
https://www.w3.org/TR/n-quads
編集者:
Gregg Kellogg (2025年9月6日まで), 追悼
Dominik Tomaszuk
元編集者:
Gavin Carothers (RDF 1.1)
フィードバック:
GitHub w3c/rdf-n-quads (プルリクエスト, 新規イシュー, 未解決のイシュー)
public-rdf-star-wg@w3.org 宛て、件名行は[rdf12-n-quads] … メッセージのトピック … (アーカイブ)

Copyright © 2012-2026 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.

概要

N-Quadsは、RDF データセットをエンコードするための行ベースのプレーンテキスト形式です。

RDF 1.2 N-Quadsは、トリプル項を RDF項の第4の種類として導入します。 これは別の トリプルの オブジェクト として使用でき、 他の文についての文を作成できるようにします。 RDF 1.2 N-Quadsは、 方向付き言語タグ文字列のサポートも追加します。

この文書のステータス

このセクションは、公開時点における この文書のステータスを説明します。現在のW3C 公開物の一覧およびこの技術報告書の最新版は、 W3C標準および草案 インデックスで確認できます。

この文書はRDF 1.2文書スイートの一部です。 N-Quads形式は行ベースのRDF構文であり、 N-Triples [RDF12-N-TRIPLES]の拡張です。 主な違いは、N-Quadsでは RDFデータセットを表す単一の文書内で、 複数のグラフをエンコードできることです。

この文書は、RDF & SPARQLワーキング グループによって、 勧告 トラックを使用した 作業草案として公開されました。

作業草案としての公開は、 W3Cおよびその会員による承認を意味するものではありません。

これは草案文書であり、いつでも他の文書によって更新、置換、または廃止される可能性があります。 この文書を作業中のもの以外として引用することは不適切です。 今後、この将来の勧告への更新で 新機能が組み込まれる可能性があります。

この文書は、 W3C 特許 ポリシーの下で運営されるグループによって作成されました。 W3Cは、 グループの成果物に関連して行われた 特許開示の公開一覧を 維持しています。そのページには、 特許を開示するための手順も含まれています。 必須請求項を含むとその個人が考える特許について 実際の知識を有する個人は、 必須請求項 に関する情報を、 W3C特許ポリシーのセクション6に従って開示しなければなりません。

この文書は、 2025年8月18日のW3Cプロセス文書に準拠します。

1. はじめに

このセクションは非規範的です。

この文書は、RDF [RDF12-CONCEPTS]の具体的な構文であり、 N-Triples [RDF12-N-TRIPLES]の拡張である N-Quadsを定義します。 N-Quadsは、解析しやすい行ベースの RDF データセット [RDF12-CONCEPTS]のための 具体的な構文です。

N-Triplesと同様に、N-Quads文書は、内容のRDFバージョンを宣言するための 1種類の解析ディレクティブを含むことができます。 2.2 バージョン宣言を参照してください。

N-Quads文は、RDF トリプルの 主語、 述語、および 目的語 を表すRDF項の並びと、 RDFデータセット内でそのトリプルに関連付けられた 名前付きグラフを識別する任意の グラフ名であり、 クワッドとも呼ばれます。 これらは空白（スペース、および/またはタブ）で区切ることができます。 この並びはピリオド（.）で終了し、 その後に任意で空白および/またはコメント、 そして改行（文書の末尾では任意）が続きます。

例 1: 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> .

RDF データセットは、N-Quads文書によって表され、 N-Quadsの statement生成規則に一致する クワッドをちょうどすべて含みます。

この仕様は、RDF 1.1 N-Quads [N-QUADS]で定義された元のN-Quads構文を拡張し、 RDF 1.2 Concepts and Abstract Data Model [RDF12-CONCEPTS]によって導入された 新機能をサポートします。 この拡張は完全に後方互換です。

2. N-Quads言語

このセクションは非規範的です。

N-Quads文書は、 RDF データセット をテキスト形式で書き下すことを可能にします。 RDFデータセットは、単純な文から構成されます。 それらは 主語、 述語、 目的語、 任意の グラフ 名 および任意の空行で構成されます。 コメントは、別の字句トークンの一部ではない #の後に記述でき、 行末まで続きます。

2.1 単純な文

単純な文は、[RDF12-N-TRIPLES]における 単純なトリプルの定義を、 任意の名前付きグラフで拡張します。

最も単純な文は、 （主語、 述語、 目的語）項の並びであり、 RDFトリプルを形成します。 さらに任意の グラフ名 （空白ノード識別子 またはIRI） が続き、これはそのトリプルが属する データセット内の 名前付きグラフを示し、 ピリオド（.）で終了します。 空白（スペース、および/またはタブ）は項の周囲に置くことができますが、 文法で重要と示されている箇所を除きます。

コメントは空白として扱われ、別の字句トークンの一部ではない #の後に記述でき、 行末まで続きます。

グラフ名は省略でき、その場合、トリプルは RDFデータセットの デフォルトグラフの一部と見なされます。

例 2: 単純な文 

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

2.2 バージョン宣言

N-Quads言語はその起源以来発展してきており、RDF 1.2では 新しい構文が追加されます。 RDF 1.2 N-Quadsは、任意のversionメディア型パラメータとともに、 VERSIONディレクティブを導入します。 初期テキスト方向 やトリプル項などの新機能を含むN-Quadsを それぞれシリアライズおよび解析する際に、 著者およびパーサーは、これらのディレクティブを使用して新しい構文形式の使用を宣言および検出できます。 同様に、 HTTPクライアントおよびサーバーはversionメディア型 パラメータを使用できます。

N-Triplesと同様に、バージョン宣言は大文字と小文字を区別します。

例 3: バージョン宣言 

VERSION "1.2"
<http://example.org/#spiderman> <http://www.perceive.net/schemas/relationship/enemyOf> <http://example.org/#green-goblin> <http://example.org/#graph> .

HTTP経由でコンテンツを提供する場合、サーバーは任意のversion メディア型パラメータを使用してバージョンを宣言できます:

例 4: HTTPバージョン宣言 

GET /document.nq HTTP/1.1
Host: example.com
Accept: application/n-quads; version=1.2

バージョン宣言の使用に関する詳細な考慮事項については、[RDF12-TURTLE]の バージョン宣言を参照してください。

2.3 トリプル項

トリプル項は、 RDF トリプルの 目的語になることができます。

トリプル項は、 <<(が前に置かれ、 )>>が後に続く、 subject、 predicate、および object を持つtripleTermとして表されます。 トリプル項 は入れ子にできることに注意してください。

例 5: トリプル項 

_:e38  <ex:familyName>                                      "Smith" .
_:anno <http://www.w3.org/1999/02/22-rdf-syntax-ns#reifies> <<( _:e38 <http://example.com/jobTitle> "Designer" )>> .
_:anno <http://example.com/accordingTo>                     _:e22 .

2.4 IRI

N-Triplesと同様に、IRIは解決済みIRIとしてのみ記述できます。 IRIの前には<が置かれ、 後には>が続き、 数値エスケープシーケンスを含むことができます。 例: <http://example.org/#green-goblin>。

2.5 RDFリテラル

N-Triplesと同様に、 リテラルは、文字列、数値、日付などの値を識別するために使用されます。

リテラル（文法生成規則Literal）は、 字句形式の後に、 言語タグ （初期テキスト方向を含む場合があります）、 データ型IRI、 またはそのどちらも持たないものが続きます。

字句形式の表現は、 最初の区切り記号"、 許可された文字または 数値エスケープシーケンスまたは 文字列エスケープシーケンスの並び、 そして最後の区切り記号から構成されます。

リテラルは、エスケープされた形式を除き、 "、 LF、または CR の文字を含むことはできません。 さらに、\は エスケープシーケンスの一部である場合を除き、引用符付きリテラル内に現れることはできず、 "文字は エスケープシーケンスを使用する場合にのみ引用符付きリテラル内に含めることができます。

対応する字句形式は、 エスケープシーケンスを処理した後の、区切り記号の間の文字です。 存在する場合、LANG_DIR 終端記号は、言語タグ と、任意で初期テキスト方向に一致します。 言語タグ の前には@が置かれ、 存在する場合、初期テキスト方向 は言語タグ から--で区切られます。 言語タグがない場合は、 データ型IRIがある場合があり、 その前には^^が置かれます。 データ型IRIも言語タグもない場合、それは 単純リテラル であり、データ型はhttp://www.w3.org/2001/XMLSchema#stringです。

2.6 RDF空白ノード

N-Triplesと同様に、 RDF空白ノードは、 _: の後に BLANK_NODE_LABEL 生成規則に一致する空白ノードラベルが続く形で表されます。

非公式には、 _: の後の最初の文字は、 PN_CHARS_U に一致する文字または数字のいずれかです。 後続の文字が存在する場合、それらは PN_CHARS または.に一致しますが、 . は最後の文字として許可されません。

文書内の一意な 空白ノード識別子ごとに、新しいRDF 空白ノードが割り当てられます。 同じ 空白ノード識別子 の繰り返し使用は、同じ空白ノードを識別します。

例 6: N-Quadsにおける空白 ノード 

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

3. N-Quadsの正準形式

このセクションでは、レイアウトが完全に指定された N-Quadsの正準形式を定義します。 この言語の文法は変更されません。

正準N-Quadsは、[RDF12-N-TRIPLES]の 正準N-Triplesを拡張し、 graphLabelを含めます。

N-Quads構文はRDFデータの表現およびレイアウトについて選択肢を許しますが、 N-Quadsの正準形式は、任意のクワッドに対して一意の構文的表現を提供します。 各符号位置は、 表現の選択が許される関連生成規則において、 UCHAR、 ECHAR、 またはエンコードされていない文字のうち、 いずれか1つだけで表現できます。 各クワッドは、指定された空白を伴って、完全に1行で表されます。

正準N-Quadsには、レイアウトに関する次の追加制約があります:

4. 適合性

非規範的として示されたセクションに加え、この仕様内のすべての作成ガイドライン、図、例、および注記は非規範的です。 この仕様内のそれ以外のすべては規範的です。

この文書におけるキーワードMAY、MUST、MUST NOT、およびSHOULDは、 ここに示すようにすべて大文字で現れる場合にのみ、 BCP 14 [RFC2119] [RFC8174] に記述されているとおりに解釈されます。

この仕様は、次のものに対する適合基準を定義します:

適合するN-Quads文書は、 RDF 文字列であり、 nquadsDoc生成規則から開始して、 5. N-Quads文法で定義された 文法および追加制約に適合します。 N-Quads文書はRDFデータセットをシリアライズします。

注記

N-Quads文書は、RDFデータセットの一部である可能性がある空のグラフをシリアライズする方法を提供しません。

適合する正準N-Quads文書は、 正準N-Quadsの追加制約に従う N-Quads文書です。

適合するN-Quadsパーサーは、アプリケーションに代わって N-Quads文書を読み取ることができるシステムです。 それは、6. 構文解析で定義される、 シリアライズされたRDFデータセットを、 通常は何らかのAPIを通じてアプリケーションに利用可能にします。

N-Quads言語を識別するIRIは次のとおりです: http://www.w3.org/ns/formats/N-Quads

4.1 メディア型およびコンテンツ エンコーディング

N-Quadsのメディア型はapplication/n-quadsです。 N-Quadsのコンテンツエンコーディングは常にUTF-8です。 メディア型登録フォームについては、N-Quadsメディア型を参照してください。

4.1.1 その他のメディア型

元の仕様である N-Quads: Extending N-Triples with Contextは、 7ビットUS-ASCIIを使用するエンコーディングとともに、 メディア型text/x-nquadsの使用を提案しました。

5. N-Quads文法

N-Quads文書は、UTF-8 [RFC3629]でエンコードされた RDF 文字列です。 U+0000からU+D7FFまで、 およびU+E000からU+10FFFFまでの範囲の、 Unicodeスカラー値のみが許可されます。 これは、U+D800からU+DFFFまでの範囲の サロゲート符号位置を除外します。

5.1 空白

空白（スペース、および/またはタブ）は、終端記号の外側で許可されます。 以下の大文字の規則名は、空白が重要である場所を示します。

空白は、生成規則STRING_LITERAL_QUOTE内で重要です。

空白および/またはコメントのみで構成される 空行は、 statement生成規則が許可される場所であればどこにでも出現でき、 空白として扱われます。

注記

N-Triples [RDF12-N-TRIPLES]と同様に、 N-Quadsは水平空白（スペースまたはタブ）のみを許可します。

5.2 コメント

N-Quadsにおけるコメントは、IRIREFまたは STRING_LITERAL_QUOTEの外側にある #から始まり、 文字 CRまたは LFで示される行末まで、 またはコメントマーカーの後に行末がない場合はファイル末尾まで続きます。 コメントは空白として扱われます。

5.3 文法

ここで使用されるEBNFは、 XML 1.0 [EBNF-NOTATION]で定義されています。

エスケープシーケンス規則は、N-Triples [RDF12-N-TRIPLES]およびTurtle [RDF12-TURTLE]と同じです。 ただし、STRING_LITERAL_QUOTE 生成規則のみが許可されるため、リテラル内の改行はエスケープされなければ MUSTなりません。

'VERSION'終端記号は、大文字と小文字を区別することを示すために 一重引用符で囲まれています。

[1] nquadsDoc ::= statement? (EOL statement)* EOL?
[2] statement ::= directive | quad
[3] directive ::= versionDirective
[4] versionDirective ::= 'VERSION' versionSpecifier
[5] versionSpecifier ::= STRING_LITERAL_QUOTE
[6] quad ::= subject predicate object graphLabel? '.'
[7] subject ::= IRIREF | BLANK_NODE_LABEL
[8] predicate ::= IRIREF
[9] object ::= IRIREF | BLANK_NODE_LABEL | literal | tripleTerm
[10] graphLabel ::= IRIREF | BLANK_NODE_LABEL
[11] literal ::= STRING_LITERAL_QUOTE (('^^' IRIREF) | LANG_DIR)?
[12] tripleTerm ::= '<<(' subject predicate object ')>>'

終端記号の生成規則
[14] IRIREF ::= '<' ([^#x00-#x20<>"{}|^`\] | UCHAR)* '>'
[15] BLANK_NODE_LABEL ::= '_:' (PN_CHARS_U | [0-9]) ((PN_CHARS | '.')* PN_CHARS)?
[16] LANG_DIR ::= '@' [a-zA-Z]+ ('-' [a-zA-Z0-9]+)* ('--' [a-zA-Z]+)?
[17] STRING_LITERAL_QUOTE ::= '"' ([^#x22#x5C#x0A#x0D] | ECHAR | UCHAR)* '"'
[18] UCHAR ::= ('\u' HEX HEX HEX HEX) | ('\U' HEX HEX HEX HEX HEX HEX HEX HEX)
[19] ECHAR ::= '\' [tbnrf\"']
[20] 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]
[21] PN_CHARS_U ::= PN_CHARS_BASE | '_'
[22] PN_CHARS ::= PN_CHARS_U | '-' | [0-9] | #xB7 | [#x0300-#x036F] | [#x203F-#x2040]
[23] HEX ::= [0-9] | [A-F] | [a-f]
[24] EOL ::= [#x0D#x0A]+

この文法のテキスト版はこちらから利用できます。

5.4 選択された終端リテラル 文字列

この文書では、いくつかの特定の終端リテラル文字列 [EBNF-NOTATION]を使用します。 これらの終端リテラル文字列に使用されるUnicode符号位置を明確にするため、 次の表ではこの文書全体で使用される特定の文字およびシーケンスを説明します。

コード グリフ 説明
U+0008 BS バックスペース
U+0009 HT 水平タブ
U+000A LF 改行
U+000B VT 垂直タブ
U+000C FF 改ページ
U+000D CR キャリッジリターン
U+0022 " 引用符
U+0023 # 番号記号
U+002D - ハイフン
U+002E . ピリオド
U+0030 0 数字のゼロ
U+0039 9 数字の九
U+003B : コロン
U+003C < 小なり記号
U+003E > 大なり記号
U+0040 @ アット記号
U+0041 A ラテン大文字A
U+0046 F ラテン大文字F
U+005C \ バックスラッシュ
U+005F _ アンダースコア
U+0061 a ラテン小文字a
U+007A z ラテン小文字z
U+007F DEL 削除
U+00B7 · 中黒
U+203F ‿ アンダータイ
U+2040 ⁀ 文字タイ

その他の短い終端リテラル文字列は、Unicode文字の特定のシーケンスで構成されます:

space
U+0020
<<(
それぞれ符号位置U+003Cを持つ2つの連結された小なり記号文字の後に、 符号位置U+0028を持つ左丸括弧文字が続くもの
)>>
符号位置U+0029を持つ左丸括弧文字の後に、 それぞれ符号位置U+003Eを持つ2つの連結された大なり記号文字が続くもの
それぞれ符号位置U+003Eを持つ2つの連結された大なり記号文字
^^
それぞれ符号位置U+005Eを持つ2つの連結されたサーカムフレックスアクセント文字
_:
_の後に:が続くもの
--
2つの連結された-文字

6. 構文解析

N-Quadsを構文解析するには、2つの項目からなる状態が必要です:

6.1 RDF項コンストラクタ

この表は、生成規則および字句トークンを、 RDF 項 またはRDF項の構成要素に対応付けるものであり、 6. 構文解析に一覧されています:

生成規則 型 手順
versionSpecifier リテラル curVersionは、一致したRDF文字列の 字句形式およびxsd:stringデータ型を使用して、 リテラルから取得されます。
BLANK_NODE_LABEL 空白ノード _:の後の文字列は、 bnodeLabels内のキーです。 マップ内に対応する空白ノードがない場合、 1つが割り当てられます。
IRIREF IRI < と>の間の文字が取得され、 エスケープシーケンスを解除して、 IRIを形成します。 得られるIRIは、汎用IRI構文の 構文上の制限に従わなければ MUSTならず、 [RFC3986]の セクション3.3に適合することが SHOULD望ましく、 対応するIRIスキーム仕様によって課されるより狭い制限にも従う必要があります。
LANG_DIR 言語タグ @の後に続く文字は、 言語タグ を形成し、一致した文字に --が含まれる場合は、 任意で初期テキスト方向も形成します。
言語タグ は、[BCP47]の セクション2.2.9 に従って整形式でなければMUSTなりません。 存在する場合、初期テキスト方向 はltrまたはrtlのいずれかでなければMUSTなりません。
STRING_LITERAL_QUOTE RDF字句形式 最外部の引用符（"）の間の文字が取得され、 エスケープシーケンスを解除して、 字句形式の 文字列を形成します。
literal リテラル リテラルは、最初の規則引数である STRING_LITERAL_QUOTEの 字句形式を持ち、 入力に一致した規則に応じて、 LANG_DIRからの 任意の初期テキスト方向を伴う 言語タグ またはiriの データ型IRIのいずれかを持ちます。 LANG_DIR 規則が一致した場合、 言語タグ および初期テキスト方向 はLANG_DIRから取得されます。 初期テキスト方向がない場合、 データ型はrdf:langStringです。 初期テキスト方向がある場合、 データ型はrdf:dirLangStringです。 LANG_DIR もデータ型IRIも一致しない場合、 リテラルのデータ型はxsd:stringです。
tripleTerm トリプル項 トリプル項 は、 subject、 predicate、および object生成規則から 構築された項で構成されます。
注記

入力上のエラーを検出するプロセッサは、 入力で記述されているよりも少ないトリプルを含むデータセット （まったくトリプルを含まない場合も含む）を生じることがあるため、 利用者は、結果のデータセットを使用するときに通知されたエラー情報を考慮すべきです。 そのデータセットは不完全であったり、 ill-typed または整形式でない項を含んだりする可能性があります。

6.2 RDFデータセット構築

N-Quads文書は、 RDF トリプルの集合で構成される RDFグラフから構成される RDFデータセット を定義します。 statement生成規則は、 subject、 predicate、および objectに対して構築された項によって定義される トリプルを生成します。 このRDFトリプルは、 生成規則graphLabelによってラベル付けされた グラフに追加され、 graphLabelが存在しない場合、そのトリプルはRDFデータセットのデフォルトグラフに追加されます。

A. プライバシーの考慮事項

このセクションは非規範的です。

N-Quads形式は任意のアプリケーションデータを表現するために使用され、 個人を特定できる情報（PII）または機微と見なされる可能性のあるその他の情報の表現を 含む場合があります。 そのような情報を公開する著者は、そのような情報を公開する必要性および利用方法、 ならびにそのデータが消費され、潜在的に明らかにされることが予期される地域に適用される規制 （例: GDPR、 CCPA、 その他）を 慎重に検討することが推奨されます。 特に、データへのアクセスに認可手段が必要かどうかを検討する必要があります。

B. セキュリティの考慮事項

このセクションは非規範的です。

STRING_LITERAL_QUOTE 生成規則は、エスケープされていない制御文字の使用を許可します。 この仕様はこの内容をエンドユーザーに直接公開しませんが、 ユーザーエージェントを通じて提示される可能性があり、そのような文字の提示により 表示されたテキストが不明瞭になる可能性があります。

N-Quadsは汎用の表明言語です。 アプリケーションは、与えられたデータを評価して、さらに多くの表明を推論したり、 IRIを参照解除したりする場合があり、 そのIRIのスキームに関するセキュリティ上の考慮事項を呼び起こします。 特に、HTTP IRIについては[RFC3023]セクション10のプライバシー問題に注意してください。 不正確または悪意のあるデータソースから取得されたデータは、 不正確または誤解を招く結論、および意図しないIRIの参照解除につながる可能性があります。 参照するリソースに対する信頼を、データの意図された使用の機微性に合わせるよう注意が必要です。 例えば、潜在的な医療処置に関する推論には、 旅行計画に関する推論とは異なる信頼が必要になる可能性があります。

N-Quads言語は任意のアプリケーションデータを表現するために使用されます。 セキュリティ上の考慮事項は利用領域によって異なります。 テキストに適用可能なセキュリティツールおよびプロトコル （例えば、PGP暗号化、チェックサム検証、パスワード保護付き圧縮）は、 N-Quads文書にも使用できます。 埋め込まれた情報の機微性を反映するセキュリティ/プライバシープロトコルを課す必要があります。

N-Quadsは、RDF Schemaラベルなど、ユーザーに提示されるデータを表現できます。 信頼されていないN-Quads文書から取得した文字列をレンダリングする、 またはエスケープされていない文字を使用するアプリケーションは、 悪意のある文字列が読者を誤解させるために使用される可能性を制限するため、 警告その他の適切な手段を使用することがSHOULD望ましいです。 XMLのメディア型登録におけるセキュリティの考慮事項 （[RFC3023]セクション10）は、 任意のデータおよびマークアップの表現に関して追加の指針を提供します。

N-Quadsは、項識別子として IRIを使用します。 N-Quadsで表現されたデータを解釈するアプリケーションは、 Internationalized Resource Identifiers (IRIs) [RFC3987] セクション8、および Uniform Resource Identifier (URI): Generic Syntax [RFC3986] セクション7のセキュリティ問題に対処することがSHOULD望ましいです。

複数のIRIが 同じ外観を持つ場合があります。 異なる文字体系の文字が似て見えることがあります（例えば、 キリル文字の「о」はラテン文字の「o」に似て見える場合があります）。 結合文字が後続する文字は、別の文字と同じ視覚的表現を持つ場合があります （例えば、LATIN SMALL LETTER "E"にCOMBINING ACUTE ACCENTが続くものは、LATIN SMALL LETTER "E" WITH ACUTEと同じ視覚的表現を持ちます）。 N-Quadsでデータを書いたり解釈したりする人またはアプリケーションは、 意図した意味論に一致するIRIを使用し、 似て見える可能性のあるIRIを避けるよう注意しなければなりません。 視覚的に類似する文字の照合に関する詳細情報は、 Unicode Security Considerations [UNICODE-SECURITY]および Internationalized Resource Identifiers (IRIs) [RFC3987] セクション8にあります。

C. インターネットメディア型およびファイル 拡張子

N-Quadsのインターネットメディア型（以前はMIME型として知られていたもの）は「application/n-quads」です。

以下の情報は、審査、承認、およびIANAへの登録のため、 Internet Engineering Steering Group（IESG）に提出されています。

型名:
application
サブタイプ名:
n-quads
必須パラメータ:
なし
任意パラメータ:
version
このパラメータは任意です。 存在する場合、versionで許容される値は、 [RDF12-CONCEPTS]の 2.1 バージョンラベルで定義されています。
profile
このパラメータは任意であり、追加情報を含めるために使用されます。 プロファイルの知識なしに処理された場合でも、 リソース表現の意味論は変更されません。 profileパラメータの値は、空白で区切られたURIの空でないリストです。 詳細情報および背景については、[RFC6906]を参照してください。
エンコーディング上の考慮事項:
N-Quadsの構文は、Unicode [UNICODE]の 符号位置上で表現されます。 エンコーディングは常にUTF-8 [UTF-8]です。
Unicode符号位置は、\uXXXX（U+0000からU+FFFFまで） または\UXXXXXXXX構文（U+10FFFFまでの符号位置用）でも表現できます。 ここでXは16進数字[0-9A-F]です。
セキュリティ上の考慮事項:
B. セキュリティ の考慮事項を参照してください。
相互運用性上の考慮事項:
既知の相互運用性の問題はありません。
公開仕様:
この仕様。
このメディア型を使用するアプリケーション:
N-QuadsはRDFデータを表すために広く使用されています。 ほとんどの一般的なプログラミング言語で利用可能な実装があります。
追加情報:
マジックナンバー:
なし。
ファイル拡張子:
.nq
詳細情報の連絡先となる人物およびメールアドレス:
RDF & SPARQL Working Group <public-rdf-star-wg@w3.org>
想定される使用:
一般的
使用上の制限:
なし
著者:
N-Quads仕様はRDF & SPARQL WGの成果物です。W3Cはこの仕様に対する変更管理を保持します。
注記

profileパラメータは、コンテンツネゴシエーション過程において クライアントが自らの選好を表現するため、およびサーバーがレスポンスに関する追加情報を示すために 使用できます。

profileパラメータがクライアントによって与えられた場合、 サーバーは、そのリスト内でサーバーが認識するすべてのプロファイルを尊重する文書を 返すべきです。 サーバーは、profile値のみに基づいてエラーで応答すべきではありません。

profileパラメータがサーバーによって与えられた場合、 クライアントはそれを無視することを選択できます。

注記

profile URIは参照解除可能であり、 そのURIで有用な文書を提供することが推奨されます。

注記

メディア型パラメータ [RFC4288]として、 HTTP Content-Typeヘッダー または HTTP Acceptヘッダー [RFC7231] で使用される場合、profileパラメータの値は、 複数のprofile URIを区切るために使用される空白を含む特殊文字を含む場合、 引用符（ASCII "）で囲む必要があります。

profileパラメータの値には、 IRIではなく1つ以上のURIが含まれる点に注意することが重要です。 そのため、[RFC3987]の セクション3 IRIとURIの関係 で指定されているように、IRIとURIの間の変換が必要になる場合があります。

D. 謝辞

このセクションは非規範的です。

D.1 RDF 1.1への謝辞

このセクションは非規範的です。

RDF 1.1版の編集者は、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、およびDavid Boothからの貴重な貢献に謝意を表します。

この仕様は、Guus SchreiberおよびDavid Woodが議長を務めるRDF Working Groupのメンバーによる 広範な審議の成果です。 これは、Richard Cyganiak、Andreas Harth、およびAidan Hoganが編集した N-Quads: Extending N-Triples with Contextの 以前の仕様に基づいています。

D.2 RDF 1.2への謝辞

このセクションは非規範的です。

RDF 1.2版の編集者は、Andy Seaborneからの貴重な貢献に謝意を表します。

編集者に加えて、次の人々がこの仕様に貢献しました: Andy Seaborne、Denis Ah-Kang、Jim Smart、Niklas Lindström、Peter F. Patel-Schneider、Pierre-Antoine Champin、Ted Thibodeau Jr、およびThomas Tanon

RDF & SPARQL Working Group Groupのメンバーには、次の人々が含まれていました
James Anderson、Dörthe Arndt、Jerven Bolleman、Erich Bremer、Pierre-Antoine Champin、Souripriya Das、 Enrico Franconi、Adrian Gschwend、Olaf Hartig、Gregg Kellogg†、Ora Lassila、Niklas Lindström、Thomas Lörtsch、Peter Patel-Schneider、Dave Raggett、Felix Sasaki、Andy Seaborne、Ruben Taelman、Thomas Pellissier Tanon、Ted Thibodeau Jr、Dominik Tomaszuk、Gregory Williams、William Van Woensel、およびAntoine Zimmermann
† Gregg Kelloggは2025年9月に逝去しました。RDFおよび関連標準のより広いエコシステムへの彼の多大な貢献に、 深く感謝の意を表します。

編集者注

タスクフォースのメンバーを認識するか？貢献者の一覧を見つけるのは容易ではありません。

E. RDF 1.1とRDF 1.2の間の変更点

このセクションは非規範的です。

この仕様は、RDF 1.1 N-Quads [N-QUADS]で定義された元のN-Quads構文を拡張し、 RDF 1.2 Concepts and Abstract Data Model [RDF12-CONCEPTS]によって導入された 新機能をサポートします。 この拡張は完全に後方互換です: 古いバージョンに適合する任意の文書は新しいバージョンにも適合し、同じグラフに構文解析されます。 さらに、新しいバージョンに適合し、RDF 1.1の機能のみを含む任意の文書も 古いバージョンに適合します （VERSIONディレクティブを除きます。2.2 バージョン宣言を参照）。 最後に、新しい構文構成要素はいずれも古い構文では有効ではありません。 つまり、RDF 1.2機能を使用するN-Quads文書は、 この仕様の以前のバージョンに適合せず、その下で別のグラフとして解釈することはできません。

より具体的には、次の変更が行われました:

F. 索引

このセクションは非規範的です。

F.1 この仕様で定義される 用語

F.2 参照によって定義される用語

G. 課題概要

このセクションは非規範的です。

この仕様には一覧されている課題はありません。

H. 参考文献

H.1 規範的参考文献

[BCP47]
Tags for Identifying Languages. A. Phillips, Ed.; M. Davis, Ed. IETF. 2009年9月. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc5646
[EBNF-NOTATION]
EBNF Notation. Tim Bray; Jean Paoli; Michael Sperberg-McQueen; Eve Maler; François Yergeau et al. W3C. W3C勧告. URL: https://www.w3.org/TR/xml/#sec-notation
[I18N-GLOSSARY]
Internationalization Glossary. Richard Ishida; Addison Phillips. W3C. 2024年10月17日. W3C Working Group Note. URL: https://www.w3.org/TR/i18n-glossary/
[RDF12-CONCEPTS]
RDF 1.2 Concepts and Abstract Data Model. Andy Seaborne; Gregg Kellogg; Olaf Hartig; Pierre-Antoine Champin. W3C. 2026年4月7日. W3C Candidate Recommendation. URL: https://www.w3.org/TR/rdf12-concepts/
[RDF12-N-TRIPLES]
RDF 1.2 N-Triples. Gregg Kellogg; Dominik Tomaszuk. W3C. 2026年5月15日. W3C作業草案. URL: https://www.w3.org/TR/rdf12-n-triples/
[RDF12-TURTLE]
RDF 1.2 Turtle. Gregg Kellogg; Andy Seaborne; Dominik Tomaszuk. W3C. 2026年5月28日. W3C作業草案. URL: https://www.w3.org/TR/rdf12-turtle/
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. 1997年3月. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119
[RFC3629]
UTF-8, a transformation format of ISO 10646. F. Yergeau. IETF. 2003年11月. Internet Standard. URL: https://www.rfc-editor.org/rfc/rfc3629
[RFC3986]
Uniform Resource Identifier (URI): Generic Syntax. T. Berners-Lee; R. Fielding; L. Masinter. IETF. 2005年1月. Internet Standard. URL: https://www.rfc-editor.org/rfc/rfc3986
[RFC3987]
Internationalized Resource Identifiers (IRIs). M. Duerst; M. Suignard. IETF. 2005年1月. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc3987
[RFC6906]
The 'profile' Link Relation Type. E. Wilde. IETF. 2013年3月. Informational. URL: https://www.rfc-editor.org/rfc/rfc6906
[RFC8174]
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. 2017年5月. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc8174
[UNICODE]
The Unicode Standard. Unicode Consortium. URL: https://www.unicode.org/versions/latest/
[XML11]
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. 2006年8月16日. W3C勧告. URL: https://www.w3.org/TR/xml11/

H.2 参考情報の参考文献

[N-QUADS]
RDF 1.1 N-Quads. Gavin Carothers. W3C. 2014年2月25日. W3C勧告. URL: https://www.w3.org/TR/n-quads/
[RDF12-INTEROP]
RDF 1.2 Interoperability. Pierre-Antoine Champin. W3C. W3C編集者草案. URL: https://w3c.github.io/rdf-interop/spec/
[RDF12-NEW]
What’s New in RDF 1.2. The W3C RDF & SPARQL Working Group. W3C. W3C編集者草案. URL: https://w3c.github.io/rdf-new/spec/
[RDF12-PRIMER]
RDF 1.2 Primer. Pierre-Antoine Champin; Niklas Lindström. W3C. 2026年4月16日. DNOTE. URL: https://www.w3.org/TR/rdf12-primer/
[RDF12-SCHEMA]
RDF 1.2 Schema. Dominik Tomaszuk. W3C. 2026年3月28日. W3C作業草案. URL: https://www.w3.org/TR/rdf12-schema/
[RDF12-SEMANTICS]
RDF 1.2 Semantics. Peter Patel-Schneider; Enrico Franconi; Dörthe Arndt. W3C. 2026年4月7日. W3C Candidate Recommendation. URL: https://www.w3.org/TR/rdf12-semantics/
[RDF12-TRIG]
RDF 1.2 TriG. Gregg Kellogg; Dominik Tomaszuk. W3C. 2026年5月28日. W3C作業草案. URL: https://www.w3.org/TR/rdf12-trig/
[RDF12-XML]
RDF 1.2 XML Syntax. Gregg Kellogg; Jerven Bolleman. W3C. 2026年4月9日. W3C作業草案. URL: https://www.w3.org/TR/rdf12-xml/
[RFC3023]
XML Media Types. M. Murata; S. St. Laurent; D. Kohn. IETF. 2001年1月. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc3023
[RFC4288]
Media Type Specifications and Registration Procedures. N. Freed; J. Klensin. IETF. 2005年12月. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc4288
[RFC7231]
Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. R. Fielding, Ed.; J. Reschke, Ed. IETF. 2014年6月. Proposed Standard. URL: https://httpwg.org/specs/rfc7231.html
[SPARQL12-CONCEPTS]
SPARQL 1.2 Concepts. The W3C RDF & SPARQL Working Group. W3C. W3C編集者草案. URL: https://w3c.github.io/sparql-concepts/spec/
[SPARQL12-ENTAILMENT]
SPARQL 1.2 Entailment Regimes. Peter Patel-Schneider. W3C. 2026年4月9日. W3C作業草案. URL: https://www.w3.org/TR/sparql12-entailment/
[SPARQL12-FEDERATED-QUERY]
SPARQL 1.2 Federated Query. Ruben Taelman; Gregory Williams. W3C. 2026年4月23日. W3C作業草案. URL: https://www.w3.org/TR/sparql12-federated-query/
[SPARQL12-GRAPH-STORE-PROTOCOL]
SPARQL 1.2 Graph Store Protocol. Andy Seaborne; Thomas Pellissier Tanon. W3C. 2024年12月19日. W3C 作業草案. URL: https://www.w3.org/TR/sparql12-graph-store-protocol/
[SPARQL12-NEW]
What’s New in SPARQL 1.2. The W3C RDF & SPARQL Working Group. W3C. W3C編集者草案. URL: https://w3c.github.io/sparql-new/spec/
[SPARQL12-PROTOCOL]
SPARQL 1.2 Protocol. Andy Seaborne; Ruben Taelman; Gregory Williams; Thomas Pellissier Tanon. W3C. 2026年4月26日. W3C作業 草案. URL: https://www.w3.org/TR/sparql12-protocol/
[SPARQL12-QUERY]
SPARQL 1.2 Query Language. Olaf Hartig; Andy Seaborne; Ruben Taelman; Gregory Williams; Thomas Pellissier Tanon. W3C. 2026年5月28日. W3C作業草案. URL: https://www.w3.org/TR/sparql12-query/
[SPARQL12-RESULTS-CSV-TSV]
SPARQL 1.2 Query Results CSV and TSV Formats. Ruben Taelman; Gregory Williams; Thomas Pellissier Tanon. W3C. 2026年3月28日. W3C作業草案. URL: https://www.w3.org/TR/sparql12-results-csv-tsv/
[SPARQL12-RESULTS-JSON]
SPARQL 1.2 Query Results JSON Format. Andy Seaborne; Ruben Taelman; Gregory Williams; Thomas Pellissier Tanon. W3C. 2026年3月28日. W3C作業草案. URL: https://www.w3.org/TR/sparql12-results-json/
[SPARQL12-RESULTS-XML]
SPARQL 1.2 Query Results XML Format. Ruben Taelman; Dominik Tomaszuk; Thomas Pellissier Tanon. W3C. 2024年12月27日. W3C作業草案. URL: https://www.w3.org/TR/sparql12-results-xml/
[SPARQL12-SERVICE-DESCRIPTION]
SPARQL 1.2 Service Description. Ruben Taelman; Gregory Williams. W3C. 2026年4月23日. W3C作業 草案. URL: https://www.w3.org/TR/sparql12-service-description/
[SPARQL12-UPDATE]
SPARQL 1.2 Update. Ruben Taelman; Andy Seaborne; Thomas Pellissier Tanon. W3C. 2026年4月23日. W3C作業草案. URL: https://www.w3.org/TR/sparql12-update/
[UNICODE-SECURITY]
Unicode Security Considerations. Mark Davis; Michel Suignard. Unicode Consortium. 2014年9月19日. Unicode Technical Report #36. URL: https://www.unicode.org/reports/tr36/tr36-15.html