RDF 1.2 TriG

RDF データセット言語

W3C 作業草案

この文書についての詳細
このバージョン:
https://www.w3.org/TR/2026/WD-rdf12-trig-20260612/
最新公開バージョン:
https://www.w3.org/TR/rdf12-trig/
最新編集者草案:
https://w3c.github.io/rdf-trig/spec/
履歴:
https://www.w3.org/standards/history/rdf12-trig/
コミット履歴
テストスイート:
https://w3c.github.io/rdf-tests/rdf/rdf12/rdf-trig/
最新勧告:
https://www.w3.org/TR/trig
編集者:
Gregg Kellogg (2025-09-06 まで)、追悼
Dominik Tomaszuk
元編集者:
Gavin Carothers (RDF 1.1)
Andy Seaborne (RDF 1.1)
著者:
Chris Bizer (Freie Universität Berlin)
Richard Cyganiak (Freie Universität Berlin)
フィードバック:
GitHub w3c/rdf-trig (プルリクエスト、 新しい課題、 未解決の課題)
public-rdf-star-wg@w3.org 件名行を [rdf12-trig] … メッセージのトピック … としてください (アーカイブ)

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

概要

この文書は、TriG と呼ばれる RDF のテキスト構文を定義します。 これにより、RDF データセットを、一般的な使用パターンおよび データ型の省略記法を用いて、コンパクトかつ自然なテキスト形式で 完全に記述できます。TriG は Turtle [RDF12-TURTLE] 形式の拡張です。

RDF 1.2 TriG は、[RDF12-TURTLE] と トリプル項を共有します。これは第4の RDF 項として、 別の トリプルの オブジェクト として使用でき、 他の文について文を述べることを可能にします。 RDF 1.2 TriG はまた、[RDF12-TURTLE] と 方向付き言語タグ付き文字列 も共有します。

さらに、RDF 1.2 TriG は [RDF12-TURTLE] と トリプルの具体化および 注釈構文拡張も共有し、これにより トリプル項も表明できるようになります。

この文書のステータス

このセクションは、この 文書が公開された時点でのステータスを説明します。現在の W3C 公開物およびこの技術レポートの最新リビジョンの一覧は、 W3C 標準および草案 索引にあります。

この文書は RDF 1.2 文書スイートの一部です。 TriG は、複数グラフのための RDF 構文を定義するという RDF & SPARQL Working Group の 憲章要件を満たすことを意図しています。TriG は、RDF の Turtle 構文 [RDF12-TURTLE] の拡張です。現在の文書は、 Chris Bizer と Richard Cyganiak による元の提案に基づいています。

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

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

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

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

この文書は、 2025年8月18日版 W3C プロセス文書に従います。

1. はじめに

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

この文書は、RDF Concepts and Abstract Syntax 文書 [RDF12-CONCEPTS] で定義される RDF の 具象構文である TriG を定義します。TriG は Turtle [RDF12-TURTLE] の拡張であり、完全な RDF データセットの表現をサポートするように 拡張されています。

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

2. TriG 言語

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

TriG 文書は、RDF データセットをコンパクトなテキスト形式で 書き下すことを可能にします。 これは、ディレクティブ、トリプル文、 トリプルを生成する文を含むグラフ文、および任意の空行の列で構成されます。 コメントは、別の 字句トークンの一部ではない # の後に記述でき、 行末まで続きます。

グラフ文は、 IRI または 空白 ノード と、波括弧（{}）で囲まれた トリプル文のグループとの組です。 グラフ文の IRI または 空白 ノード は別のグラフ文で使用でき、 これは各グラフ文によって生成されるトリプルの和集合を取ることを 意味します。 グラフラベルとして使用される IRI または 空白 ノード は、任意のトリプル文の一部として再び現れることもあります。 任意で、グラフ文は IRI でラベル付けされない場合があります。 そのようなグラフ文は、デフォルトグラフ、すなわち RDF データセットのデフォルトグラフに対応します。

TriG 文書から RDF データセットを構築する方法は、 4. TriG 文法 および 5. 解析で定義されます。

2.1 バージョン告知

TriG は、Turtle [RDF12-TURTLE] と同じバージョン告知機構を使用します。

2.2 トリプル文

