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] … 메시지 주제 …를 포함 (아카이브)

초록

N-Triples는 RDF 그래프를 인코딩하기 위한 줄 기반의 일반 텍스트 형식입니다.

RDF 1.2 N-Triples는 트리플 용어를 네 번째 종류의 RDF 용어로 도입하며, 이는 다른 트리플객체로 사용될 수 있어, 다른 문장에 대한 문장을 만들 수 있게 합니다. RDF 1.2 N-Triples는 또한 방향성이 있는 언어 태그 문자열에 대한 지원도 추가합니다.

이 문서의 상태

이 절은 발행 당시 이 문서의 상태를 설명합니다. 현재 W3C 발행물 목록과 이 기술 보고서의 최신 개정판은 W3C 표준 및 초안 색인에서 확인할 수 있습니다.

이 문서는 RDF 1.2 문서 모음의 일부입니다. N-Triples 형식은 Turtle [RDF12-TURTLE]의 하위 집합에 기반한 줄 기반 RDF 구문입니다.

W3C 후보 권고안 단계를 종료하려면, W3C RDF & SPARQL 워킹 그룹은 최소 두 개의 독립적인 구현이 전용 테스트 스위트의 각 테스트를 통과할 것을 요구합니다.

이 문서는 RDF & SPARQL 워킹 그룹에 의해 권고안 트랙을 사용하여 작업 초안으로 발행되었습니다.

작업 초안으로 발행되었다고 해서 W3C 및 그 회원의 지지를 의미하지는 않습니다.

이 문서는 초안 문서이며 언제든지 다른 문서에 의해 갱신, 대체 또는 폐기될 수 있습니다. 이 문서를 진행 중인 작업 이외의 것으로 인용하는 것은 적절하지 않습니다. 이 향후 권고안의 미래 업데이트에는 새 기능이 포함될 수 있습니다.

이 문서는 W3C 특허 정책에 따라 운영되는 그룹에 의해 작성되었습니다. W3C는 해당 그룹의 산출물과 관련하여 이루어진 특허 공개의 공개 목록을 유지합니다. 해당 페이지에는 특허 공개에 대한 지침도 포함되어 있습니다. 개인이 자신이 알고 있는 특허가 필수 청구항을 포함한다고 믿을 실제 지식을 가지고 있는 경우, W3C 특허 정책 제6절에 따라 해당 정보를 공개해야 합니다.

이 문서는 2025년 8월 18일 W3C Process Document의 적용을 받습니다.

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 버전을 선언하기 위한 한 종류의 파싱 지시문을 포함할 수 있습니다. 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, 또는 인코딩되지 않은 문자 중 하나로만 표현될 수 있습니다. 각 트리플은 지정된 공백 문자와 함께 완전히 한 줄에 표현됩니다.

정규 N-Triples에는 레이아웃에 대해 다음 추가 제약 조건이 있습니다.

4. 適合性

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

この文書におけるキーワード MAYMUSTMUST 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 용어 또는 그 구성 요소(예: 언어 태그, 리터럴의 어휘 형식)에 매핑함으로써 트리플 스트림에 매핑합니다. 문법 생성 규칙은 파서 상태를 변경하고 트리플을 방출합니다.

입력에서 오류를 감지한 프로세서는 이를 오류 또는 경고로 신호해야 MUST 합니다. 이 명세는 프로세서의 정확한 출력을 정의하지 않으며, 트리플이 전혀 방출되는지 여부도 포함됩니다. 모든 출력은 오류가 없는 입력 영역을 파싱하여 방출된 트리플의 하위 집합만 포함해야 SHOULD 합니다.

참고

이 명세의 이전 버전들은 인식되지 않은 입력에 대한 동작을 명시하지 않았지만, 워킹 그룹에 알려진 모든 구현은 이미 위의 요구사항과 일관되게 동작합니다. 특히 이러한 구현은 VERSION 지시문을 포함하여 이전 버전에서 인식되지 않는 RDF 1.2 전용 구문을 만나면 오류를 신호합니다. 이러한 구문을 조용히 무시하거나 잘못 해석하지 않습니다.

6.1 파서 상태

N-Triples를 파싱하려면 두 항목으로 된 상태가 필요합니다.

6.2 RDF 용어 생성자

이 표는 생성 규칙과 어휘 토큰을 RDF 용어 또는 RDF 용어의 구성 요소에 매핑하며, 이는 6. 파싱에 나열되어 있습니다.

