RDF 1.2 N-Triples

RDFグラフのための行ベース構文

W3C作業草案

この文書の詳細
このバージョン:
https://www.w3.org/TR/2026/WD-rdf12-n-triples-20260624/
最新公開バージョン:
https://www.w3.org/TR/rdf12-n-triples/
最新編集者草案:
https://w3c.github.io/rdf-n-triples/spec/
履歴:
https://www.w3.org/standards/history/rdf12-n-triples/
コミット履歴
テストスイート:
https://w3c.github.io/rdf-tests/rdf/rdf12/rdf-n-triples/
実装報告:
https://w3c.github.io/rdf-tests/rdf/rdf12/reports/
最新勧告:
https://www.w3.org/TR/n-triples
編集者:
Gregg Kellogg（2025-09-06まで）、追悼
Dominik Tomaszuk
元編集者:
Gavin Carothers（RDF 1.1）
Andy Seaborne（RDF 1.1）
著者:
David Beckett
フィードバック:
GitHub w3c/rdf-n-triples （プルリクエスト、 新しい課題、 未解決の課題）
public-rdf-star-wg@w3.org 宛てに、件名行を[rdf12-n-triples] … メッセージのトピック …として送信してください（アーカイブ）

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

要約

N-Triplesは、RDF グラフを符号化するための、行ベースのプレーンテキスト形式である。

RDF 1.2 N-Triplesは、トリプル項を RDF項の第4の種類として導入する。 これは、別の トリプル の 目的語 として使用でき、 他の文についての文を作ることを可能にする。 RDF 1.2 N-Triplesは、 方向付き言語タグ付き文字列の サポートも追加する。

この文書の状態

この節は、この文書の公開時点における状態を説明する。現在のW3C 公開物の一覧と、この技術報告の最新改訂版は、 W3C標準および草案 索引で確認できる。

この文書は、RDF 1.2文書群の一部である。 N-Triples形式は、Turtle [RDF12-TURTLE] のサブセットに基づく、 行ベースのRDF構文である。

W3C候補勧告フェーズを終了するために、 W3C RDF & SPARQLワーキンググループは、 少なくとも2つの独立した実装が 専用テストスイートの各テストに合格することを要求する。

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

作業草案としての公開は、 W3Cおよびそのメンバーによる承認を意味しない。

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

この文書は、 W3C 特許 方針の下で運営される グループによって作成された。 W3Cは、 グループの成果物に関連して行われた 特許開示の公開一覧を 維持している。そのページには、 特許を開示するための手順も含まれる。個人が、その個人の考えるところ、 必須クレームを含む 特許について実際の知識を有する場合、その個人は W3C特許方針の第6節に従って その情報を開示しなければならない。

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

1. はじめに

この節は非規範的である。

この文書は、RDF [RDF12-CONCEPTS] の具象構文である N-Triplesを定義する。 N-Triplesは、Turtle [RDF12-TURTLE] の、解析しやすい行ベースのサブセットである。

この構文は、RDF Test Cases [RDF-TESTCASES] 文書で最初に定義された N-Triplesの改訂版である。 当初の目的はテストケースを書くことであったが、 RDFデータの交換形式として広く使われるようになった。 この仕様は、[N-TRIPLES] で 定義されている構文をさらに拡張し、[RDF12-CONCEPTS] によって導入された 新機能をサポートする。 この拡張は完全に後方互換である。

N-Triples文書は、内容のRDFバージョンを宣言するための 1種類の構文解析ディレクティブを含むことができる。 2.2 バージョン宣言を参照。

N-Triplesのトリプルは、 RDF トリプルの 主語、 述語、および 目的語 を表すRDF項の列である。 これらは空白（スペースおよび/またはタブ）で区切ることができる。 この列はピリオド（.）で終了し、 任意で空白および/またはコメントが続き、 さらに改行（文書の末尾では任意）が続く。

例 1: N-Triplesにおけるコメントの使用 

<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のトリプルはTurtleの単純なトリプルでもあるが、 TurtleにはRDF項の他の表現や RDFトリプルの省略表記も含まれる。 Turtleパーサーで解析した場合、 N-Triples形式のデータは、N-Triples言語のパーサーとまったく同じトリプルを生成する。

