RDF 1.2 Turtle

簡潔な RDF トリプル言語

W3C 作業草案

この文書の詳細
このバージョン:
https://www.w3.org/TR/2026/WD-rdf12-turtle-20260812/
最新公開バージョン:
https://www.w3.org/TR/rdf12-turtle/
最新編集者草案:
https://w3c.github.io/rdf-turtle/spec/
履歴:
https://www.w3.org/standards/history/rdf12-turtle/
コミット履歴
テストスイート:
https://w3c.github.io/rdf-tests/rdf/rdf12/rdf-turtle/
最新の勧告:
https://www.w3.org/TR/turtle
編集者:
Gregg Kellogg (2025-09-06 まで), 追悼
Andy Seaborne
Dominik Tomaszuk
以前の編集者:
Eric Prud'hommeaux (RDF 1.1)
Gavin Carothers (RDF 1.1)
著者:
David Beckett
Tim Berners-Lee (W3C)
Eric Prud'hommeaux (W3C)
Gavin Carothers (Lex Machina, Inc)
フィードバック:
GitHub w3c/rdf-turtle (プルリクエスト, 新しい課題, 未解決の課題)
public-rdf-star-wg@w3.org 件名行を [rdf12-turtle] … メッセージのトピック … としてください (アーカイブ)

要約

Resource Description Framework (RDF) は、 Web における情報を表現するための汎用言語です。

この文書は、Turtle と呼ばれる RDF のテキスト構文を 定義します。これは、RDF グラフを 一般的な使用パターンおよびデータ型の省略記法を備えた、コンパクトで 自然なテキスト形式で完全に記述できるようにするものです。 Turtle は、 N-Triples [RDF12-N-TRIPLES] 形式、および SPARQL 1.2 Query Language W3C 勧告のトリプルパターン構文との互換性レベルを提供します。

RDF 1.2 Turtle は、別の トリプルオブジェクト として使用できる、 RDF 用語の 第四の種類として トリプル 用語 を導入し、他の文について文を作成できるようにします。 トリプル 用語は、一般に reifiedTriple 構造が好まれるため、 明示的には通常使用されません。 RDF 1.2 Turtle は、 方向付き言語タグ付き文字列のサポートも追加します。

さらに、RDF 1.2 Turtle は、 注釈構文を導入します。これにより、 トリプル 用語も表明できるようになります。

この文書のステータス

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

この文書は、RDF 1.2 文書群の一部です。 この文書は、RDF [RDF12-CONCEPTS] の具体構文である、 簡潔な RDF トリプル言語 Turtle を定義します。

この文書は、RDF & SPARQL Working Group により、 勧告 トラックを用いた作業草案として公開されました。

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

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

この文書は、 W3C 特許 ポリシーの下で活動するグループによって作成されました。 W3C は、 そのグループの成果物に関連して行われた 特許 開示の公開一覧を管理しています。 そのページには、特許を開示するための手順も含まれています。 ある個人が、当該個人が 必須クレーム を含むと考える特許について実際の知識を有している場合、 その情報は W3C 特許ポリシー第6節に従って開示しなければなりません。

この文書は、 2025年8月18日版 W3C Process Document によって管理されます。

1. はじめに

この節は非規範的です。

この文書は、RDF [RDF12-CONCEPTS] の具体構文である、 簡潔な RDF トリプル言語 Turtle を定義します。

Turtle 文書は、RDF グラフのテキスト表現です。 次の Turtle 文書は、Green Goblin と Spiderman の関係を説明しています。

1: Turtle の例

BASE <http://example.org/>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX rel: <http://www.perceive.net/schemas/relationship/>
PREFIX dct: <http://purl.org/dc/terms/>

<#green-goblin>
  rel:enemyOf <#spiderman> ;
  a foaf:Person ;    # in the context of the Marvel universe
  foaf:name "Green Goblin" .