TriG は Turtle 言語の拡張であるため、 Turtle 言語の任意の構成要素を使用できます。 単純トリプル、 述語リスト、 および オブジェクトリスト はすべて、グラフ文の内部、または TriG 文書内で それ自体として使用できます。 グラフ文の外にある場合、それらのトリプルは RDF データセットの デフォルトグラフの一部とみなされます。

2.3 グラフ文

グラフ文は、 IRI または 空白ノードと RDF グラフを対応付けます。 グラフを構成するトリプル文は、 {} で囲まれます。

TriG 文書では、グラフ IRI または空白ノードを、複数のグラフ文のラベルとして 使用できます。 グラフ文のグラフラベルは省略できます。 この場合、そのグラフは RDF データセットの デフォルトグラフとみなされます。

RDF データセットは、単一のグラフのみを含む場合があります。

例 1: 単一グラフを持つデータセット 

# This document encodes one graph.
PREFIX ex: <http://www.example.org/vocabulary#>
PREFIX : <http://www.example.org/exampleDocument#>

:G1 { :Monica a ex:Person ;
    ex:name "Monica Murphy" ;
    ex:homepage <http://www.monicamurphy.org> ;
    ex:email <mailto:monica@monicamurphy.org> ;
    ex:hasSkill ex:Management ,
                ex:Programming .
}

RDF データセットは、 デフォルトグラフ、および/または 0 個以上の 名前付きグラフを含むことができます。

例 2: デフォルトグラフおよび名前付きグラフを持つデータセット 

# This document contains a default graph and two named graphs.

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX dc: <http://purl.org/dc/terms/>
PREFIX foaf: <http://xmlns.com/foaf/0.1/>

# default graph
{
  <http://example.org/bob> dc:publisher "Bob" .
  <http://example.org/alice> dc:publisher "Alice" .
}

<http://example.org/bob> {
   _:a foaf:name "Bob" .
   _:a foaf:mbox <mailto:bob@oldcorp.example.org> .
   _:a foaf:knows _:b .
}

<http://example.org/alice> {
   _:b foaf:name "Alice" .
   _:b foaf:mbox <mailto:alice@work.example.org> .
}

TriG は、グラフおよびトリプルを書くためのさまざまな代替方法を提供し、 データ作成者が明確さのために選択できるようにします。

例 3: 名前付きグラフを書く代替方法 

# This document contains a same data as the previous example.

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX dc: <http://purl.org/dc/terms/>
PREFIX foaf: <http://xmlns.com/foaf/0.1/>

# default graph - no {} used.
<http://example.org/bob> dc:publisher "Bob" .
<http://example.org/alice> dc:publisher "Alice" .

# GRAPH keyword to highlight a named graph
# Abbreviation of triples using ;
GRAPH <http://example.org/bob>
{
   [] foaf:name "Bob" ;
      foaf:mbox <mailto:bob@oldcorp.example.org> ;
      foaf:knows _:b .
}

GRAPH <http://example.org/alice>
{
    _:b foaf:name "Alice" ;
        foaf:mbox <mailto:alice@work.example.org>
}

2.4 その他の項

その他すべての項、構文形式、およびディレクティブは、 RDF Turtle に由来します。

2.4.1 空白ノードに関する 特別な考慮事項

空白ノードは、 異なるラベル付きグラフ文において同じ 識別子 を共有する場合、同じ空白ノードであるとみなされます。

3. 適合性

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

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

この仕様は、次の適合基準を定義します。

適合する TriG 文書は、4. TriG 文法で定義される文法および追加制約に適合する Unicode 文字列であり、 trigDoc 生成規則から始まります。 TriG 文書は RDF データセットを直列化します。

適合する TriG パーサーは、アプリケーションのために TriG 文書を読み取ることができるシステムです。 これは、5. 解析で定義される、 直列化された RDF データセットを、 通常は何らかの形の API を通じてアプリケーションに利用可能にします。

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

注記

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

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

TriG のメディア型は application/trig です。 TriG コンテンツの内容符号化は常に UTF-8 です。

4. TriG 文法

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

4.1 空白

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

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

4.2 コメント

TriG のコメントは、 IRIREF、 STRING_LITERAL_SINGLE_QUOTE、 STRING_LITERAL_QUOTE、 STRING_LITERAL_LONG_SINGLE_QUOTE、 または STRING_LITERAL_LONG_QUOTE の外側にある # から始まり、 行末（LF または CR によって示されます）まで、 またはコメントマーカーの後に行末がない場合はファイル末尾まで続きます。 コメントは空白として扱われます。