N-Triples文書によって表されるRDF グラフは、 N-Triplesのtriple生成規則に一致する 各トリプルを正確に含む。

2. N-Triples言語

この節は非規範的である。

N-Triples文書により、 RDF グラフ をテキスト形式で記述できる。 RDFグラフは、 主語、 述語、および 目的語 からなる単純なトリプルと、 任意の空行で構成される。 コメントは、他の字句トークンの一部ではない#の後に記述でき、 行末まで続く。

2.1 単純なトリプル

最も単純なトリプル文は、 （主語、 述語、および 目的語）項の列であり、 ピリオド（.）で終了する。 空白（スペース U+0020 またはタブ U+0009）は、 文法で重要であると示されている箇所を除き、 項の周囲に置くことができる。

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

例 2: 単純なトリプル 

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

2.2 バージョン宣言

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

Turtleとは異なり、バージョン宣言は大文字と小文字を区別する。

例 3: バージョン宣言 

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

HTTPで内容を転送する場合、送信者と受信者は任意のversionメディア型パラメーターを使用して、 バージョンを宣言または要求できる。

例 4: HTTPバージョン宣言 

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

バージョン宣言を使用する際の追加の考慮事項については、[RDF12-TURTLE] の バージョン宣言を参照。

2.3 トリプル項

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

トリプル項は、 <<(を前に置き、 )>>を後に置いた subject、 predicate、および object を含むtripleTermとして表される。 トリプル項は 入れ子にできることに注意。

例 5: トリプル項 

VERSION                                                     "1.2"
_: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

IRIは、 解決済みIRIとしてのみ記述できる。 IRIは<を前に置き、 >を後に置き、 数値エスケープシーケンスを含むことができる。 例えば、<http://example.org/#green-goblin>である。

2.5 RDFリテラル

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

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

字句形式の表現は、 開始区切り記号"、 許可される文字または 数値エスケープシーケンスもしくは 文字列エスケープシーケンスの列、 そして終了区切り記号からなる。

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

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

例 6: N-Triplesにおけるリテラル 

VERSION     "1.2"
<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 an initial text 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.6 RDF空白ノード

RDF空白ノードは、 _:の後に、 BLANK_NODE_LABEL 生成規則に一致する空白ノードラベルを続けて表現される。

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

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

例 7: N-Triplesにおける空白ノード 

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

3. N-Triplesの正準形式

この節は、完全に指定されたレイアウトをもつ N-Triplesの正準形式を定義する。 この言語の文法は変更されない。

N-Triples構文はRDFデータの表現およびレイアウトに選択肢を許すが、 N-Triplesの正準形式は任意のトリプルに対して一意な構文表現を提供する。 各符号位置は、 関連する生成規則が表現の選択肢を許す場合、 UCHAR、 ECHAR、 または符号化されていない文字のうち、ただ1つによって表現できる。 各トリプルは、指定された空白を用いて完全に1行で表現される。

正準N-Triplesには、レイアウトに関して次の追加制約がある。

4. 適合性

非規範的と示された節に加えて、この仕様におけるすべての作成者向けガイドライン、図、例、および注記は 非規範的である。この仕様におけるそれ以外のすべては規範的である。

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

この仕様は、次のものについて適合基準を定義する。

適合するN-Triples文書は、RDF 文字列であり、 5. N-Triples文法で定義される文法および追加制約に、 ntriplesDoc生成規則から始まるものとして適合する。 N-Triples文書はRDFグラフを直列化する。

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

適合するN-Triplesパーサーは、アプリケーションに代わって N-Triples文書を読み取ることができるシステムである。 これは、6. 構文解析で定義される、 直列化されたRDFグラフを、 通常は何らかのAPIを通じて、アプリケーションが利用できるようにする。

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

4.1 メディア型およびコンテンツ 符号化

N-Triplesのメディア型はapplication/n-triplesである。 N-Triplesのコンテンツ符号化は常にUTF-8 [RFC3629] である。 メディア型登録フォームについては、N-Triplesメディア型を参照。