<#spiderman>
  rel:enemyOf <#green-goblin> ;
  a foaf:Person ;
  foaf:name "Spiderman",
   "الرجل العنكبوت"@ar--rtl {| dct:source <https://www.wikidata.org/> |}.

この例では、Turtle 言語の多くの機能を紹介します。 BASE および相対 IRI 参照PREFIX および接頭辞付き名前;で区切られた述語リスト,で区切られた目的語リスト、 トークン aリテラル、 および注釈です。

triples の Turtle 文法は、SPARQL 1.2 クエリ言語 [SPARQL12-QUERY] の TriplesBlock 文法のサブセットです。 2 つの文法は、可能な場合には生成規則名および終端記号名を共有します。

Turtle 文書からのRDF グラフの構築は、 Turtle 文法 および構文解析で定義されています。

このバージョンの Turtle は、以前のバージョンである RDF 1.1 Turtle と、構文的にも意味的にも完全な後方互換性があります。

2. Turtle 言語

この節は非規範的です。

Turtle 文書は、RDF グラフをコンパクトなテキスト形式で書き表すことを可能にします。 RDF グラフは、主語、述語、およびオブジェクトからなる トリプルで 構成されます。

コメントは、別の字句トークンの一部ではない # の後に続くことができ、行末まで続きます。

2.1 単純なトリプル

最も単純なトリプル文は、 (主語述語、 および オブジェクト) 用語の列であり、 RDF トリプル を形成し、ピリオド (.) で終了します。 空白 (スペースタブLF、および/または CR) は、文法で重要と明記されている場合を除き、 用語の周囲に現れてもかまいません。

2: 単純な トリプル

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

2.2 述語リスト

同じ主語が複数の述語によって参照されることがよくあります。 predicateObjectList 生成規則は、 主語に続く、; で区切られた一連の述語およびオブジェクトに一致します。 これは、その主語を持ち、 各述語 およびオブジェクトが1つのトリプルに割り当てられる、一連の RDF トリプルを表します。 したがって、; は、述語およびオブジェクトの RDF 用語のみが異なる トリプルの主語を繰り返すために使用されます。

これら2つの例は、Spiderman についてのトリプルを書く等価な方法です。

3: 述語リスト

<http://example.org/#spiderman> <http://www.perceive.net/schemas/relationship/enemyOf> <http://example.org/#green-goblin> ;
  <http://xmlns.com/foaf/0.1/name> "Spiderman" .
4: 単純なトリプルに展開された述語リスト

<http://example.org/#spiderman> <http://www.perceive.net/schemas/relationship/enemyOf> <http://example.org/#green-goblin> .
<http://example.org/#spiderman> <http://xmlns.com/foaf/0.1/name> "Spiderman" .

2.3 オブジェクトリスト

述語と同様に、同じ主語および述語が異なるオブジェクトとともに繰り返されることがよくあります。 objectList 生成規則は、 述語に続く、, で区切られた一連のオブジェクトに 一致します。 これは、同じ主語 および述語を持ち、 各オブジェクトが1つのトリプルに割り当てられる、一連の RDF トリプルを表します。 したがって、, は、オブジェクトの RDF 用語 のみが異なるトリプルの主語および述語を繰り返すために使用されます。

これら2つの例は、Spiderman の名前を2つの言語で書く等価な方法です。

5: オブジェクト リスト

<http://example.org/#spiderman> <http://xmlns.com/foaf/0.1/name> "Spiderman", "Человек-паук"@ru .
6: 単純なトリプルに展開されたオブジェクトリスト

<http://example.org/#spiderman> <http://xmlns.com/foaf/0.1/name> "Spiderman" .
<http://example.org/#spiderman> <http://xmlns.com/foaf/0.1/name> "Человек-паук"@ru .

RDF Concepts では、4つの RDF 用語 が定義されています: IRI (国際化 資源識別子)、 リテラル空白 ノード、および トリプル 用語です。 Turtle は、それぞれを書くための多数の方法を提供します。

2.4 バージョン宣言

Turtle 言語はその起源以来進化しており、RDF 1.2 は新しい構文を追加します。 RDF 1.2 Turtle は、任意の version メディア型パラメーターとともに、 VERSION および @version 指令を導入します。 初期テキスト方向トリプル 用語などの新機能を含む Turtle をシリアライズする場合、 著者はこれらの指令を使用して新しい構文形式の使用を宣言できます。

7: バージョン宣言

VERSION "1.2"
PREFIX : <http://example.com/>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
:a :name "Alice" ~ :t {| :statedBy :bob ; :recorded "2021-07-07"^^xsd:date |} .

あるいは、旧式の指令を使用できます (末尾に "." があることに注意してください):

8: 旧式の バージョン宣言

@version "1.2" .
@prefix : <http://example.com/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
:a :name "Alice" ~ :t {| :statedBy :bob ; :recorded "2021-07-07"^^xsd:date |} .

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

9: Turtle バージョン 1.2 を宣言する HTTP 応答

HTTP/1.1 200 OK
Content-Type: text/turtle; version=1.2

RDF 1.2 固有の機能( 初期テキスト方向など)を使用する場合、 文書の早い段階で、特定の RDF バージョンを VERSION または @version ディレクティブのいずれかを使用して宣言する必要があります。 これにより、これらの機能をサポートしていないパーサーは、 それらが存在する可能性を早期に検出し、必要に応じて ユーザーに通知できます。これによりユーザーは、処理を停止するか、 出力データが予想される出力の サブセットとなる可能性があるという事実に基づいて別の対応を行う機会を得られます。

1 つの Turtle 文書内に複数のバージョンディレクティブを記述できます。 ディレクティブは、そのディレクティブより後の文書部分に適用され、 別のディレクティブが検出されるか、文書の末尾に達するまで有効です。

現在のバージョンディレクティブがない場合、メディアタイプの一部として指定されたバージョンが考慮されます。 いずれの場合も、バージョンの宣言はヒントです。 パーサーは、宣言されたバージョンの範囲外にある機能を拒否する必要はありません (ただし、警告によってそれらを通知することはできます)。

注記
バージョンラベルは、RDF 1.2 Concepts and Abstract Data Model2.1 Version Labels 節で定義されています。 処理器は、認識されないラベルをエラーまたは警告として扱ってもかまいません。

"1.1" は許容されるバージョンラベルですが、 VERSION または @version 指令でこれを使用することは推奨されません。 これは Turtle 1.1 パーサーを不必要に失敗させるためです。

2.5 IRI

IRI は、 解決済み IRI、 相対 IRI 参照、 または 接頭辞付き名前として書くことができます。 相対 IRI および解決済み IRI は、< で始まり、 > で終わり、 数値エスケープシーケンス (後述) を含んでもかまいません。 例: <http://example.org/#green-goblin>

<#green-goblin> のような 相対 IRI 参照は、 現在の基底 IRI を基準に解決されます。 新しい基底 IRI は、@base または BASE 指令を使用して定義できます。 この操作の詳細は、 6.3 IRI 参照で定義されます。

Turtle トリプルの述語位置にあるトークン a は、 IRI http://www.w3.org/1999/02/22-rdf-syntax-ns#type を表します。

接頭辞付き名前は、 接頭辞ラベルと ローカル部を : で区切ったものです。 接頭辞付き名前は、接頭辞に関連付けられた IRI とローカル部を連結することで IRI に変換されます。 @prefix または PREFIX 指令は、 接頭辞ラベルを IRI に関連付けます。 後続の @prefix または PREFIX 指令は、同じ接頭辞ラベルを再割り当てしてもかまいません。

注記

Turtle 言語は当初、接頭辞および基底指令を書くために @ 文字を含む構文のみを許可していました。 大文字小文字を区別しない PREFIXBASE、および VERSION 形式は、Turtle の構文を SPARQL の構文と整合させるために追加されました。 元の指令 @prefix@base、または @version も 使用できます。 PREFIXBASE、および VERSION を使用すると、宣言を SPARQL クエリへコピーしやすくなる場合があります。

http://www.perceive.net/schemas/relationship/enemyOf を接頭辞付き名前で書くには:

  1. 語彙 IRI http://www.perceive.net/schemas/relationship/ に対する接頭辞ラベルを somePrefix として定義します
  2. 次に somePrefix:enemyOf と書きます。これは <http://www.perceive.net/schemas/relationship/enemyOf> と書くことと等価です

これは、接頭辞宣言に対する SPARQL スタイルの構文を使用して書けます:

10: 接頭辞宣言の SPARQL 構文

PREFIX somePrefix: <http://www.perceive.net/schemas/relationship/>

<http://example.org/#green-goblin> somePrefix:enemyOf <http://example.org/#spiderman> .

または、接頭辞宣言に対する元の Turtle 構文を使用して書けます:

11: 接頭辞宣言の 元の構文

@prefix somePrefix: <http://www.perceive.net/schemas/relationship/> .

<http://example.org/#green-goblin> somePrefix:enemyOf <http://example.org/#spiderman> .
注記

接頭辞付き名前は、XML QName のスーパーセットです。 これらは、接頭辞付き名前のローカル部が次を含んでもよい点で異なります:

次の Turtle 文書は、Turtle で IRI を書くさまざまな方法のすべての例を含んでいます。

12: IRI を書くさまざまな方法

# A triple with all resolved IRIs
<http://one.example/subject1> <http://one.example/predicate1> <http://one.example/object1> .

@base <http://one.example/> .
<subject2> <predicate2> <object2> .     # relative IRI references, e.g., http://one.example/subject2

BASE <http://one.example/>
<subject2> <predicate2> <object2> .     # relative IRI references, e.g., http://one.example/subject2

@prefix p: <http://two.example/> .
p:subject3 p:predicate3 p:object3 .     # prefixed name, e.g., http://two.example/subject3

PREFIX p: <http://two.example/>
p:subject3 p:predicate3 p:object3 .     # prefixed name, e.g., http://two.example/subject3

@prefix p: <path/> .                    # prefix p: now stands for http://one.example/path/
p:subject4 p:predicate4 p:object4 .     # prefixed name, e.g., http://one.example/path/subject4

PrEfIx : <http://another.example/>       # empty prefix
:subject5 :predicate5 :object5 .        # prefixed name, e.g., http://another.example/subject5

:subject6 a :subject7 .                 # same as :subject6 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> :subject7 .

<http://伝言.example/?user=أ&channel=R%26D> a :subject8 . # a multi-script subject IRI .
注記

@prefix および @base 指令では、 IRI の後に末尾の . が必要ですが、 等価な PREFIX および BASE では、指令の IRI 部分の後に末尾の . はありません。 PREFIX および BASE は大文字小文字を区別せず、 prefix および base として、または大文字小文字を混在させた任意の形で書くことができます。

2.6 RDF リテラル

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

13: Turtle における リテラル

PREFIX foaf: <http://xmlns.com/foaf/0.1/>

<http://example.org/#green-goblin> foaf:name "Green Goblin" .

<http://example.org/#spiderman> foaf:name "Spiderman" .

2.6.1 引用符付きリテラル

引用符付きリテラル (文法生成規則 RDFLiteral) は、字句形式に続いて、 言語タグ (場合により 初期テキスト方向を含む)、 データ型 IRI、またはそのどちらも持たないものです。

字句形式の表現は、開始区切り文字 (例: "'"""、または '''); 許可された文字、数値エスケープシーケンス、 および/または 文字列エスケープシーケンスの列、 ならびに開始区切り文字に対応する終了区切り文字で構成されます。 対応する RDF 字句 形式 は、エスケープシーケンスを処理した後の、区切り文字の間の文字です。

存在する場合、言語タグの前には @ が置かれ、言語タグから -- で区切られた 初期テキスト方向 が後続してもかまいません。

言語タグがない場合、 データ型 IRI が存在してもかまいません。 その前には ^^ が置かれます。 Turtle におけるデータ型 IRI は、 解決済み IRI相対 IRI 参照、 または 接頭辞付き名前のいずれかを使用して書くことができます。

データ型 IRI も言語タグもない場合、 データ型は xsd:string です。

\ は、 エスケープシーケンスの一部である場合を除き、引用符付きリテラル内に出現できない。 その他の制限は区切り文字によって異なる。

  • ' で区切られたリテラルには、 エスケープされていない 'LF、または CR 文字を含めることはできない。
  • " で区切られたリテラルには、 エスケープされていない "LF、または CR 文字を含めることはできない。
  • ''' で区切られたリテラルには、そのような シーケンスを含めることはできない。
  • """ で区切られたリテラルには、そのような シーケンスを含めることはできない。
14: 引用符付きリテラル

VERSION "1.2"
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX show: <http://example.org/vocab/show/>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>

show:218 rdfs:label "That Seventies Show"^^xsd:string .                # literal with XML Schema string datatype
show:218 rdfs:label "That Seventies Show"^^<http://www.w3.org/2001/XMLSchema#string> . # same as above
show:218 rdfs:label "That Seventies Show" .                                            # same again
show:218 show:localName "That Seventies Show"@en .                     # literal with a language tag
show:218 show:localName "HTML היא שפת סימון."@he--rtl .                # literal with a language tag and initial text direction
show:218 show:localName "That Seventies Show"@en-us--ltr .             # literal with a language tag, region subtag, and initial text direction
show:218 show:localName 'Cette Série des Années Soixante-dix'@fr .     # literal delimited by single quote
show:218 show:localName "Cette Série des Années Septante"@fr-be .      # literal with a region subtag
show:218 show:blurb '''This is a multi-line
                       literal with many quotes (""""")
                       and up to two sequential apostrophes ('').''' . # literal with embedded new lines and quotes

2.6.2 数値

数値は、字句形式およびデータ型を持つ他のリテラルと同様に書くことができます (例: "-5.0"^^xsd:decimal)。 Turtle には、整数値、 任意精度の10進数値、および倍精度浮動小数点値を書くための省略構文があります。

データ型 省略形 字句形式 説明
xsd:integer -5 "-5"^^xsd:integer 整数値は、任意の符号と一連の数字として書くことができます。 整数は正規表現 "[+-]?[0-9]+" に一致します。
xsd:decimal -5.0 "-5.0"^^xsd:decimal 任意精度の10進数は、任意の符号、 0個以上の数字、 小数点、および1個以上の数字として書くことができます。 10進数は正規表現 "[+-]?[0-9]*\.[0-9]+" に一致します。
xsd:double 4.2E9 "4.2E9"^^xsd:double 倍精度浮動小数点値は、 任意の符号を持つ仮数、小数点の有無、 文字 e または文字 E、 および任意の符号を持つ整数指数として書くことができます。 指数は正規表現 "[+-]?[0-9]+" に一致し、仮数は次のいずれかの正規表現に一致します: "[+-]?[0-9]+\.[0-9]+"、 "[+-]?\.[0-9]+"、 または "[+-]?[0-9]"。
15: 数値 リテラル

PREFIX : <http://example.org/elements/>
<http://en.wikipedia.org/wiki/Helium>
    :atomicNumber 2 ;               # xsd:integer
    :atomicMass 4.002602 ;          # xsd:decimal
    :specificGravity 1.663E-4 .     # xsd:double

2.6.3 真偽値

真偽値は、true または false (大文字小文字を区別) のいずれかとして書くことができ、 データ型 xsd:boolean [XMLSCHEMA11-2] を持つ RDF リテラルを表します。

16: 真偽値 リテラル

PREFIX : <http://example.org/stats/>
<http://somecountry.example/census2007>
    :isLandlocked false .           # xsd:boolean

2.7 RDF 空白ノード

Turtle における RDF 空白 ノードは、 _: に続けて、 文字の列である 空白ノード識別子として表されます。 識別子内の文字は PN_CHARS_BASE に基づき、次のように緩和されています:

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

17: Turtle における 空白ノード

PREFIX foaf: <http://xmlns.com/foaf/0.1/>

_:alice foaf:knows _:bob .
_:bob foaf:knows _:alice .

2.8 空白ノード識別子を持たない 空白 ノードの入れ子

Turtle では、 blankNodePropertyList 生成規則および終端 ANON に一致する場合にも、新しい RDF 空白 ノードが割り当てられます。 これらはいずれも、トリプルの subject または object 位置に現れてもかまいません (Turtle 文法を参照)。 その主語またはオブジェクトは、新しい RDF 空白 ノードです。 この空白ノードは、blankNodePropertyList 内に埋め込まれた predicateObjectList 生成規則に一致することで 生成されるトリプルの主語としても機能します。 これらのトリプルの生成は、 述語リストで説明されています。 空白ノードは、後述のコレクションにも割り当てられます。

18: 空白ノードプロパティリスト
  
  PREFIX foaf: <http://xmlns.com/foaf/0.1/>

  # Someone knows someone else, who has the name "Bob".
  [] foaf:knows [ foaf:name "Bob" ] .

Turtle 文法では、 blankNodePropertyList を 入れ子にすることができます。 この場合、内側の各 [ は新しい主語 空白ノードを確立し、 ] で外側のノードに戻り、 述語オブジェクトリストに対する現在の主語として機能します。

blankNodePropertyList 内で predicateObjectList を使用することは、ノードの一連のプロパティを表すための一般的な慣用法です。

省略形: 対応する単純なトリプル:

PREFIX foaf: <http://xmlns.com/foaf/0.1/>

[ foaf:name "Alice" ] foaf:knows [
    foaf:name "Bob" ;
    foaf:knows [
        foaf:name "Eve" ] ;
    foaf:mbox <mailto:bob@example.com> ] .

_:a <http://xmlns.com/foaf/0.1/name> "Alice" .
_:a <http://xmlns.com/foaf/0.1/knows> _:b .
_:b <http://xmlns.com/foaf/0.1/name> "Bob" .
_:b <http://xmlns.com/foaf/0.1/knows> _:c .
_:c <http://xmlns.com/foaf/0.1/name> "Eve" .
_:b <http://xmlns.com/foaf/0.1/mbox> <mailto:bob@example.com> .

2.9 コレクション

RDF は、コレクション [RDF12-SCHEMA] 構造を、RDF ノードのリストのために提供します。 コレクションの Turtle 構文は、RDF 用語の空である可能性のあるリストを、() で囲んだものです。 このコレクションは、rdf:first/rdf:rest リスト構造を表し、rdf:first 文のオブジェクトの並びが、() で囲まれた用語の順序となります。

(…) 構文は、トリプルの subject または object 位置に 現れなければなりません (MUST) (Turtle 文法を参照)。 リストの先頭にある 空白 ノードは、それを含むトリプルの主語またはオブジェクトです。

21: Turtle における コレクション

PREFIX : <http://example.org/foo/>
# the object of this triple is the RDF collection blank node
:subject :predicate ( :a :b :c ) .

# an empty collection value - rdf:nil
:subject :predicate2 () .

2.10 トリプル用語

トリプル 用語は、 RDF トリプルオブジェクトに なってもかまいません。

トリプル 用語 は、ttSubjectpredicate、および ttObject を持つ tripleTerm として表され、 すべての前に <<( が置かれ、 すべての後に )>> が置かれます。 トリプル用語 は入れ子にできることに注意してください。

22: トリプル 用語

VERSION     "1.2"
PREFIX :    <http://www.example.org/>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>

_:e38  :familyName                     "Smith" .
_:anno rdf:reifies <<( _:e38 :jobTitle "Designer" )>> .
_:anno :accordingTo                     _:e22 .

2.11 トリプルの具象化

RDF では、 トリプル 用語が直接使用されることはまれです。 それらは一般に、rdf:reifies 述語を使用する トリプルオブジェクトとしてのみ 使用されるよう制限されるためです。 そのようなトリプルは、具象化トリプルと呼ばれます。 Turtle は、reifiedTriple 生成規則を使用して 具象化トリプル を書くための省略記法を提供します。

reifiedTriple は、具象化トリプルを表す構文糖です。 これは、識別子 (具象化子) と トリプル用語との特定の関係を定義します。 識別子は、トリプル用語を間接的に参照する方法になります。 そのトリプル用語は、この入力文書に対応するグラフ内で表明される場合もあれば、されない場合もあります。

注記

RDF 1.2 における具象化は、 具象化語彙とは異なる概念です。 後者は、もともと RDF Semantics で定義されました。 どちらの用語も、構成要素を用いた RDF トリプルの表現を説明しますが、 RDF 1.2 では、この用語を、 rdf:reifies 述語を使用して トリプル 用語 を識別するために使用します。

ある 具体化トリプルは、 reifiedTriple 生成規則を使用して表され、 << で始まり、 続いて rtSubjectpredicate、および rtObject が続き、 その後に省略可能な reifier が続きます。 これは、~ と、 それに続く省略可能な iri 生成規則 または BlankNode 生成規則で構成され、 最後に >> が続きます。 例えば、<< :subject :predicate :object ~ :IRIREF >> です。 reifier が存在しない場合、 または ~ の直後に iri または BlankNode が続かない場合は、 新しい RDF 空白 ノードが割り当てられます。 これは、<< :subject :predicate :object >>、 または << :subject :predicate :object ~ >> の場合と同様です。

注記

reifiedTriples は、 次のように入れ子にできます。
<< :subject1 :predicate1 << :subject2 :predicate2 :object2 >> ~:IRIREF1 >> または
<< :subject4 :predicate4 << :subject3 :predicate3 :object3 ~:IRIREF3 >> >>

23: 具象化 トリプル

VERSION     "1.2"
PREFIX :    <http://www.example.org/>

:employee38 :familyName "Smith" .
<< :employee38 :jobTitle "Assistant Designer" >> :accordingTo :employee22 .
24: 明示的な具象化子を持つ具象化トリプル

PREFIX :    <http://www.example.org/>

:employee38 :familyName "Smith" .
<< :employee38 :jobTitle "Assistant Designer" ~ _:id >> :accordingTo :employee22 .
たとえば、上の例の構文糖は次と等価です:
25: トリプル用語に展開された具象化トリプル

PREFIX :    <http://www.example.org/>

:employee38 :familyName "Smith" .
_:id rdf:reifies <<( :employee38 :jobTitle "Assistant Designer" )>> .
_:id :accordingTo :employee22 .
注記

reifiedTriple の構文糖 (すなわち << [...] >>) と、通常の tripleTerm (すなわち <<( [...] )>>) の構文の違いに注意してください。

IRI を省略できるように接頭辞を宣言した後、 この例の最初のトリプルは、employee38 が "Smith" という familyName を持つことを表明します。 このグラフは、employee38 が "Assistant Designer" という jobTitle を持つことを表明していないことに注意してください。 これは、employee22reifiedTriple を使用して その主張を行ったことを述べています。 言い換えると、"employee38 has a jobTitle of 'Assistant Designer'" というトリプルは、上の "employee38 has a familyName of 'Smith'" と同様に、 グラフ自体のメンバーではありません。 むしろ、それは 具象化トリプルとして知られます。

reifiedTriple は、 rdf:reifies 述語を使用して 具象化子tripleTerm に関連付ける構文糖です。

2.11.1 注釈構文

Turtle はまた、トリプルを具象化し、かつ表明するための 注釈 構文 を定義します。 これは便利なショートカットを提供します。 注釈は、明示的または暗黙的な識別子を介して トリプルを同時に表明し、 さらにそのトリプルを別のトリプルの 主語または オブジェクトに するために使用できます。 明示的に識別されている場合、同じ 具象化子を、 追加のトリプルおよび/または トリプル用語主語または オブジェクト として使用できます。

reifiedTriple と同様に、 注釈構文では、具体化される トリプル項を識別するために、 チルダ(~)を前置した、 IRI または 空白ノードとして記述される、 具体化子を使用します。 ただし、 reifiedTriple が含むことのできる 具体化子は最大で 1 つですが、注釈構文には 任意の数の 具体化子を含めることができます。各 具体化子により、対応する 具体化トリプルが生成されます。

具象化子の後には、注釈ブロックが続いてもかまいません。 具象化子の後に注釈ブロックが続かない場合、 これは追加の注釈を持たない reifiedTriple と同様に扱われます。 注釈ブロックの直前に 具象化子がない場合、 新しい RDF 空白ノードが割り当てられ、 トリプル 用語具象化子として機能します。

注記

注釈構文は Turtle における構文上のショートカットです。 RDF 抽象構文 [RDF11-CONCEPTS] は、 トリプルがどのように書かれたかを区別しません。

26: 注釈付きトリプル

VERSION     "1.2"
PREFIX :    <http://example.com/>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>

:alice :name "Alice" ~ :t {| :statedBy :bob ; :recorded "2021-07-07"^^xsd:date |} .

は、次と同じトリプル集合です:

27: 具象化子に展開された注釈付きトリプル

VERSION     "1.2"
PREFIX :    <http://example.com/>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>

:alice :name "Alice" .
<< :alice :name "Alice" ~ :t >> :statedBy :bob ;
                                :recorded "2021-07-07"^^xsd:date .

トリプル用語を使用するよう完全に展開すると、 具象化子ではなく、次のようになります:

28: トリプル 用語に展開された注釈付きトリプル

VERSION     "1.2"
PREFIX :    <http://example.com/>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>

:alice :name "Alice" .
:t rdf:reifies <<( :alice :name "Alice" )>> .
:t :statedBy :bob .
:t :recorded "2021-07-07"^^xsd:date .

前の例では、グラフには4つの トリプルが含まれます。 具象化子:t によって識別されます。

注釈ブロックは、明示的な 具象化子なしでも使用できます。 その場合、新しい RDF 空白ノードが割り当てられ、 トリプル 用語具象化子として機能します。

29: 暗黙的な具象化子を持つ注釈付きトリプル

VERSION     "1.2"
PREFIX :    <http://example.com/>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>

:alice :name "Alice" {| :statedBy :bob ; :recorded "2021-07-07"^^xsd:date |} .

この例を完全に展開すると、次のトリプルになります。ここで _:b0 は新しい RDF 空白 ノードを表します:

30: 展開された、暗黙的な具象化子を持つ注釈付きトリプル

VERSION     "1.2"
PREFIX :    <http://example.com/>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>

:alice :name "Alice" .
_:b0 rdf:reifies <<( :alice :name "Alice" )>> .
_:b0 :statedBy :bob .
_:b0 :recorded "2021-07-07"^^xsd:date .

annotation は、任意の数の注釈ブロックを含んでもかまいません。 そのようなブロックの直前に明示的な 具象化子がない場合、 各ブロックは、その 具象化子として割り当てられた新しい RDF 空白ノードと関連付けられます。

31: 複数の暗黙的な 具象化子を持つ注釈付きトリプル

VERSION     "1.2"
PREFIX :    <http://example.com/>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>

:alice :name "Alice"
  {| :statedBy :alice ; :recorded "2017-02-01"^^xsd:date |}
  {| :statedBy :bob ; :recorded "2021-07-07"^^xsd:date |} .

この例を完全に展開すると、次のトリプルになります。ここで _:b0 および _:b1 は新しい RDF 空白ノードを表します:

32: 展開された、複数の暗黙的な 具象化子を持つ注釈付きトリプル

VERSION     "1.2"
PREFIX :    <http://example.com/>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>

:alice :name "Alice" .
_:b0 rdf:reifies <<( :alice :name "Alice" )>> .
_:b0 :statedBy :alice .
_:b0 :recorded "2017-02-01"^^xsd:date .
_:b1 rdf:reifies <<( :alice :name "Alice" )>> .
_:b1 :statedBy :bob .
_:b1 :recorded "2021-07-07"^^xsd:date .

注釈構文は、注釈ブロックを持たない複数の明示的な 具象化子も含んでもかまいません。 そのような各 具象化子 は、対応する具象化トリプルを生成させます。

33: 複数の明示的な 具象化子を持つ注釈付きトリプル

VERSION     "1.2"
PREFIX :    <http://example.com/>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>

:alice :name "Alice" ~ :stmt1 ~ :stmt2 .

この例を完全に展開すると、次のトリプルになります:

34: 展開された、複数の明示的な 具象化子を持つ注釈付きトリプル

VERSION     "1.2"
PREFIX :    <http://example.com/>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>

:alice :name "Alice" .
:stmt1 rdf:reifies <<( :alice :name "Alice" )>> .
:stmt2 rdf:reifies <<( :alice :name "Alice" )>> .

3.

この節は非規範的です。

この例は、 RDF 1.2 XML Syntax例 7 を Turtle に翻訳したものです (example1.ttl):

PREFIX dc: <http://purl.org/dc/elements/1.1/>
PREFIX ex: <http://example.org/stuff/1.0/>

<https://www.w3.org/TR/rdf12-xml/>
  dc:title "RDF 1.2 XML Syntax" ;
  ex:editor [
    ex:fullName "Gregg Kellogg" ;
    ex:homePage <https://greggkellogg.net/>
  ] .

2つのリテラルからなる RDF コレクションの例です。

36: 2つのリテラルからなる RDF コレクション

PREFIX : <http://example.org/stuff/1.0/>
:a :b ( "apple" "banana" ) .

これは次の省略形です (example2.ttl):

PREFIX : <http://example.org/stuff/1.0/>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
:a :b
  [ rdf:first "apple";
    rdf:rest [ rdf:first "banana";
               rdf:rest rdf:nil ]
  ] .

リテラルオブジェクトに改行を含む2つの同一トリプルの例であり、 プレーン形式および長いリテラル形式で書かれています。 この例の改行は LF です。 (example3.ttl):

PREFIX : <http://example.org/stuff/1.0/>

:a :b "The first line\nThe second line\n  more" .

:a :b """The first line
The second line
  more""" .

文法で示されているように、 collectionsubject または object のいずれにもなれます。 この主語またはオブジェクトは、コレクションが1つ以上のオブジェクトを持つ場合は 最初のオブジェクトに対する新しい 空白ノードとなり、 コレクションが空の場合は rdf:nil になります。

たとえば、

39: 主語として使用されるコレクション

PREFIX : <http://example.org/stuff/1.0/>
(1 2.0 3E1) :p "w" .

は次の構文糖です (ここで 空白 ノード b0b1、および b2RDF グラフの他の場所には現れないことに注意してください):

40: 空白ノードで表現されたコレクション

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX : <http://example.org/stuff/1.0/>
_:b0  rdf:first  1 ;
      rdf:rest   _:b1 .
_:b1  rdf:first  2.0 ;
      rdf:rest   _:b2 .
_:b2  rdf:first  3E1 ;
      rdf:rest   rdf:nil .
_:b0  :p         "w" .

RDF コレクションは入れ子にでき、他の構文形式を 含むことができます:

41: 入れ子の コレクション

PREFIX : <http://example.org/stuff/1.0/>
(1 [:p :q] ( 2 ) ) :p2 :q2 .

は次の構文糖です:

42: 空白ノードで表現された入れ子のコレクション

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX : <http://example.org/stuff/1.0/>
_:b0  :p2  :q2 .
_:b0  rdf:first  1 ;
      rdf:rest   _:b1 .
_:b1  rdf:first  _:b2 .
_:b2  :p         :q .
_:b1  rdf:rest   _:b3 .
_:b3  rdf:first  _:b4 .
_:b4  rdf:first  2 ;
      rdf:rest   rdf:nil .
_:b3  rdf:rest   rdf:nil .

4. Turtle と SPARQL の比較

この節は非規範的です。

SPARQL 1.2 Query Language (SPARQL) [SPARQL12-QUERY] は、その TriplesBlock 生成規則に Turtle 風の構文を使用します。 この生成規則は、次の点で Turtle 言語と異なります:

  1. SPARQL は、RDF リテラルトリプルパターンの主語として許可します。
  2. SPARQL は、形式上のトリプルの任意の部分に 変数 (?name または $name) を許可します。
  3. Turtle は、接頭辞、基底、およびバージョン宣言を トリプルの外側の任意の場所に許可します。 SPARQL では、それらは Prologue (SPARQL クエリの先頭) でのみ許可されます。
  4. SPARQL は、a を除き、 大文字小文字を区別しないキーワードを使用します。 Turtle の @prefix および @base 宣言は大文字小文字を区別し、 SPARQL 由来の PREFIX および BASE は大文字小文字を区別しません。
  5. true および false は、 SPARQL では大文字小文字を区別せず、Turtle では大文字小文字を区別します。 TrUe は Turtle における有効な真偽値ではありません。

詳細については、 SPARQL クエリ文書 [SPARQL12-QUERY] の IRI の構文 および SPARQL 文法 の節を参照してください。

5. 適合性

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

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

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

適合する Turtle 文書は、 RDF 文字列であり、 turtleDoc 生成規則から開始して、 6. Turtle 文法で定義される 文法および追加制約に適合します。 Turtle 文書は、RDF グラフをシリアライズします。

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

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

注記

この仕様は、Turtle パーサーが不適合な入力文書をどのように扱うかを定義しません。

5.1 メディア型および内容 符号化

Turtle のメディア型は text/turtle です。 Turtle コンテンツの内容符号化は常に UTF-8 です [RFC3629]。

6. Turtle 文法

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

6.1 空白

空白 (生成規則 WS) は、そうでなければ1つの終端として (誤って)認識される2つの終端を分離するために使用されます。 以下の大文字の規則名は、空白が重要な場所を示します。 これらは Turtle パーサーを構築するための終端の可能な選択肢を形成します。

空白は生成規則 String において重要です。

6.2 コメント

Turtle におけるコメントは、 IRIREFSTRING_LITERAL_SINGLE_QUOTESTRING_LITERAL_QUOTESTRING_LITERAL_LONG_SINGLE_QUOTE、 または STRING_LITERAL_LONG_QUOTE の外側にある # で始まり、 行末 (LF、または CR で示される) まで、 あるいはコメントマーカーの後に行末がない場合はファイル終端まで続きます。 コメントは空白として扱われます。

6.3 IRI 参照

相対 IRI 参照は、統一 資源識別子(URI):汎用構文 [RFC3986] に従い、 5.2 節の基本アルゴリズムのみを使用して、基底 IRI により解決されます。 構文ベースの正規化もスキームベースの正規化も (RFC3986 の 6.2.2 節および 6.2.3 節で説明されています)実行されません。 IRI 参照で追加で許可される文字は、国際化資源 識別子(IRI) [RFC3987] の 6.5 節に従い、 URI 参照における非予約文字と同じように扱われます。

@base または BASE ディレクティブは、 [RFC3986] の5.1.1 節「コンテンツに埋め込まれた 基底 URI」に従って、相対 IRI 参照を解決するために使用される基底 IRI を定義します。 5.1.2 節「カプセル化する エンティティからの基底 URI」では、 適用範囲内の基底 IRI が、xml:base ディレクティブを持つ SOAP エンベロープや、 Content-Location ヘッダーを持つ MIME マルチパート文書などの カプセル化する文書から取得される場合について定義しています。 5.1.3 節「取得 URI からの基底 URI」で特定される「取得 URI」は、 特定のTurtle 文書が取得された URL です。 上記のいずれによっても基底 URI が指定されない場合は、デフォルトの 基底 URI(5.1.4 節「デフォルトの基底 URI」)が使用されます。 各 @base または BASE ディレクティブは、 直前のものを基準として、新しい適用範囲内の基底 URI を設定します。

6.4 エスケープシーケンス

Turtle 文書で使用されるエスケープには3つの形式があります:

各種類のエスケープシーケンスを使用できるコンテキスト
数値
エスケープ
文字列
エスケープ
予約文字
エスケープ
IRIRDF 用語 として使用されるもの、または @prefixPREFIX@base、 もしくは BASE 宣言内のもの 不可 不可
ローカル 名 不可 不可
文字列 不可

エスケープシーケンスは、関連する文法生成規則に一致する Unicode 符号位置の列を取得し、 次の手順を適用することによって処理されます。

  1. Unicode 符号位置の列を左から右へ走査し、最初に一致するエスケープシーケンスを探します。
  2. エスケープシーケンスが見つかった場合、そのエスケープシーケンスに対応する符号位置が エスケープシーケンスに置換されます。
  3. Unicode 符号位置の列の走査は、置換されたエスケープシーケンスの直後の符号位置から続行されます。
処理されたエスケープシーケンスの例
入力符号位置 出力符号位置 符号位置の数
abc\u005Cdef abc\def 7
abc\u005Ctuv abc\tuv 7
\u005CA \A 2
\\u005C \u005C 6
\u005C\u005C \\ 2
\\\u005C \\ 2
\\\\ \\ 2
\u005Cn \n 2
注記

%-符号化されたシーケンスは、 IRI の文字範囲内にあり、 ローカル名では明示的に許可されています。 これらは % に続く2つの16進文字として現れ、 同じ3文字の列を表します。これらのシーケンスは処理中にデコードされません (not)。 Turtle で <http://a.example/%66oo-bar> と書かれた用語は、IRI http://a.example/%66oo-bar を示し、IRI http://a.example/foo-bar を示すものではありません。 接頭辞 PREFIX ex: <http://a.example/> を持つ ex:%66oo-bar と書かれた用語も、 IRI http://a.example/%66oo-bar を示します。

6.5 文法

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

注記:

  1. 一重引用符内のキーワード ('@base', '@prefix', '@version', 'a', 'true', and 'false') は大文字小文字を区別します。 引用符内のキーワード ("BASE", "PREFIX", and "VERSION") は大文字小文字を区別しません。
  2. エスケープシーケンス UCHAR および ECHAR は大文字小文字を区別します。
  3. 入力をトークン化して文法規則を選択する際には、最長一致が選択されます。
  4. Turtle 文法は、大文字名の規則を終端として使用する場合、LL(1) および LALR(1) です。
  5. 文法への入口点は turtleDoc です。
  6. 符号付き数値では、符号と数値の間に空白は許可されません。
  7. 文字列 '@prefix', '@base', and '@version' は、LANG_DIR のパターンに一致しますが、 prefixbase、および version のいずれも登録済み言語サブタグではありません。 この仕様は、引用符付きリテラルの後にこれらのトークンのいずれかが続くもの (例: "A"@base) が Turtle 言語に含まれるかどうかを定義しません。
[1] turtleDoc ::= statement*
[2] statement ::= directive | (triples '.')
[3] directive ::= prefixID | base | version | sparqlPrefix | sparqlBase | sparqlVersion
[4] prefixID ::= '@prefix' PNAME_NS IRIREF '.'
[5] base ::= '@base' IRIREF '.'
[6] version ::= '@version' VersionSpecifier '.'
[7] sparqlPrefix ::= "PREFIX" PNAME_NS IRIREF
[8] sparqlBase ::= "BASE" IRIREF
[9] sparqlVersion ::= "VERSION" VersionSpecifier
[10] VersionSpecifier ::= STRING_LITERAL_QUOTE | STRING_LITERAL_SINGLE_QUOTE
[11] triples ::= (subject predicateObjectList) | (blankNodePropertyList predicateObjectList?) | (reifiedTriple predicateObjectList?)
[12] predicateObjectList ::= verb objectList (';' (verb objectList)?)*
[13] objectList ::= object annotation (',' object annotation)*
[14] verb ::= predicate | 'a'
[15] subject ::= iri | BlankNode | collection
[16] predicate ::= iri
[17] object ::= iri | BlankNode | collection | blankNodePropertyList | literal | tripleTerm | reifiedTriple
[18] literal ::= RDFLiteral | NumericLiteral | BooleanLiteral
[19] blankNodePropertyList ::= '[' predicateObjectList ']'
[20] collection ::= '(' object* ')'
[21] NumericLiteral ::= INTEGER | DECIMAL | DOUBLE
[22] RDFLiteral ::= String (LANG_DIR | ('^^' iri))?
[23] BooleanLiteral ::= 'true' | 'false'
[24] String ::= STRING_LITERAL_QUOTE | STRING_LITERAL_SINGLE_QUOTE | STRING_LITERAL_LONG_SINGLE_QUOTE | STRING_LITERAL_LONG_QUOTE
[25] iri ::= IRIREF | PrefixedName
[26] PrefixedName ::= PNAME_LN | PNAME_NS
[27] BlankNode ::= BLANK_NODE_LABEL | ANON
[28] reifier ::= '~' (iri | BlankNode)?
[29] reifiedTriple ::= '<<' rtSubject verb rtObject reifier? '>>'
[30] rtSubject ::= iri | BlankNode | reifiedTriple
[31] rtObject ::= iri | BlankNode | literal | tripleTerm | reifiedTriple
[32] tripleTerm ::= '<<(' ttSubject verb ttObject ')>>'
[33] ttSubject ::= iri | BlankNode
[34] ttObject ::= iri | BlankNode | literal | tripleTerm
[35] annotation ::= (reifier | annotationBlock)*
[36] annotationBlock ::= '{|' predicateObjectList '|}'

終端の生成規則

[38] IRIREF ::= '<' ([^#x00-#x20<>"{}|^`\] | UCHAR)* '>'
/* #x00=NULL #x01-#x1F=control codes #x20=space */
[39] PNAME_NS ::= PN_PREFIX? ':'
[40] PNAME_LN ::= PNAME_NS PN_LOCAL
[41] BLANK_NODE_LABEL ::= '_:' (PN_CHARS_U | [0-9]) ((PN_CHARS | '.')* PN_CHARS)?
[42] LANG_DIR ::= '@' [a-zA-Z]+ ('-' [a-zA-Z0-9]+)* ('--' [a-zA-Z]+)?
[43] INTEGER ::= [+-]? [0-9]+
[44] DECIMAL ::= [+-]? ([0-9]* '.' [0-9]+)
[45] DOUBLE ::= [+-]? (([0-9]+ ('.' [0-9]*)?) | ('.' [0-9]+)) EXPONENT
[46] EXPONENT ::= [eE] [+-]? [0-9]+
[47] STRING_LITERAL_QUOTE ::= '"' ([^#x22#x5C#x0A#x0D] | ECHAR | UCHAR)* '"'
[48] STRING_LITERAL_SINGLE_QUOTE ::= "'" ([^#x27#x5C#x0A#x0D] | ECHAR | UCHAR)* "'"
[49] STRING_LITERAL_LONG_SINGLE_QUOTE ::= "'''" (("'" | "''")? ([^'\] | ECHAR | UCHAR))* "'''"
[50] STRING_LITERAL_LONG_QUOTE ::= '"""' (('"' | '""')? ([^"\] | ECHAR | UCHAR))* '"""'
[51] UCHAR ::= ('\u' HEX HEX HEX HEX) | ('\U' HEX HEX HEX HEX HEX HEX HEX HEX)
[52] ECHAR ::= '\' [tbnrf\"']
[53] WS ::= #x20 | #x09 | #x0D | #x0A
[54] ANON ::= '[' WS* ']'
[55] 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]
[56] PN_CHARS_U ::= PN_CHARS_BASE | '_'
[57] PN_CHARS ::= PN_CHARS_U | '-' | [0-9] | #xB7 | [#x0300-#x036F] | [#x203F-#x2040]
[58] PN_PREFIX ::= PN_CHARS_BASE ((PN_CHARS | '.')* PN_CHARS)?
[59] PN_LOCAL ::= (PN_CHARS_U | ':' | [0-9] | PLX) ((PN_CHARS | '.' | ':' | PLX)* (PN_CHARS | ':' | PLX))?
[60] PLX ::= PERCENT | PN_LOCAL_ESC
[61] PERCENT ::= '%' HEX HEX
[62] HEX ::= [0-9] | [A-F] | [a-f]
[63] PN_LOCAL_ESC ::= '\' ('_' | '~' | '.' | '-' | "!" | '$' | '&' | "'" | '(' | ')' | '*' | '+' | ',' | ';' | '=' | '/' | '?' | '#' | '@' | '%')

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

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

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

コード グリフ 説明
U+0009 HT 水平タブ
U+000A LF 改行
U+000D CR 復帰
U+0022 " 引用符
U+0023 # 番号記号
U+0025 % パーセント記号
U+0027 ' アポストロフィ
U+0028 ( 左丸括弧
U+0029 ) 右丸括弧
U+002C , コンマ
U+002D - ハイフン
U+002E . ピリオド
U+0030 0 数字のゼロ
U+0039 9 数字の9
U+003B : コロン
U+003B ; セミコロン
U+003C < 小なり記号
U+003E > 大なり記号
U+0040 @ アット記号
U+0045 E ラテン大文字 E
U+005B [ 左角括弧
U+005C \ バックスラッシュ
U+005D [ 右角括弧
U+005F _ アンダースコア
U+0061 a ラテン小文字 A
U+0065 e ラテン小文字 E
U+007C | 縦線
U+007E ~ チルダ
U+00B7 · 中点
U+203F アンダータイ
U+2040 キャラクタータイ

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

space
U+0020
"""
3つの引用符文字を連結したもので、それぞれの符号位置は U+0022 です
'''
3つのアポストロフィ文字を連結したもので、それぞれの符号位置は U+0027 です
<<
2つの小なり記号文字を連結したもので、それぞれの符号位置は U+003C です
>>
2つの大なり記号文字を連結したもので、それぞれの符号位置は U+003E です
<<(
2つの小なり記号文字を連結したもので、それぞれの符号位置は U+003C、 その後に、符号位置 U+0028 を持つ左丸括弧文字が続きます
)>>
符号位置 U+0029 を持つ左丸括弧文字に、 2つの大なり記号文字を連結したものが続き、それぞれの符号位置は U+003E です
^^
2つのサーカムフレックスアクセント文字を連結したもので、それぞれの符号位置は U+005E です
{|
{ (左波括弧、符号位置 U+007B) に続いて、 | (縦線、符号位置 U+007C) が置かれます
|}
| (縦線、符号位置 U+007C) に続いて、 } (右波括弧、符号位置 U+007D) が置かれます
_:
_ に続いて : が置かれます
--
2つの - 文字を連結したものです

7. 構文解析

RDF 1.2 Concepts and Abstract Syntax 仕様 [RDF12-CONCEPTS] は、4種類の RDF 用語を定義します: IRIリテラル空白 ノード、および トリプル 用語です。 リテラルは、字句形式 と、任意の 言語タグ [BCP47] – 場合により 初期テキスト方向を含む – または データ型 IRIから構成されます。 追加の型である prefix は、構文解析中に文字列識別子を 名前空間 IRI に対応付けるために使用されます。 この節では、6.5 文法 の文法に適合する文字列を、生成規則および字句トークンに一致する文字列を RDF 用語またはその構成要素 (例: 言語タグ、リテラルの字句形式) に対応付けることによって、 トリプル集合に対応付けます。 文法生成規則はパーサー状態を変更し、トリプルを出力します。

7.1 パーサー状態

Turtle の構文解析には、9項目の状態が必要です:

用語コンストラクターは、「curSubject および curPredicate を記録する」 などの言語を使用して示される、これらの値のスタックを作成できます。

7.2 RDF 用語コンストラクター

この表は、生成規則および字句トークンを、RDF 用語、 または RDF 用語の構成要素に対応付けます。 それらは 7. 構文解析に 列挙されています:

生成規則 手順
IRIREF IRI <> の間の文字を取得し、 数値エスケープシーケンスをエスケープ解除して IRI を形成します。相対 IRI 参照の解決は、 6.3 節に従って行われます。結果として得られる IRI は、汎用 IRI 構文の 構文上の制約に準拠しなければならず、 [RFC3986] の 3.3 節に適合することが望ましく、対応する IRI スキーム仕様によって課される より厳しい制約にも準拠することが望まれます。
PNAME_NS 接頭辞 prefixID または sparqlPrefix 生成規則で使用される場合、 prefix は、規則の第 1 引数に一致する、空である可能性のある RDF 文字列であり、 展開された第 2 引数が将来の検索のために格納される 名前空間マップ へのキーとなります。
IRI PrefixedName 生成規則で使用される場合、名前空間マップには対応する namespace が存在しなければならず、これが IRI の RDF 文字列を形成します。結果として得られる IRI は、 汎用 IRI 構文の 構文上の制約に準拠しなければならず、対応する IRI スキーム仕様によって課される より厳しい制約にも準拠することが望まれます
PNAME_LN IRI 空である可能性のある 接頭辞は、第 1 シーケンスである PNAME_NS によって識別されます。名前空間マップには、対応する namespace存在しなければなりません。IRI の RDF 文字列は、 第 2 引数 予約文字である PN_LOCAL のエスケープを解除し、それを namespace に連結することで形成されます。結果として得られる IRI は、汎用 IRI 構文の 構文上の制約に準拠しなければならず、対応する IRI スキーム仕様によって課される より厳しい制約にも準拠することが望まれます
VersionSpecifier リテラル。 curVersion は、一致した RDF 文字列の字句形式と xsd:string データ型を使用して、リテラルから取得されます。
STRING_LITERAL_SINGLE_QUOTE 字句形式 最も外側の ' の間の文字を取得し、数値および 文字列エスケープ シーケンスを、それらが表す文字に置き換えた後、字句形式の RDF 文字列を形成します。
STRING_LITERAL_QUOTE 字句形式 最も外側の " の間の文字を取得し、数値および 文字列エスケープ シーケンスをエスケープ解除して、字句形式の RDF 文字列を形成します。
STRING_LITERAL_LONG_SINGLE_QUOTE 字句形式 最も外側の ''' の間の文字を 取得し、数値および 文字列エスケープ シーケンスをエスケープ解除して、字句形式の RDF 文字列を形成します。
STRING_LITERAL_LONG_QUOTE 字句形式 最も外側の """ の間の文字を 取得し、数値および 文字列 エスケープシーケンスを、それらが表す文字に置き換えた後、字句形式の RDF 文字列を形成します。
LANG_DIR 言語タグ @ に続く文字が 言語タグを形成し、一致した文字に -- が含まれている場合は、任意で 初期テキスト方向も形成します。言語タグは、[BCP47] の 2.2.9 節に従って整形式でなければなりません。存在する場合、初期テキスト方向は、 ltr または rtl のいずれかでなければなりません
RDFLiteral リテラル リテラルは、第 1 規則引数である String の字句形式を持ちます。'^^' iri 規則が一致した場合、データ型 IRIiri から導出され、リテラルは言語タグを持ちません。LANG_DIR 規則 が一致した場合、言語タグおよび 初期テキスト方向は、 LANG_DIR から取得されます。初期テキスト方向がない場合、 データ型は rdf:langString です。初期テキスト方向がある場合、 データ型は rdf:dirLangString です。どちらにも一致しない場合、データ型は xsd:string であり、リテラルは言語タグを持ちません。
INTEGER リテラル リテラルは入力文字列の字句形式と、 xsd:integer データ型を持ちます。
DECIMAL リテラル リテラルは入力文字列の字句形式と、 xsd:decimal データ型を持ちます。
DOUBLE リテラル リテラルは入力文字列の字句形式と、 xsd:double データ型を持ちます。
BooleanLiteral リテラル リテラルは、入力に一致した方に応じて true または false の 字句形式と、xsd:boolean データ型を持ちます。
BLANK_NODE_LABEL 空白ノード 第 2 引数 PN_LOCAL に一致する文字列は、bnodeLabels のキーです。マップ内に対応する 空白ノードがない場合、1 つ割り当てられます。
ANON 空白ノード 空白ノードが生成されます。
blankNodePropertyList 空白ノード 空白ノードが生成されます。次の 節の blankNodePropertyList の規則に注意してください。
collection 空白ノード 空でないリストでは、空白ノードが生成されます。次の節の collection の規則に注意してください。
IRI 空のリストでは、結果として得られる IRI は rdf:nil です。次の節の collection の規則に注意してください。
reifier IRI | 空白ノード curReifierから取得されます。この項は、一致した iri 生成規則、 または存在する場合は BlankNode 生成規則から取得されます。 そのような生成規則が一致しない場合、は、新しい RDF 空白ノードから取得されます。
tripleTerm トリプル項 トリプル項は、 ttSubjectpredicate、および ttObject 生成規則から 構築された項で構成されます。
reifiedTriple IRI | 空白ノード は、存在する場合は一致した reifier から取得され、 そうでない場合は新しい RDF 空白ノードから取得されます。
annotationBlock IRI | 空白ノード は、存在する場合は以前に一致した 具体化子から取得され、 そうでない場合は新しい RDF 空白ノードから取得されます。
注記

入力上のエラーを検出する処理器は、 入力で記述されたものより少ないトリプルを含むグラフ (トリプルをまったく含まないものを含む) を生成する可能性があるため、 利用者は、出力トリプルを使用する際、 通知されたエラー情報を考慮するべきです。 出力トリプルは不完全である可能性があり、かつ/または 型不正 または整形式でない用語を含む可能性があります。

7.3 RDF トリプルコンストラクター

Turtle 文書は、 RDF トリプルの集合から構成される RDF グラフを定義します。 subject 生成規則は curSubject を設定します。 verb 生成規則は curPredicate を設定します。 object および ttObject 生成規則は curObject を設定します。 文書内の各 object N は、次の RDF トリプルを生成します: curSubject curPredicate N .

7.3.1 具象化子

reifier 生成規則の開始時に、 curReifierreifier 用語コンストラクターから 取得されます。 次に RDF トリプル curReifier rdf:reifies curTripleTerm を生成します。

7.3.2 具象化された トリプル

reifiedTriple 生成規則の開始時に、 curTripleTerm を記録します。 新しい tripleTerm インスタンス curTripleTerm が、rtSubjectverb、および rtObject 生成規則を使用して作成されます。 reifiedTriple 生成規則の終了時に、 curReifier が設定されていない場合、 新しい RDF 空白 ノードが割り当てられます。 次に RDF トリプル curReifier rdf:reifies curTripleTerm を生成し、その後、記録された curTripleTerm の値を復元します。 reifiedTriple に一致することで生成されるノードは curReifier です。

7.3.3 注釈

annotation 生成規則の開始時に、 curSubject および curPredicate を記録します。 新しい tripleTerm インスタンス curTripleTerm が、curSubject curPredicate curObject を使用して作成され、 curReifier の値はクリアされます。 annotation 生成規則の終了時に、 記録された curSubject および curPredicate の値を復元します。

7.3.4 注釈ブロック

annotationBlock 生成規則の開始時に、 curTripleTerm を記録します。 curReifier が設定されていない場合、新しい RDF 空白 ノードが割り当てられ、 この生成規則は RDF トリプル curReifier rdf:reifies curTripleTerm を生成します。 curSubjectcurReifier から取得されます。 annotationBlock 生成規則の終了時に、 curReifier の値をクリアし、 curTripleTerm を復元します。

注記

curReifier がすでに設定されていた場合、 具象化トリプル curReifier rdf:reifies curTripleTerm7.3.1 具象化子で出力されています。

7.3.5 プロパティ リスト

blankNodePropertyList 生成規則の開始時に、curSubject および curPredicate を記録し、 curSubject を新しい 空白ノード B に設定します。 blankNodePropertyList 生成規則の終了時に、curSubject および curPredicate を復元します。 blankNodePropertyList に一致することで生成されるノードは、空白ノード B です。

7.3.6 コレクション

collection 生成規則の開始時に、 curSubject および curPredicate を記録します。 collection 生成規則内の各 object について、 curSubject は 新しい 空白ノード B に設定され、 curPredicaterdf:first に設定されます。 最初の後の各オブジェクト objectn は、次のトリプルを生成します:objectn-1 rdf:rest objectn . collection 生成規則の終了時に、 追加のトリプル curSubject rdf:rest rdf:nil . を作成し、 curSubject および curPredicate を復元します。 collection に一致することで 生成されるノードは、空でないリストでは最初の空白ノード B、 空のリストでは rdf:nil です。

7.4 構文解析例

この節は非規範的です。

次の参考例は、この Turtle 文書を LALR(1) パーサーで構文解析するときに実行される 意味アクションを示します:

43: Turtle の 構文解析例

  PREFIX ericFoaf: <http://www.w3.org/People/Eric/ericP-foaf.rdf#>
  PREFIX : <http://xmlns.com/foaf/0.1/>
  ericFoaf:ericP :givenName "Eric" ;
    :knows <http://norman.walsh.name/knows/who/dan-brickley> ,
            [ :mbox <mailto:timbl@w3.org> ] ,
            <http://getopenid.com/amyvdh> .

A. HTML 文書への Turtle の埋め込み

この節は非規範的です。

HTML [HTML5] の script タグは、 文書内にデータブロックを埋め込むために使用できます。Turtle は、この方法で HTML に容易に埋め込むことができます。

44: HTML への Turtle の埋め込み

<script type="text/turtle">
  PREFIX dc: <http://purl.org/dc/terms/>
  PREFIX frbr: <http://purl.org/vocab/frbr/core#>

  <http://books.example.com/works/45U8QJGZSQKDH8N> a frbr:Work ;
    dc:creator "Wil Wheaton"@en ;
    dc:title "Just a Geek"@en ;
    frbr:realization <http://books.example.com/products/9780596007683.BOOK>,
      <http://books.example.com/products/9780596802189.EBOOK> .

  <http://books.example.com/products/9780596007683.BOOK> a frbr:Expression ;
    dc:type <http://books.example.com/product-types/BOOK> .

  <http://books.example.com/products/9780596802189.EBOOK> a frbr:Expression ;
    dc:type <http://books.example.com/product-types/EBOOK> .
</script>

Turtle コンテンツは、 type 属性を text/turtle に設定した script タグ内に 置くべきです。 < および > 記号は、 script タグの内側ではエスケープする必要はありません。埋め込まれた Turtle の文字エンコーディングは、 HTML 文書のエンコーディングと一致します。

A.1 XHTML

この節は非規範的です。

JavaScript と同様に、HTML (text/html) 用に書かれた Turtle は、XHTML (application/xhtml+xml) で使用すると壊れることがあります。解決策は JavaScript で 使用されるものと同じです。

45: XHTML への Turtle の埋め込み

<script type="text/turtle">
  <span class="hl-bold"># <![CDATA[</span>
  PREFIX frbr: <http://purl.org/vocab/frbr/core#>

  <http://books.example.com/works/45U8QJGZSQKDH8N> a frbr:Work .
  <span class="hl-bold"># ]]></span>
</script>

XHTML に埋め込む場合、Turtle データブロックは CDATA セクションで囲まれなければなりません。 それらの CDATA マーカーは Turtle コメント内になければなりません。文字列 ]]> が文書内に現れる場合は、 文字列エスケープ (\u005D\u005D\u003E) を使用してエスケープしなければなりません。 これにより、text/htmlapplication/xhtml+xml の両方として提供されるポリグロット文書内でも Turtle が安全になります。CDATA セクションを使用しない、または ]]> をエスケープしない場合、 整形式でない XML 文書になる可能性があります。