생성 규칙 유형 절차
versionSpecifier 리터럴 curVersion은 일치한 RDF 문자열 어휘 형식과 xsd:string 데이터타입을 사용하는 리터럴에서 가져옵니다.
BLANK_NODE_LABEL 빈 노드 _: 뒤의 문자열은 bnodeLabels의 키입니다. 맵에 해당하는 빈 노드가 없으면, 하나가 할당됩니다.
IRIREF IRI <> 사이의 문자를 가져오고, 이스케이프 시퀀스를 이스케이프 해제하여 IRI를 형성합니다. 결과 IRI는 일반 IRI 구문의 구문상 제한을 준수해야 MUST 하며, [RFC3986]의 3.3절을 따라야 SHOULD 하고, 해당 IRI 스킴 명세가 부과하는 더 좁은 제한도 준수해야 합니다.
LANG_DIR 언어 태그 @ 뒤의 문자는 언어 태그와, 일치한 문자에 --가 포함된 경우 선택적으로 초기 텍스트 방향을 형성합니다. 언어 태그는 [BCP47]의 2.2.9절에 따라 올바른 형식이어야 MUST 합니다. 존재하는 경우, 초기 텍스트 방향ltr 또는 rtl이어야 MUST 합니다.
STRING_LITERAL_QUOTE 어휘 형식 가장 바깥쪽 따옴표(") 사이의 문자를 가져오고, 이스케이프 시퀀스를 이스케이프 해제하여, 어휘 형식문자열을 형성합니다.
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 생성 규칙에서 구성된 용어들로 이루어집니다.

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 문서에서 가져온 문자열을 렌더링하거나, 이스케이프되지 않은 문자를 사용하는 애플리케이션은 악의적인 문자열이 독자를 오도하는 데 사용될 가능성을 제한하기 위해 경고 및 기타 적절한 수단을 사용해야 SHOULD 합니다. XML의 미디어 유형 등록에 있는 보안 고려사항([RFC3023] 10절)은 임의 데이터와 마크업의 표현에 대한 추가 지침을 제공합니다.

N-Triples는 용어 식별자로 IRI를 사용합니다. N-Triples로 표현된 데이터를 해석하는 애플리케이션은 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-Triples에서 데이터를 작성하거나 해석하는 모든 사람 또는 애플리케이션은 의도된 의미에 맞는 IRI를 사용하고, 비슷하게 보일 수 있는 IRI를 피하도록 주의해야 합니다. 시각적으로 유사한 문자 매칭에 대한 추가 정보는 Unicode Security Considerations [UNICODE-SECURITY] 및 Internationalized Resource Identifiers (IRIs) [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 매개변수를 제공한 경우, 클라이언트는 이를 무시하도록 선택할 수 있습니다.

참고

profile URI는 역참조 가능하고 해당 URI에서 유용한 문서를 제공하는 것이 권장됩니다.

참고

미디어 유형 매개변수로 [RFC4288]가 HTTP Content-Type 헤더 또는 HTTP Accept 헤더 [RFC7231]에서 사용될 때, profile 매개변수의 값에 공백처럼 특수 문자가 포함되어 있으면 따옴표(ASCII ")로 묶어야 합니다. 여기에는 여러 profile URI를 구분하는 데 사용되는 공백도 포함됩니다.

profile 매개변수의 값은 하나 이상의 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 Working Group 구성원들의 장기간에 걸친 논의의 산물입니다. 이 명세는 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, and 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, and 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]
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 외. W3C. W3C Recommendation. 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-TURTLE]
RDF 1.2 Turtle. Gregg Kellogg; Andy Seaborne; Dominik Tomaszuk. W3C. 2026년 6월 12일. W3C Working Draft. 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 외. W3C. 2006년 8월 16일. W3C Recommendation. 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 Recommendation. URL: https://www.w3.org/TR/n-triples/
[RDF-TESTCASES]
RDF Test Cases. jan grant; Dave Beckett. W3C. 2004년 2월 10일. W3C Recommendation. URL: https://www.w3.org/TR/rdf-testcases/
[RDF12-INTEROP]
RDF 1.2 Interoperability. Pierre-Antoine Champin. W3C. W3C Editor's Draft. 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 Working Draft. URL: https://www.w3.org/TR/rdf12-n-quads/
[RDF12-NEW]
What’s New in RDF 1.2. The W3C RDF & SPARQL Working Group. W3C. W3C Editor's Draft. 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 Working Draft. 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년 6월 12일. W3C Working Draft. URL: https://www.w3.org/TR/rdf12-trig/
[RDF12-XML]
RDF 1.2 XML Syntax. Gregg Kellogg; Jerven Bolleman. W3C. 2026년 6월 18일. W3C Working Draft. 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 Editor's Draft. URL: https://w3c.github.io/sparql-concepts/spec/
[SPARQL12-ENTAILMENT]
SPARQL 1.2 Entailment Regimes. Peter Patel-Schneider. W3C. 2026년 4월 9일. W3C Working Draft. 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 Working Draft. 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 Working Draft. 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 Editor's Draft. 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 Working Draft. 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년 6월 17일. W3C Working Draft. 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 Working Draft. 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 Working Draft. 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 Working Draft. 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 Working Draft. URL: https://www.w3.org/TR/sparql12-service-description/
[SPARQL12-UPDATE]
SPARQL 1.2 Update. Ruben Taelman; Andy Seaborne; Thomas Pellissier Tanon. W3C. 2026년 6월 12일. W3C Working Draft. 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