[8] N-Triples は、 RDF の記述形式の1つです。
[26]
適合N-Triples文書
(ntriplesDoc
)
は、
仕様書の該当する文法と制約に適合する
Unicode文字列です。
N-Triples文書は、
RDFグラフを直列化したものです。
>>7
[19] 構文にはある程度の自由度がありますが、 実装は正準形である Canonical N-Triples を出力することが推奨されています。 >>7
[27] 適合正準N-Triples文書は、 Canonical N-Triples の追加の制約に従うN-Triples文書です。 >>7
[38] N-Triples文書は、 0個以上の三項組を、 改行で区切ったものです。 ただし、先頭行と最終行は空行にできます。 >>7
[71] 構文解析器は、 三項組を処理した結果で構成されるRDFグラフを返します。 >>7
[49]
改行は、
U+000D
,
U+000A
の1つ以上の列です。
>>7
[77] 構文解析器が N-Triples文書でない Unicode文字列を与えられた時、 どう動作するべきかは不明です。
[10]
単純三項組は、
(主語、述語、目的語) の語を、
空白で区切って、
最後に
.
を付けたものです。
>>7
[20]
正準形では、
3項の間の空白は U+0020
1つでなければなりません。
それ以外はあってはなりません。
>>7
[70] 構文解析器は、 主語、述語、目的語を処理した結果から構成される三項組を返します。 >>7
[41] 主語は、 IRI または空白節点ラベルです。 >>7
[43] 目的語は、 IRI または 空白節点ラベルまたはリテラルです。 >>7
[18]
空白節点は、
_:
に空白節点ラベルを続けて記述します。
同じ空白節点ラベルを持つもの同士が同じ空白節点と解釈されます。
>>7
[69]
構文解析器は、
空白節点ラベルの _:
の後の文字列を鍵とします。
bnodeLabels
[ 鍵 ]
があれば、それを使います。
なければ、それを新しい空白節点とします。
>>7
[35]
空白は、
U+0009
,
U+0020
,
注釈です。
>>7
[36] 空白は、終端記号間の区切りとして挿入できます。 仕様書にはそれがなければ誤認識されるところで使える >>7 としか書かれていないのですが、それ以外でも挿入できそうなふいんきです。
[21] 正準形では、 三項組に関するもの (>>20) を除き、 字句間の空白を挿入してはなりません。 >>7
[37]
注釈は、
#
から次の改行まで、なければファイル末までです。
>>7
[22] 正準形では、 注釈を挿入してはなりません。 >>7
[80] 仕様書は行間を読むことを求めて明記していないようですが、 字句間の空白は構文解析器が字句化段階で捨てて、無視します。
[12] リテラルは、 字句形の後に、 言語タグかデータ型IRIを書くか、 何も書きません。 >>7
[67] 構文解析器は、構成する字句から三項組を得ます。 >>7
[13]
字句形は、
"
で囲んで書きます。
数値エスケープシーケンスか文字列エスケープシーケンスを使えます。
>>7
[14]
リテラルでは、
"
,
CR
,
LF
,
\
をそのまま書けません。
>>7
[81]
N-Triples としての要件ではありませんが、
RDFリテラルとしてのデータモデル側の規定で、
字句形は NFC であるべきとされています。
[64]
構文解析器は、
"
の間の文字列を取り出し、
エスケープシーケンスを
unescape
して、
字句形を得ます。
>>7
[15]
言語タグを書くときは、前に @
を書きます。
>>7
[82] RDFリテラルとしてのデータモデルの規定では、 整形式のIETF言語タグでなければならないとされています。 N-Triples としてはそれよりも緩い構文になっており、 N-Triples の実装はそれを扱える必要があるのでしょうが、 その前後の RDF としての処理で、非整形式の言語タグがどう扱われるか不確かです。
[65]
構文解析器は、
@
の後の文字列を取り出し、
言語タグを得ます。
>>7
[16]
データ型IRIを書くときは、
前に ^^
を書きます。
>>7
[17]
データ型IRIも言語タグもないときは、
単純リテラルを表し、
データ型は
http://www.w3.org/2001/XMLSchema#string
となります。
>>7
[66] 言語タグがあるときは、
データ型は
rdf:langString
となります。
>>7
[11]
IRI
は、
絶対IRI
を
<
と
>
で囲んで書きます。
数値エスケープシーケンスを使えます。
>>7
[53] 構文上は空文字列も相対IRIも書けますが、 絶対IRIを書くという規定になっています。
[54]
IRI では、
CL,
U+0020
,
<
,
>
,
"
,
{
,
}
,
|
,
^
,
`
,
\
はそのままでは書けません。
>>7
[83] 絶対IRIでないものを N-Triples として構文的には扱えるので、 N-Triples の実装はそれを扱えないといけないと思われますが、 その前後の RDF としての処理でこれがどうなるのかは不明です。
[62]
構文解析器は、
<
と >
の間の文字列を取り出し、
エスケープシーケンスを
unescape
して、
IRI
を得ます。
>>7
[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」
と意味を定義しているので、それらの意味は未定義なのですが、
構文上それを禁止する規定もありません。
[28] 適合N-Triples構文解析器は、 応用のためにN-Triples文書を読む能力を擁するシステムです。 何らかの形の API によって、応用に対して、 N-Triples文書として直列化された RDFグラフの情報を提供します。 >>7
[76] 正準N-Triples文書が規定されていますが、相当する構文解析器は規定されていません。 正準形しか受理しない実装は想定されていないようです。
[30] MIME型は application/n-triples
です。
>>7
[32]
歴史的に text/plain
も使われてきました。
その場合構文上の制約があります (>>33)。
ただしそれはN-Triples文書ではないとされます。
>>7
[31]
N-Triples
は
Turtle
の部分集合であることから、
N-Triples文書のMIME型を
text/turtle
としてもよいとされます。
ただしそれは
N-Triples文書ではないとされます。
>>7
(哲学)
[29] 識別用の URL
は
http://www.w3.org/ns/formats/N-Triples
とされています。
>>7
[74] Macintoshファイル型は TEXT
です。
>>7
[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
[86] 単純な構文なのに仕様書の規定はがばがばやないか
[93] 構文に関する規定の欠陥のいくつかはメーリングリストに投稿され >>91, >>94、 Errata にも掲載されていますが >>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 系の行指向のツールでも処理しやすくなったんじゃないですかね?