A.2 HTML 内の Turtle の構文解析

この節は非規範的です。

埋め込まれた Turtle と通常の Turtle 文書を構文解析する場合に、構文上または文法上の違いはありません。 HTML DOM から構文解析された Turtle 文書は、UTF-8 [RFC3629] 符号 位置のストリームではなく、文字データのストリームになります。 HTML 文書がすでに DOM に構文解析されている場合、デコードは不要です。 各 script データブロックは、それ自体が1つの Turtle 文書と見なされます。 Turtle データブロック内の PREFIX および BASE 宣言は、そのデータブロックにスコープされ、 他のデータブロックには影響しません。 HTML の lang 属性または XHTML の xml:lang 属性は、 データブロックの構文解析に影響しません。 カプセル化する HTML 文書の基底 URI は、RFC3986 5.1.1 節に従う "Base URI Embedded in Content" を提供します。

B. プライバシーに関する考慮事項

この節は非規範的です。

Turtle 形式は任意のアプリケーションデータを表現するために使用され、 その中には個人識別情報 (PII) または機微であると考えられる他の情報の表現が含まれる場合があります。 そのような情報を公開する著者には、 そのような情報を公開する必要性と用途、 およびデータが消費され、潜在的に開示されると想定される地域に適用される規制 (例: GDPRCCPAその他) を 慎重に検討することが推奨されます。 特に、データへのアクセスに認可手段が必要かどうかを検討するべきです。

