application/ntriples

N-Triples

[8] N-Triples は、 RDF の記述形式の1つです。

目次

  1. 仕様書
  2. 構文
    1. 三項組
    2. 空白
    3. リテラル
    4. IRI
    5. エスケープシーケンス
  3. 文字コード
  4. 処理
  5. MIME型
  6. 識別子
  7. 関連
  8. 歴史

仕様書#

構文#

[26] 適合N-Triples文書 (ぶんしょ) (document) (ntriplesDoc) は、 仕様書の該当する文法と制約に適合する Unicode文字列です。 N-Triples文書は、 RDFグラフ直列化したものです。 >>7

[19] 構文にはある程度の自由度がありますが、 実装は正準形である Canonical N-Triples を出力することが推奨 (encourage) されています。 >>7

[27] 適合正準 (せいじゅん) (Canonical) N-Triples文書 (document) は、 Canonical N-Triples の追加の制約に従うN-Triples文書です。 >>7

[38] N-Triples文書は、 0個以上三項組を、 改行で区切ったものです。 ただし、先頭行と最終行は空行にできます。 >>7

[71] 構文解析器は、 三項組を処理した結果で構成されるRDFグラフを返します。 >>7

[39] N-Triples文書
空白三項組空白改行空白三項組空白改行空白

[49] 改行は、 U+000D, U+000A の1つ以上の列です。 >>7

[50] この定義では空行は認められますが、 空白だけが含まれるは認められません。
[51] 改行
U+000DU+000A

[77] 構文解析器N-Triples文書でない Unicode文字列を与えられた時、 どう動作するべきかは不明です。

三項組#

[10] 単純三項組 (simple triple) は、 (主語述語目的語) の (term) を、 空白で区切って、 最後に . を付けたものです。 >>7

[20] 正準形では、 3項の間の空白U+0020 1つでなければなりません。 それ以外はあってはなりません>>7

[70] 構文解析器は、 主語述語目的語を処理した結果から構成される三項組を返します。 >>7

[40] 三項組
主語空白述語空白目的語空白.

[41] 主語は、 IRI または空白節点ラベルです。 >>7

[44] 主語
IRI空白節点ラベル

[42] 述語は、 IRI です。 >>7

[45] 述語
IRI

[43] 目的語は、 IRI または 空白節点ラベルまたはリテラルです。 >>7

[46] 目的語
IRI空白節点ラベルリテラル

[18] 空白節点は、 _:空白節点ラベルを続けて記述します。 同じ空白節点ラベルを持つもの同士が同じ空白節点と解釈されます。 >>7

[69] 構文解析器は、 空白節点ラベル_: の後の文字列とします。 bnodeLabels [ ] があれば、それを使います。 なければ、それを新しい空白節点とします。 >>7

空白#

[35] 空白 (white space) は、 U+0009, U+0020, 注釈です。 >>7

[36] 空白は、終端記号間の区切りとして挿入できます。 仕様書にはそれがなければ誤認識されるところで使える >>7 としか書かれていないのですが、それ以外でも挿入できそうなふいんきです。

[21] 正準形では、 三項組に関するもの (>>20) を除き、 字句間の空白を挿入してはなりません>>7

[78] 空白
U+0009U+0020注釈

[37] 注釈 (comment) は、 # から次の改行まで、なければファイル末までです。 >>7

[22] 正準形では、 注釈を挿入してはなりません>>7

[79] 注釈
#改行以外の文字改行

[80] 仕様書は行間を読むことを求めて明記していないようですが、 字句間の空白構文解析器字句化段階で捨てて、無視します。

リテラル#

[12] リテラルは、 字句形の後に、 言語タグデータ型IRIを書くか、 何も書きません。 >>7

[67] 構文解析器は、構成する字句から三項組を得ます。 >>7

[68] 三項組
字句形
字句形から得た字句形
データ型IRI
リテラルから決まるデータ型
言語タグ
言語タグから決まる言語タグ (あれば)
[47] リテラル
字句形空白^^空白IRI空白言語タグ

[13] 字句形は、 " で囲んで書きます。 数値エスケープシーケンス文字列エスケープシーケンスを使えます。 >>7

[14] リテラルでは、 ", CR, LF, \ をそのまま書けません。 >>7

[81] N-Triples としての要件ではありませんが、 RDFリテラルとしてのデータモデル側の規定で、 字句形NFC であるべきとされています。 RDFリテラル NFC は破壊的な操作で、任意の自然言語文を扱うのは危険です。 正規化 N-Triples としては何の規定もないので素通しするのが妥当な実装でしょうが、 その前後の RDF としての処理の段階でどう扱われるか不安が残ります。

[64] 構文解析器は、 " の間の文字列を取り出し、 エスケープシーケンスunescape して、 字句形を得ます。 >>7

[63] 字句形
"リテラルの文字ECHARUCHAR"

[15] 言語タグを書くときは、前に @ を書きます。 >>7

[82] RDFリテラルとしてのデータモデルの規定では、 整形式IETF言語タグでなければならないとされています。 N-Triples としてはそれよりも緩い構文になっており、 N-Triples の実装はそれを扱える必要があるのでしょうが、 その前後の RDF としての処理で、非整形式言語タグがどう扱われるか不確かです。

[65] 構文解析器は、 @ の後の文字列を取り出し、 言語タグを得ます。 >>7

[48] 言語タグ
@ASCII英字-ASCII英数字

[16] データ型IRIを書くときは、 前に ^^ を書きます。 >>7