4.3 IRI 参照

相対 IRI 参照は、 Uniform Resource Identifier (URI): Generic Syntax [RFC3986] に従い、 5.2 節の基本アルゴリズムのみを使用して、基底 IRI により解決されます。 Syntax-Based Normalization も Scheme-Based Normalization （RFC3986 の 6.2.2 節および 6.2.3 節で説明）も実行されません。 IRI 参照で追加的に許可される文字は、 Internationalized Resource Identifiers (IRIs) [RFC3987] の 6.5 節に従い、 URI 参照における未予約文字と同じ方法で扱われます。

@base または BASE ディレクティブは、 [RFC3986] 5.1.1 節「Base URI Embedded in Content」に従って相対 IRI 参照を解決するために使用される 基底 IRI を定義します。 5.1.2 節「Base URI from the Encapsulating Entity」は、 スコープ内の基底 IRI が、xml:base ディレクティブを持つ SOAP エンベロープや Content-Location ヘッダーを持つ MIME マルチパート文書などの カプセル化文書からどのように得られるかを定義します。 5.1.3 節「Base URI from the Retrieval URI」で識別される「Retrieval URI」は、 特定の TriG 文書が取得された URL です。 上記のいずれも基底 URI を指定しない場合は、 既定の基底 URI（5.1.4 節「Default Base URI」）が 使用されます。 各 @base または BASE ディレクティブは、 前のものに相対的に、新しいスコープ内基底 URI を設定します。

4.4 エスケープシーケンス

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

各種類のエスケープシーケンスを使用できるコンテキスト
数値
エスケープ 		文字列
エスケープ 		予約文字
エスケープ
PREFIX または BASE 宣言において、 RDF 項 として、またはそれらと同様に使用される IRI はい いいえ いいえ
ローカル 名 いいえ いいえ はい
String はい はい いいえ
注記

%-符号化シーケンスは IRI の文字範囲に含まれ、 ローカル名では明示的に許可されています。 これらは「%」の後に2つの16進文字が続くものとして現れ、 同じ3文字のシーケンスを表します。 これらのシーケンスは処理中にデコードされません。 TriG で <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 を指します。

4.5 文法

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

注記:

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

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

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

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

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

コード グリフ 説明
U+000A LF 改行
U+000D CR 復帰
U+0022 " 引用符
U+0023 # 番号記号
U+0027 ' アポストロフィ
U+002D - ハイフン
U+003B : コロン
U+0040 @ アット記号
U+005C \ バックスラッシュ
U+005F _ アンダースコア
U+0061 a ラテン小文字 E
U+007B { 左波括弧
U+007D } 右波括弧

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