C. セキュリティに関する考慮事項

この節は非規範的です。

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

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

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

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

Turtle は、項の識別子としてIRIを使用します。 Turtle で表現されたデータを解釈するアプリケーションは、 国際化 資源識別子(IRI) [RFC3987] の 8 節、および 統一資源 識別子(URI):汎用構文 [RFC3986] の 7 節に記載されたセキュリティ上の問題に対処するべきです

複数のIRIが、 同じ外観を持つ場合があります。 異なる用字体系の文字が似て見える場合があります(たとえば、 キリル文字の「о」(コードポイント U+043E)は、ラテン文字の「o」(コードポイント U+006F)と似て見えることがあります)。 文字の後に結合文字が続く場合、別の文字と同じ視覚表現になることがあります (たとえば、ラテン小文字「E」(コードポイント U+0065)の後に 結合アキュートアクセント(コードポイント U+0301)が続くものは、 アキュートアクセント付きラテン小文字「E」 (U+00E9)と同じ視覚表現になります)。 Turtle でデータを記述または解釈する人またはアプリケーションは、 意図した意味論に一致する IRI を使用するよう注意し、 似て見える可能性のある IRI を避けなければなりません。 視覚的に類似した文字の照合に関する詳細情報は、 Unicode のセキュリティに関する考慮事項 [UNICODE-SECURITY] および 国際化 資源識別子(IRI) [RFC3987] の 8 節に記載されています。

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