4.1.1 その他のメディア型

N-Triplesは歴史的に他のメディア型でも提供されてきた。 N-Triplesはtext/plainとして提供されてもよい。 このように使用する場合、N-TriplesはUS-ASCII外の任意の文字についてエスケープ形式を 使用しなければならない。 N-TriplesはTurtleのサブセットであるため、N-Triples文書は text/turtleとして提供されてもよい。 これらのいずれの場合も、その文書はN-Triples文書ではない。N-Triples文書は application/n-triplesとしてのみ提供されるからである。

5. N-Triples文法

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

5.1 空白

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

空白は、生成規則STRING_LITERAL_QUOTE内では意味を持つ。

空白および/またはコメントのみで構成される空行は、 triple生成規則が許可される任意の場所に現れてもよく、 空白として扱われる。

注記

N-Triplesは、Turtle [RDF12-TURTLE] が LF およびCR も空白として扱うのに対し、水平空白（スペースまたはタブ）のみを許可する。

5.2 コメント

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

5.3 文法

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

エスケープシーケンス規則はTurtle [RDF12-TURTLE] と同じである。 ただし、許可されるのはSTRING_LITERAL_QUOTE 生成規則のみであるため、リテラル内の改行はエスケープしなければならない。

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

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

終端記号の生成規則
[13] IRIREF ::= '<' ([^#x00-#x20<>"{}|^`\] | UCHAR)* '>'
[14] BLANK_NODE_LABEL ::= '_:' (PN_CHARS_U | [0-9]) ((PN_CHARS | '.')* PN_CHARS)?
[15] LANG_DIR ::= '@' [a-zA-Z]+ ('-' [a-zA-Z0-9]+)* ('--' [a-zA-Z]+)?
[16] STRING_LITERAL_QUOTE ::= '"' ([^#x22#x5C#x0A#x0D] | ECHAR | UCHAR)* '"'
[17] UCHAR ::= ('\u' HEX HEX HEX HEX) | ('\U' HEX HEX HEX HEX HEX HEX HEX HEX)
[18] ECHAR ::= '\' [tbnrf\"']
[19] 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]
[20] PN_CHARS_U ::= PN_CHARS_BASE | '_'
[21] PN_CHARS ::= PN_CHARS_U | '-' | [0-9] | #xB7 | [#x0300-#x036F] | [#x203F-#x2040]
[22] HEX ::= [0-9] | [A-F] | [a-f]
[23] 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 数字の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
<<(
2つの連結された小なり記号文字（各符号位置はU+003C）の後に、 符号位置U+0028をもつ左丸括弧文字が続く
)>>
符号位置U+0029をもつ左丸括弧文字の後に、 2つの連結された大なり記号文字（各符号位置はU+003E）が続く
^^
2つの連結されたサーカムフレックスアクセント文字（各符号位置はU+005E）
_:
_の後に:が続く
--
2つの連結された-文字

6. 構文解析

この節は、5.3 文法の文法に適合する文字列を、 生成規則および字句トークンに一致する文字列を RDF 項またはその構成要素（例: 言語タグ、リテラルの字句形式）に対応付けることによって、 トリプルのストリームに対応付ける。 文法生成規則はパーサー状態を変更し、トリプルを出力する。

入力の誤りを検出したプロセッサーは、それらを誤りまたは警告として通知しなければならない。 プロセッサーの正確な出力は、トリプルがそもそも出力されるかどうかを含め、 この仕様では定義されない。 いかなる出力も、入力の誤りのない領域を解析して出力されるトリプルの部分集合のみを 含むべきである。

注記

この仕様の以前のバージョンでは、認識されない入力に対する振る舞いを指定していなかったが、 ワーキンググループが把握しているすべての実装は、すでに上記の要件と一貫する振る舞いをしている。 特に、これらの実装は、 VERSIONディレクティブを含め、それら以前のバージョンで認識されない RDF 1.2固有の構文に遭遇した場合に誤りを通知する。 それらは、そのような構文を暗黙に無視したり誤って解釈したりしない。

6.1 パーサー状態

N-Triplesの構文解析には、2つの項目からなる状態が必要である。

6.2 RDF項コンストラクター

この表は、生成規則および字句トークンを、RDF 項、またはRDF 項の構成要素に対応付ける。これらは6. 構文解析に示されている。

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

6.3 RDFトリプル構築

N-Triples文書は、 RDFトリプルの集合で構成される RDF グラフを定義する。 triple生成規則は、 subject、 predicate、および objectのために構築された項によって定義される トリプルを出力する。

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

この節は非規範的である。

N-Triples形式は、任意のアプリケーションデータを表現するために使用される。 これには、個人を識別可能な情報（PII）、 または機微とみなされる可能性のあるその他の情報の表現が含まれることがある。 そのような情報を公開する作成者には、 そのような情報を公開する必要性と用途、 ならびにデータが消費され、潜在的に開示されることが想定される地域に適用される規制 （例: GDPR、 CCPA、 その他）を、 特にデータへのアクセスに認可措置が必要かどうかを含めて、 慎重に検討することが推奨される。

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

この節は非規範的である。

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

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

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

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

N-Triplesは、項識別子としてIRIを使用する。 N-Triplesで表現されたデータを解釈するアプリケーションは、 国際化 リソース識別子（IRI） [RFC3987] 第8節、および 統一リソース 識別子（URI）: 汎用構文 [RFC3986] 第7節のセキュリティ問題に対処すべきである。

複数のIRIが 同じ外観をもつ場合がある。 異なる文字体系の文字が似て見える場合がある（例えば、 キリル文字の「о」はラテン文字の「o」に似て見える場合がある）。 文字に結合文字が続くものが、別の文字と同じ視覚表現をもつ場合がある （例えば、LATIN SMALL LETTER "E"の後にCOMBINING ACUTE ACCENTが続くものは、LATIN SMALL LETTER "E" WITH ACUTEと同じ視覚表現をもつ）。 N-Triplesでデータを書いたり解釈したりする人またはアプリケーションは、 意図された意味論に一致するIRIを使用し、 似て見える可能性のあるIRIを避けるよう注意しなければならない。 視覚的に類似する文字の照合に関する追加情報は、 Unicodeセキュリティの考慮事項 [UNICODE-SECURITY] および 国際化 リソース識別子（IRI） [RFC3987] 第8節にある。

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

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

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

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

profileパラメーターは、クライアントがコンテンツネゴシエーション処理で 自身の選好を表現するため、およびサーバーが応答に関する追加情報を示すために使用できる。

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

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

注記

プロファイルURIは逆参照可能であり、 そのURIで有用な文書を提供することが推奨される。

注記

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

profileパラメーターの値は、 1つ以上のURIを含むものであり、IRIではないことに注意することが重要である。 したがって、[RFC3987] の 第3節 IRIとURIの関係で 指定されているように、IRIとURIの間で変換する必要がある場合がある。

D. 謝辞

この節は非規範的である。

D.1 RDF 1.1への謝辞

この節は非規範的である。

RDF 1.1版の編集者は、Gregg Kellogg、Eric Prud'hommeaux、Dave Beckett、David Robillard、Gregory Williams、Pat Hayes、Richard Cyganiak、Henry S. Thompson、 Peter Ansell、Evan PattonおよびDavid Boothからの貴重な貢献に謝意を表する。

この仕様は、RDFワーキンググループのメンバーによる 長期にわたる審議の成果物である。 これは、Dave Beckettが編集した[RDF-TESTCASES] の 以前の仕様を基礎としている。

D.2 RDF 1.2への謝辞

この節は非規範的である。

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

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

RDF & SPARQLワーキンググループのメンバーには、次の人々が含まれていた。
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の相違点

この節は非規範的である。

この仕様は、[N-TRIPLES] で 定義された元のN-Triples構文を拡張し、[RDF12-CONCEPTS] によって導入された 新機能をサポートする。 この拡張は完全に後方互換である。 旧バージョンに適合する任意の文書は新バージョンにも適合し、同じグラフへ解析される。 さらに、新バージョンに適合し、RDF 1.1の機能のみを含む任意の文書も、 旧バージョンに適合する （VERSIONディレクティブを除く。2.2 バージョン宣言を参照）。 最後に、新しい構文構造はいずれも旧構文では妥当ではない。 これは、RDF 1.2の機能を使用する任意のN-Triples文書が、 この仕様の以前のバージョンに適合せず、その下で別のグラフとして 解釈されることもないことを意味する。

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

F. 索引

この節は非規範的である。

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

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

G. 課題の概要

この節は非規範的である。

この仕様には課題が記載されていない。

H. 参考文献

H.1 規範的参考文献

[BCP47]
言語を識別するためのタグ. A. Phillips, Ed.; M. Davis, Ed. IETF. 2009年9月. 最新実務慣行. URL: https://www.rfc-editor.org/rfc/rfc5646
[EBNF-NOTATION]
EBNF記法. 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]
国際化用語集. Richard Ishida; Addison Phillips. W3C. 2024年10月17日. W3Cワーキンググループノート. URL: https://www.w3.org/TR/i18n-glossary/
[RDF12-CONCEPTS]
RDF 1.2の概念および抽象データ モデル. Andy Seaborne; Gregg Kellogg; Olaf Hartig; Pierre-Antoine Champin. W3C. 2026年 4月7日. W3C候補勧告. URL: https://www.w3.org/TR/rdf12-concepts/
[RDF12-TURTLE]
RDF 1.2 Turtle. Gregg Kellogg; Andy Seaborne; Dominik Tomaszuk. W3C. 2026年6月12日. W3C作業草案. URL: https://www.w3.org/TR/rdf12-turtle/
[RFC2119]
RFCにおいて要件レベルを示すために用いる キーワード. S. Bradner. IETF. 1997年3月. 最新実務慣行. URL: https://www.rfc-editor.org/rfc/rfc2119
[RFC3629]
UTF-8、ISO 10646の変換形式. F. Yergeau. IETF. 2003年11月. インターネット標準. URL: https://www.rfc-editor.org/rfc/rfc3629
[RFC3986]
統一リソース識別子（URI）: 汎用 構文. T. Berners-Lee; R. Fielding; L. Masinter. IETF. 2005年1月. インターネット 標準. URL: https://www.rfc-editor.org/rfc/rfc3986
[RFC3987]
国際化リソース識別子 （IRI）. M. Duerst; M. Suignard. IETF. 2005年1月. 提案標準. URL: https://www.rfc-editor.org/rfc/rfc3987
[RFC6906]
'profile'リンク関係型. E. Wilde. IETF. 2013年3月. 情報提供. URL: https://www.rfc-editor.org/rfc/rfc6906
[RFC8174]
RFC 2119キーワードにおける大文字と小文字の曖昧性. B. Leiba. IETF. 2017年5月. 最新実務慣行. URL: https://www.rfc-editor.org/rfc/rfc8174
[UNICODE]
Unicode標準. Unicode Consortium. URL: https://www.unicode.org/versions/latest/
[XML11]
拡張可能マークアップ言語（XML）1.1（第2 版）. 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-TRIPLES]
RDF 1.1 N-Triples. Gavin Carothers; Andy Seaborne. W3C. 2014年2月25日. W3C勧告. URL: https://www.w3.org/TR/n-triples/
[RDF-TESTCASES]
RDFテストケース. jan grant; Dave Beckett. W3C. 2004年2月10日. W3C勧告. URL: https://www.w3.org/TR/rdf-testcases/
[RDF12-INTEROP]
RDF 1.2相互運用性. Pierre-Antoine Champin. W3C. W3C編集者草案. URL: https://w3c.github.io/rdf-interop/spec/
[RDF12-N-QUADS]
RDF 1.2 N-Quads. Gregg Kellogg; Dominik Tomaszuk. W3C. 2026年6月12日. W3C作業草案. URL: https://www.w3.org/TR/rdf12-n-quads/
[RDF12-NEW]
RDF 1.2の新機能. The W3C RDF & SPARQL Working Group. W3C. W3C編集者草案. URL: https://w3c.github.io/rdf-new/spec/
[RDF12-PRIMER]
RDF 1.2入門. Pierre-Antoine Champin; Niklas Lindström. W3C. 2026年4月16日. DNOTE. URL: https://www.w3.org/TR/rdf12-primer/
[RDF12-SCHEMA]
RDF 1.2スキーマ. Dominik Tomaszuk. W3C. 2026年3月28日. W3C作業草案. URL: https://www.w3.org/TR/rdf12-schema/
[RDF12-SEMANTICS]
RDF 1.2意味論. Peter Patel-Schneider; Enrico Franconi; Dörthe Arndt. W3C. 2026年4月7日. W3C候補勧告. URL: https://www.w3.org/TR/rdf12-semantics/
[RDF12-TRIG]
RDF 1.2 TriG. Gregg Kellogg; Dominik Tomaszuk. W3C. 2026年6月12日. W3C作業草案. URL: https://www.w3.org/TR/rdf12-trig/
[RDF12-XML]
RDF 1.2 XML構文. Gregg Kellogg; Jerven Bolleman. W3C. 2026年6月18日. W3C作業草案. URL: https://www.w3.org/TR/rdf12-xml/
[RFC3023]
XMLメディア型. M. Murata; S. St. Laurent; D. Kohn. IETF. 2001年1月. 提案標準. URL: https://www.rfc-editor.org/rfc/rfc3023
[RFC4288]
メディア型仕様および登録 手続き. N. Freed; J. Klensin. IETF. 2005年12月. 最新実務慣行. URL: https://www.rfc-editor.org/rfc/rfc4288
[RFC7231]
ハイパーテキスト転送プロトコル（HTTP/1.1）: 意味論および内容. R. Fielding, Ed.; J. Reschke, Ed. IETF. 2014年6月. 提案標準. URL: https://httpwg.org/specs/rfc7231.html
[SPARQL12-CONCEPTS]
SPARQL 1.2の概念. The W3C RDF & SPARQL Working Group. W3C. W3C編集者草案. URL: https://w3c.github.io/sparql-concepts/spec/
[SPARQL12-ENTAILMENT]
SPARQL 1.2含意レジーム. Peter Patel-Schneider. W3C. 2026年4月9日. W3C作業草案. URL: https://www.w3.org/TR/sparql12-entailment/
[SPARQL12-FEDERATED-QUERY]
SPARQL 1.2連合 クエリ. 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グラフストア プロトコル. Andy Seaborne; Thomas Pellissier Tanon. W3C. 2024年12月19日. W3C 作業草案. URL: https://www.w3.org/TR/sparql12-graph-store-protocol/
[SPARQL12-NEW]
SPARQL 1.2の新機能. The W3C RDF & SPARQL Working Group. W3C. W3C編集者草案. URL: https://w3c.github.io/sparql-new/spec/
[SPARQL12-PROTOCOL]
SPARQL 1.2プロトコル. 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クエリ言語. Olaf Hartig; Andy Seaborne; Ruben Taelman; Gregory Williams; Thomas Pellissier Tanon. W3C. 2026年6月17日. W3C作業草案. URL: https://www.w3.org/TR/sparql12-query/
[SPARQL12-RESULTS-CSV-TSV]
SPARQL 1.2クエリ結果CSVおよびTSV 形式. 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クエリ結果JSON 形式. 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クエリ結果XML 形式. 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サービス 記述. Ruben Taelman; Gregory Williams. W3C. 2026年4月23日. W3C作業 草案. URL: https://www.w3.org/TR/sparql12-service-description/
[SPARQL12-UPDATE]
SPARQL 1.2更新. Ruben Taelman; Andy Seaborne; Thomas Pellissier Tanon. W3C. 2026年6月12日. W3C作業草案. URL: https://www.w3.org/TR/sparql12-update/
[UNICODE-SECURITY]
Unicodeセキュリティの 考慮事項. Mark Davis; Michel Suignard. Unicode Consortium. 2014年9月19日. Unicode技術報告 #36. URL: https://www.unicode.org/reports/tr36/tr36-15.html