space
U+0020
"""
それぞれがコードポイント U+0022 を持つ、連結された3つの引用符文字
'''
それぞれがコードポイント U+0027 を持つ、連結された3つのアポストロフィ文字
--
連結された2つの - 文字

5. 解析

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

5.1 パーサー状態

TriG の解析には、10個の項目からなる状態が必要です。

項コンストラクターは、「curSubject および curPredicate を記録する」 のような表現で示されるこれらの値のスタックを作成できます。

5.2 RDF 項コンストラクター

この表は、生成規則および字句トークンを、RDF 項 または RDF 項の構成要素として、 5. 解析に列挙されるものへ対応付けます。

生成規則 型 手順
IRIREF IRI < と > の間の文字を取り、 数値エスケープシーケンスを解除して、 IRI を形成します。相対 IRI 参照の解決は セクション 6.3 に従って行われます。 結果の IRI は、汎用 IRI 構文の構文上の制限に 適合しなければMUSTならず、[RFC3986] の 3.3 節に適合すべきSHOULDであり、 対応する IRI スキーム仕様によって課されるより狭い制限にも適合すべきです。
PNAME_NS prefix prefixID または sparqlPrefix 生成規則で使用される場合、 prefix は規則の第1引数に一致する、空の場合もある RDF 文字列です。 その文字列は namespaces マップのキーとして機能し、 展開された第2引数が将来の検索のためにそのキーの下に格納されます。
IRI PrefixedName 生成規則で使用される場合、iri は規則の第1引数に対応する namespaces マップ内の値です。
PNAME_LN IRI 空の場合もある prefix は、第1シーケンス PNAME_NS によって識別されます。 namespaces マップは、対応する namespace を 持たなければMUSTなりません。 IRI の RDF 文字列は、第2引数 PN_LOCAL 内の 予約文字をアンエスケープし、 それを namespace に連結することによって形成されます。 結果の IRI は、汎用 IRI 構文の 構文上の制限に 適合しなければMUSTならず、 対応する IRI スキーム仕様によって課されるより狭い制限にも適合すべきSHOULDです。
VersionSpecifier リテラル curVersion は、一致した RDF 文字列字句形式と xsd:string データ型を用いるリテラルから取得されます。
STRING_LITERAL_SINGLE_QUOTE 字句形式 最外側の ' の間の文字を取り、 数値および文字列エスケープ シーケンスをアンエスケープして、字句形式の Unicode 文字列を形成します。
STRING_LITERAL_QUOTE 字句形式 最外側の " の間の文字を取り、 数値および文字列エスケープ シーケンスをアンエスケープして、字句形式の Unicode 文字列を形成します。
STRING_LITERAL_LONG_SINGLE_QUOTE 字句形式 最外側の ''' の間の文字を取り、 数値および文字列エスケープ シーケンスをアンエスケープして、字句形式の Unicode 文字列を形成します。
STRING_LITERAL_LONG_QUOTE. 字句形式 最外側の """ の間の文字を取り、 数値および文字列エスケープ シーケンスをアンエスケープして、字句形式の Unicode 文字列を形成します。
LANG_DIR 言語タグ @ に続く文字は 言語タグを形成し、一致した文字に -- が含まれる場合は、任意で 初期テキスト方向も形成します。 言語タグは [BCP47] の 2.2.9 節に従って整形式でなければMUSTなりません。 存在する場合、初期テキスト方向は ltr または rtl のいずれかでなければMUSTなりません。
RDFLiteral リテラル リテラルは、第1規則引数 String の字句形式を持ちます。 '^^' iri 規則に一致する場合、 データ型 IRI は iri から導出され、リテラルは言語タグを持ちません。 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 トリプル項 トリプル項は、 ttSubject、 predicate、および ttObject 生成規則から構築された 項で構成されます。
reifiedTriple IRI | 空白ノード 項は、一致した reifier があればそれから、 または新しい RDF 空白ノードから取得されます。
annotationBlock IRI | 空白ノード 項は、以前に一致した reifier があればそれから、 または新しい RDF 空白ノードから取得されます。
注記

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

5.3 RDF トリプルの構築

TriG 文書は、1つの デフォルトグラフと 0 個以上の 名前付きグラフで構成される RDF データセット を定義します。 各グラフは、RDF トリプルの集合で構成されます。

5.3.1 出力グラフ

状態 curGraph は 最初は未設定です。これは、解析中に生成されるトリプルの グラフのラベルを記録します。 未定義の場合、デフォルトグラフが使用されます。

規則 labelOrSubject は curGraph と curSubject の両方を設定します （これらのうち使用されるのは一方だけです）。

次の文法生成規則句は、 curGraph を未定義に設定し、デフォルト グラフを示します。

  • 規則 block における文法生成規則句 wrappedGraph
  • 規則 triples2 における文法生成規則。

文法生成規則 labelOrSubject predicateObjectList '.' は、規則 triplesOrGraph において predicateObjectList 生成規則を処理する前に、 curGraph を解除します。

5.3.2 トリプル出力

生成された各 RDF トリプルは curGraph に追加されます。 解析処理のその時点で curGraph が設定されていない場合は、 デフォルトグラフに追加されます。

subject 生成規則は curSubject を設定します。 verb 生成規則は curPredicate を設定します。

トリプルは、解析処理の次の時点で生成され、 生成された各 RDF トリプルは curGraph によって識別されるグラフに追加されます。

5.3.3 トリプル生成

文書内の各 object N は、RDF トリプルを生成します。 curSubject curPredicate N.

5.3.4 具体化子

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

5.3.5 具体化されたトリプル

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

5.3.6 注釈

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

5.3.7 注釈ブロック

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

注記