Turtle のインターネットメディア型 (以前は MIME 型として知られていたもの) は "text/turtle" です。

以下の情報は、レビュー、承認、および IANA への登録のため、Internet Engineering Steering Group (IESG) に 提出されています。

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

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

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

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

注記

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

注記

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

profile パラメーターの値は、1つ以上の URI を含み、IRI ではないことに 注意することが重要です。そのため、 [RFC3987] の 第3節 Relationship between IRIs and URIs で指定されるように、IRI と URI の間で変換する必要がある場合があります。

E. 謝辞

E.1 RDF 1.1 に対する謝辞

この節は非規範的です。

この作業は論文 RDF の新しい構文 で説明されており、この論文は他の RDF 構文と Turtle の背景 (WWW2004 に提出され、そこでは N-Triples Plus と呼ばれた) について論じています。

この作業は、EU IST-7 プログラム IST-2001-34732 (2002-2004) によって資金提供された Semantic Web Advanced Development Europe (SWAD-Europe) プロジェクト中に開始され、 さらに英国 University of BristolInstitute for Learning and Research Technology によって開発が支援されました (2002年–2005年9月)。

この版への貴重な貢献は、Gregg Kellogg、Andy Seaborne、Sandro Hawke、および RDF Working Group のメンバーによって行われました。