[17] データ型IRI言語タグもないときは、 単純リテラルを表し、 データ型http://www.w3.org/2001/XMLSchema#string となります。 >>7

[66] 言語タグがあるときは、 データ型rdf:langString となります。 >>7

IRI#

[11] IRI は、 絶対IRI<> で囲んで書きます。 数値エスケープシーケンスを使えます。 >>7

[53] 構文上は空文字列相対IRIも書けますが、 絶対IRIを書くという規定になっています。

[54] IRI では、 CL, U+0020, <, >, ", {, }, |, ^, `, \ はそのままでは書けません。 >>7

[83] 絶対IRIでないものを N-Triples として構文的には扱えるので、 N-Triples の実装はそれを扱えないといけないと思われますが、 その前後の RDF としての処理でこれがどうなるのかは不明です。

[62] 構文解析器は、 <> の間の文字列を取り出し、 エスケープシーケンスunescape して、 IRI を得ます。 >>7

[52] IRI
<IRIの文字UCHAR>

エスケープシーケンス#

[75] エスケープシーケンスTurtle と同じと規定されています >>7

[33] MIME型text/plain とするときは、 US-ASCII 以外の文字はエスケープシーケンスとしなければなりません>>7

[84] という文書に対する要件はありますが、 構文解析器非ASCII文字に遭遇した時どう処理するべきか不明です。


[55] UCHAR は、 \u の後に4桁の十六進数を続けたものか、 \U の後に8桁の十六進数を続けたものです。 >>7

[23] 正準形では、 十六進数大文字でなければなりません>>7

[24] 正準形では、 文字UCHAR としてはなりません>>7

[85] 構文解析器が、 U-00110000 以上の値が与えられたときや、 サロゲート符号点が与えられた時、どうするべきかは不明です。 Turtle の仕様書は 「A Unicode character in the range U+0000 to U+10FFFF inclusive」 と意味を定義しているので、それらの意味は未定義なのですが、 構文上それを禁止する規定もありません。

[58] リテラル字句形IRI で使えます。

[56] UCHAR
\u十六進数十六進数十六進数十六進数\U十六進数十六進数十六進数十六進数十六進数十六進数十六進数十六進数

[57] ECHAR は、 \t, \b, \n, \r, \f, \", \', \\ のいずれかです。 >>7

[59] リテラル字句形で使えます。

[25] 正準形では、 ", \, CR, LF 以外文字ECHAR としてはなりません>>7

文字コード#

[34] UTF-8 で符号化します。 >>7

[72] UTF-8 として不正な入力が与えられた時の構文解析器の挙動は規定がなく不明です。

処理#

[28] 適合N-Triples構文解析器 (parser) は、 応用のためにN-Triples文書を読む能力を擁するシステムです。 何らかの形の API によって、応用に対して、 N-Triples文書として直列化された RDFグラフの情報を提供します。 >>7

[60] 構文解析器は、次の状態を持ちます。

[61] N-Triples構文解析器
bnodeLabels
文字列から空白節点への写像

[76] 正準N-Triples文書が規定されていますが、相当する構文解析器は規定されていません。 正準形しか受理しない実装は想定されていないようです。

MIME型#

[30] MIME型application/n-triples です。 >>7

[32] 歴史的に text/plain も使われてきました。 その場合構文上の制約があります (>>33)。 ただしそれはN-Triples文書ではないとされます。 >>7

[31] N-TriplesTurtle部分集合であることから、 N-Triples文書MIME型text/turtle としてもよいとされます。 ただしそれは N-Triples文書ではないとされます。 >>7 (哲学)

識別子#

[29] 識別用の URLhttp://www.w3.org/ns/formats/N-Triples とされています。 >>7

[73] 拡張子.nt です。 >>7

[74] Macintoshファイル型TEXT です。 >>7

関連#

[9] N3部分集合とされています。

歴史#

[6] RDF 1.0 時代はテスト記述用のおまけのような扱いだったのが、 RDF 1.1 で独立したW3C勧告に格上げされたようです。

[1] RDF 1.1 N-Triples ( ( 版)) http://www.w3.org/TR/2013/CR-n-triples-20131105/

[2] RDF 1.1 N-Triples ( ( 版)) http://www.w3.org/TR/2014/REC-n-triples-20140225/

[3] RDF 1.1 N-Triples ( ( 版)) http://www.w3.org/TR/n-triples/

[4] RDF Test Cases ( ( 版)) http://www.w3.org/TR/2004/REC-rdf-testcases-20040210/#ntriples

[5] Documentation | HyperGraphQL () http://hypergraphql.org/documentation

Pure RDF content types

application/rdf+xml

application/turtle

text/turtle

application/ntriples

text/ntriples

application/n3

text/n3

[86] 単純な構文なのに仕様書の規定はがばがばやないか

[93] 構文に関する規定の欠陥のいくつかはメーリングリストに投稿され >>91, >>94Errata にも掲載されていますが >>92、 仕様書本体はその後長年放置されています。

[95] WG も放置したまま解散してしまったようだし...

[96] それにしても一度でも誰かが実装すれば気づきそうな誤りばかりなのですが、 W3C勧告のレビュープロセスはいつもがばがばですね...

[97] 誰も実装してないのかな、と思いきや実装していて互換性がないみたいですよww >>94

[98] N-Triples Implementation Report, , https://www.w3.org/2013/N-TriplesReports/index.html

[99] リテラルIRI も絶対に改行を生で含むことがないのだから、 1行1文にしてしまえば Unix 系の行指向のツールでも処理しやすくなったんじゃないですかね?