curReifier がすでに設定されていた場合、 具体化トリプル curReifier rdf:reifies curTripleTerm は 5.3.4 具体化子で出力されています。

5.3.8 プロパティリスト

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

5.3.9 コレクション

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

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

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

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

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

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

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

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

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

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

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

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

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

TriG のインターネットメディア型（旧称 MIME Type）は "application/trig" です。

TriG ファイルは、すべてのプラットフォームで拡張子 ".trig"（すべて小文字）を持つことが推奨されます。

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

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

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

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

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

注記

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

注記

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

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

D. 謝辞

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

D.1 RDF 1.1 への謝辞

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

編集者は、元の TriG 仕様を作成した Chris Bizer および Richard Cyganiak の作業に感謝します。 このバージョンには Gregg Kellogg、Eric Prud'hommeaux および Sandro Hawke による貴重な貢献がありました。

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

D.2 RDF 1.2 への謝辞

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

編集者に加えて、次の人々がこの仕様に貢献しました: Andy Seaborne, Denis Ah-Kang, Niklas Lindström, Peter F. Patel-Schneider, Pierre-Antoine Champin, 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 の間の変更点

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

このセクションでは、RDF 1.1 勧告からの主な相違点を説明します。

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

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

F. 索引

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

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

G. 参考文献

G.1 規範的参考文献

[BCP47]
言語を識別するためのタグ. A. Phillips, Ed.; M. Davis, Ed. IETF. 2009年9月. Best Current Practice. 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 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 候補勧告. URL: https://www.w3.org/TR/rdf12-concepts/
[RFC2119]
RFC における要件レベルを示すための キーワード. S. Bradner. IETF. 1997年3月. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119
[RFC3629]
UTF-8、ISO 10646 の変換形式. F. Yergeau. IETF. 2003年11月. Internet Standard. URL: https://www.rfc-editor.org/rfc/rfc3629
[RFC3986]
統一資源識別子（URI）: 一般 構文. T. Berners-Lee; R. Fielding; L. Masinter. IETF. 2005年1月. Internet Standard. URL: https://www.rfc-editor.org/rfc/rfc3986
[RFC3987]
国際化資源識別子 （IRI）. M. Duerst; M. Suignard. IETF. 2005年1月. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc3987
[RFC6906]
'profile' リンク関係型. E. Wilde. IETF. 2013年3月. Informational. URL: https://www.rfc-editor.org/rfc/rfc6906
[RFC8174]
RFC 2119 キーワードにおける大文字と小文字の曖昧性. B. Leiba. IETF. 2017年5月. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc8174
[UNICODE]
Unicode 標準. Unicode Consortium. URL: https://www.unicode.org/versions/latest/

G.2 参考情報としての参考文献