この文書は、より広いコミュニティによるレビュー過程を通じて改善されました。

E.2 RDF 1.2 に対する謝辞

この節は非規範的です。

編集者に加えて、以下の方々がこの仕様に貢献しました。 Andrew Louis, Denis Ah-Kang, Gregory Todd Williams, John Walker, Mirek Kratochvil, Niklas Lindström, Peter F. Patel-Schneider, Pierre-Antoine Champin, Ted Thibodeau Jr, Thomas Tanon, および William Van Woensel

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 および関連標準のより広範なエコシステムに対する彼の多大な貢献に、 深く感謝の意を表します。
編集者注

タスクフォースのメンバーにも謝意を表すべきでしょうか?貢献者の一覧は簡単には見つかりません。

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

この節は非規範的です。

この仕様は、RDF 1.1 Turtle で定義されている元の Turtle 構文を拡張し、 RDF 1.2 の概念 および抽象データモデルで導入された新機能をサポートします。 この拡張は完全な後方互換性を備えています。 旧バージョンに準拠するすべての文書は新バージョンにも準拠し、同じグラフとして構文解析されます。 さらに、新バージョンに準拠し、RDF 1.1 の機能のみを含む文書は、旧バージョンにも準拠します (VERSION ディレクティブを除きます。2.4 バージョンの宣言を参照してください)。 最後に、新しい構文構造はいずれも旧構文では有効ではありません。 これは、RDF 1.2 の機能を使用する Turtle 文書は、 この仕様の以前のバージョンには 準拠せず、そのバージョンの下で異なるグラフとして 解釈されることもないことを意味します。

より具体的には、次の変更が加えられました。

G. 索引

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

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

H. 参考文献

H.1 規範的参考文献

[BCP47]
言語を識別するためのタグ. A. Phillips(編); M. Davis(編). IETF. 2009 年 9 月. 現行の最良の慣行. URL: https://www.rfc-editor.org/info/rfc5646/
[EBNF-NOTATION]
EBNF 記法. Tim Bray; Jean Paoli; Michael Sperberg-McQueen; Eve Maler; François Yergeau ほか. 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/
[RFC2119]
要求レベルを示すために RFC で使用するキーワード . S. Bradner. IETF. 1997 年 3 月. 現行の最良の慣行. URL: https://www.rfc-editor.org/info/rfc2119/
[RFC3629]
UTF-8、ISO 10646 の変換形式. F. Yergeau. IETF. 2003 年 11 月. インターネット標準. URL: https://www.rfc-editor.org/info/rfc3629/
[RFC3986]
統一資源識別子(URI):汎用 構文. T. Berners-Lee; R. Fielding; L. Masinter. IETF. 2005 年 1 月. インターネット標準. URL: https://www.rfc-editor.org/info/rfc3986/
[RFC3987]
国際化資源識別子 (IRI). M. Duerst; M. Suignard. IETF. 2005 年 1 月. 標準化提案. URL: https://www.rfc-editor.org/info/rfc3987/
[RFC6906]
「profile」リンク関係型. E. Wilde. IETF. 2013 年 3 月. 情報提供. URL: https://www.rfc-editor.org/info/rfc6906/
[RFC8174]
RFC 2119 のキーワードにおける大文字と小文字の 曖昧さ. B. Leiba. IETF. 2017 年 5 月. 現行の最良の慣行. URL: https://www.rfc-editor.org/info/rfc8174/
[UNICODE]
Unicode 標準. Unicode Consortium. URL: https://www.unicode.org/versions/latest/