[LANG-SUBTAG-REGISTRY]
Language Subtag Registry. IANA. URL: http://www.iana.org/assignments/language-subtag-registry/language-subtag-registry
[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年5月28日. W3C 作業草案. URL: https://www.w3.org/TR/rdf12-n-quads/
[RDF12-N-TRIPLES]
RDF 1.2 N-Triples. Gregg Kellogg; Dominik Tomaszuk. W3C. 2026年5月15日. W3C 作業草案. URL: https://www.w3.org/TR/rdf12-n-triples/
[RDF12-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 Primer. Pierre-Antoine Champin; Niklas Lindström. W3C. 2026年4月16日. DNOTE. URL: https://www.w3.org/TR/rdf12-primer/
[RDF12-SCHEMA]
RDF 1.2 Schema. Dominik Tomaszuk. W3C. 2026年3月28日. W3C 作業草案. URL: https://www.w3.org/TR/rdf12-schema/
[RDF12-SEMANTICS]
RDF 1.2 Semantics. Peter Patel-Schneider; Enrico Franconi; Dörthe Arndt. W3C. 2026年4月7日. W3C 候補勧告. URL: https://www.w3.org/TR/rdf12-semantics/
[RDF12-TURTLE]
RDF 1.2 Turtle. Gregg Kellogg; Andy Seaborne; Dominik Tomaszuk. W3C. 2026年5月28日. W3C 作業草案. URL: https://www.w3.org/TR/rdf12-turtle/
[RDF12-XML]
RDF 1.2 XML Syntax. Gregg Kellogg; Jerven Bolleman. W3C. 2026年4月9日. W3C 作業草案. URL: https://www.w3.org/TR/rdf12-xml/
[RFC3023]
XML メディア型. M. Murata; S. St. Laurent; D. Kohn. IETF. 2001年1月. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc3023
[RFC4288]
メディア型仕様および登録 手続き. N. Freed; J. Klensin. IETF. 2005年12月. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc4288
[RFC7231]
Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. R. Fielding, Ed.; J. Reschke, Ed. IETF. 2014年6月. Proposed Standard. URL: https://httpwg.org/specs/rfc7231.html
[SPARQL12-CONCEPTS]
SPARQL 1.2 Concepts. The W3C RDF & SPARQL Working Group. W3C. W3C 編集者草案. URL: https://w3c.github.io/sparql-concepts/spec/
[SPARQL12-ENTAILMENT]
SPARQL 1.2 Entailment Regimes. Peter Patel-Schneider. W3C. 2026年4月9日. W3C 作業草案. URL: https://www.w3.org/TR/sparql12-entailment/
[SPARQL12-FEDERATED-QUERY]
SPARQL 1.2 Federated Query. Ruben Taelman; Gregory Williams. W3C. 2026年4月23日. W3C 作業草案. URL: https://www.w3.org/TR/sparql12-federated-query/
[SPARQL12-GRAPH-STORE-PROTOCOL]
SPARQL 1.2 Graph Store Protocol. Andy Seaborne; Thomas Pellissier Tanon. W3C. 2024年12月19日. W3C 作業草案. URL: https://www.w3.org/TR/sparql12-graph-store-protocol/
[SPARQL12-NEW]
SPARQL 1.2 の新機能. The W3C RDF & SPARQL Working Group. W3C. W3C 編集者草案. URL: https://w3c.github.io/sparql-new/spec/
[SPARQL12-PROTOCOL]
SPARQL 1.2 Protocol. Andy Seaborne; Ruben Taelman; Gregory Williams; Thomas Pellissier Tanon. W3C. 2026年4月26日. W3C 作業 草案. URL: https://www.w3.org/TR/sparql12-protocol/
[SPARQL12-QUERY]
SPARQL 1.2 Query Language. Olaf Hartig; Andy Seaborne; Ruben Taelman; Gregory Williams; Thomas Pellissier Tanon. W3C. 2026年5月28日. W3C 作業草案. URL: https://www.w3.org/TR/sparql12-query/
[SPARQL12-RESULTS-CSV-TSV]
SPARQL 1.2 Query Results CSV and TSV Formats. Ruben Taelman; Gregory Williams; Thomas Pellissier Tanon. W3C. 2026年3月28日. W3C 作業草案. URL: https://www.w3.org/TR/sparql12-results-csv-tsv/
[SPARQL12-RESULTS-JSON]
SPARQL 1.2 Query Results JSON Format. Andy Seaborne; Ruben Taelman; Gregory Williams; Thomas Pellissier Tanon. W3C. 2026年3月28日. W3C 作業草案. URL: https://www.w3.org/TR/sparql12-results-json/
[SPARQL12-RESULTS-XML]
SPARQL 1.2 Query Results XML Format. Ruben Taelman; Dominik Tomaszuk; Thomas Pellissier Tanon. W3C. 2024年12月27日. W3C 作業草案. URL: https://www.w3.org/TR/sparql12-results-xml/
[SPARQL12-SERVICE-DESCRIPTION]
SPARQL 1.2 Service Description. Ruben Taelman; Gregory Williams. W3C. 2026年4月23日. W3C 作業 草案. URL: https://www.w3.org/TR/sparql12-service-description/
[SPARQL12-UPDATE]
SPARQL 1.2 Update. Ruben Taelman; Andy Seaborne; Thomas Pellissier Tanon. W3C. 2026年4月23日. W3C 作業草案. URL: https://www.w3.org/TR/sparql12-update/
[TRIG]
RDF 1.1 TriG. Gavin Carothers; Andy Seaborne. W3C. 2014年2月25日. W3C 勧告. URL: https://www.w3.org/TR/trig/
[UNICODE-SECURITY]
Unicode セキュリティに関する 考慮事項. Mark Davis; Michel Suignard. Unicode Consortium. 2014年9月19日. Unicode Technical Report #36. URL: https://www.unicode.org/reports/tr36/tr36-15.html