H.2 参考参考文献

[HTML5]
HTML5. Ian Hickson; Robin Berjon; Steve Faulkner; Travis Leithead; Erika Doyle Navara; Theresa O'Connor; Silvia Pfeiffer. W3C. 2018 年 3 月 27 日. W3C 勧告. URL: https://www.w3.org/TR/html5/
[LANG-SUBTAG-REGISTRY]
言語 サブタグレジストリ. IANA. URL: http://www.iana.org/assignments/language-subtag-registry/language-subtag-registry
[RDF-MT]
RDF 意味論. Patrick Hayes. W3C. 2004 年 2 月 10 日. W3C 勧告. URL: https://www.w3.org/TR/rdf-mt/
[RDF11-CONCEPTS]
RDF 1.1 の概念および抽象構文. Richard Cyganiak; David Wood; Markus Lanthaler. W3C. 2014 年 2 月 25 日. W3C 勧告. URL: https://www.w3.org/TR/rdf11-concepts/
[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 年 7 月 23 日. W3C 作業草案. URL: https://www.w3.org/TR/rdf12-n-quads/
[RDF12-N-TRIPLES]
RDF 1.2 N-Triples. Gregg Kellogg; Dominik Tomaszuk. W3C. 2026 年 7 月 23 日. W3C 作業草案. URL: https://www.w3.org/TR/rdf12-n-triples/
[RDF12-NEW]
RDF 1.2 の新機能. W3C RDF & SPARQL ワーキンググループ. 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 日. WG ノート草案. 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/info/rfc3023/
[RFC4288]
メディアタイプの仕様および登録 手続き. N. Freed; J. Klensin. IETF. 2005 年 12 月. 現行の最良の慣行. URL: https://www.rfc-editor.org/info/rfc4288/
[RFC7231]
ハイパーテキスト転送プロトコル(HTTP/1.1):意味論および コンテンツ. R. Fielding(編); J. Reschke(編). IETF. 2014 年 6 月. 標準化提案. URL: https://httpwg.org/specs/rfc7231.html
[SPARQL12-CONCEPTS]
SPARQL 1.2 の概念. W3C RDF & SPARQL ワーキンググループ. 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 の新機能. W3C RDF & SPARQL ワーキンググループ. 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 年 7 月 23 日. 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 月 25 日. 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 年 7 月 23 日. 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 年 7 月 23 日. 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/
[TURTLE]
RDF 1.1 Turtle. Eric Prud'hommeaux; Gavin Carothers. W3C. 2014 年 2 月 25 日. W3C 勧告. URL: https://www.w3.org/TR/turtle/
[UNICODE-SECURITY]
Unicode のセキュリティに関する考慮事項. Mark Davis; Michel Suignard. Unicode Consortium. 2014 年 9 月 19 日. Unicode 技術報告書 #36. URL: https://www.unicode.org/reports/tr36/tr36-15.html
[XML-NAMES]
XML 1.0 における名前空間(第 3 版). Tim Bray; Dave Hollander; Andrew Layman; Richard Tobin; Henry Thompson ほか. W3C. 2009 年 12 月 8 日. W3C 勧告. URL: https://www.w3.org/TR/xml-names/
[XMLSCHEMA11-2]
W3C XML スキーマ定義言語(XSD)1.1 第 2 部: データ型. David Peterson; Sandy Gao; Ashok Malhotra; Michael Sperberg-McQueen; Henry Thompson; Paul V. Biron ほか. W3C. 2012 年 4 月 5 日. W3C 勧告. URL: https://www.w3.org/TR/xmlschema11-2/