[6] tag:
は、
任意の文字列を識別子として使うための
URL scheme です。
[7] 00年代中頃 (平成時代中期)、 Semantic Web や Atom などの世界で一時流行しました。 その後それらの衰退と共に使われなくなりました。
本項は歴史的事項を説明しています。本項の内容の一部または全部は、現在の状況とは異なるかもしれません。
(なお本項の内容の一部または全部は、互換性または歴史的連続性のために現在も有効な場合もあります。しかし新たに利用することは避けるべきです。)
[8] tag:
URL は廃止されたわけではありませんから、
現在でも必要があれば使うことができます。しかし互換性などの制約が無い限り、
ほとんど有用性は無いと思われます。
[18]
tag:
URL
は、
URL scheme
の後に
tagging entity
と
specific
を
:
で区切って記述したものです。
素片識別子を使うこともできます。
>>11
tag:
URL[24]
tagging entity
(構文 taggingEntity)
は、
authority name
と日付を
,
で連結したものです。
tag:
URL
のうち名前空間として機能する部分です。
>>11
[56]
ある日付の時点である authority name を保有する者は一意に定まることから、
この組み合わせによって tag:
URL を一意にすることが意図されています。
>>11
[57] tagging entity は、 日付の UTC 0時0分時点で当該 authority name に割り当てられていた者を表します。 過去であっても構いません。 >>11
[65]
tag:
URL を割り当てる者は、
日付の 0時0分 UTC 時点で他者に割り当てられた
authority name
を使ってはなりません。
>>11
[67]
tag:
URL を割り当てる者は、
authority name
を一旦手放して再取得した場合に、
その間も割り当てられていたものと扱うことができます。
ただし、その間に未割当だったとする根拠を有していなければなりません。
>>11
[66]
tag:
URL を割り当てる者は、
将来の日付を使ってはなりません。
>>11
[72]
tag:
URL を扱うソフトウェアはそうした誤りを検出する補助機能を提供して構いません。
>>11
[74] 悪意ある者が1つの authority name を複数の者に割り当てられているように見せるかもしれませんから、 tagging entity となる者は評判の良い事業者を選んで注意して使うべきとされます。 >>11
tag:
以外の一般的なドメイン名やメールアドレスの用途に支障が出るような悪意あるサービスは、
評判の良し悪し以前に実用に耐えない詐欺か何かではないでしょうか。
そんな状況で
tag:
URL
を割り当てようとする人が出てくる危険性より、
悪意ある者が自身が利用権を持たない
authority name
を悪用する危険性の方が大きそうかつ簡単そうですが、
RFC 4151
はそちらには何も言及していません。[26] authority name (構文 authorityName) は、 ドメイン名またはメールアドレスです。 >>11
[40] 将来他の構文が認められるかもしれません。 処理するソフトウェアは、 構文に合致しないからといって拒絶してはなりません。 >>11
[33]
メールアドレス
(構文 emailAddress)
は、
1文字以上のASCII英数字、
-
,
.
,
_
の列の後に、
@
と
DNSname
を連ねたものです。
>>11
[35] インターネットメールの電子メールアドレスであることは文脈上明らかですが、 仕様書は RFC 2821 や RFC 2822 を参照しておらず、 この構文がどのような意味を持つのか明らかにしていません。
[36]
インターネットメールの電子メールアドレスと比べると、
local-part
相当の部分はかなり厳しい制限が加わっています。
インターネットメールで使える記号類のほとんどが認められません。
非ASCII文字も使えません。
ドメイン名部分はインターネットメールで使える
IPv6アドレスが認められません。
[42]
local-part
部分の大文字・小文字については明文規定がなく、
区別されるものと思われます。インターネットメールでも区別されます。
[28]
構文 DNSname は、
RFC 1035 ドメイン名を
.
区切りで0個以上のラベル (構文 DNScomp)
を連結したものです。
>>11
[37] 単体でもメールアドレスでも、 ドメイン名は完全修飾でなければなりません。 >>11
[84] と規定されていますが、実際には FQDN になっていない謎のホスト名なども使われています。
[39]
tag:
URL の比較では、ドメイン名の大文字と小文字は区別されます。
>>11
[43]
日付 (構文 date)
は、グレゴリオ暦、 UTC の年月日を -
で連結したものです。
>>11
[45] 年 (構文 year) は、4桁のASCII数字です。 月 (構文 month) は、2桁のASCII数字です。 日 (構文 day) は、2桁のASCII数字です。 >>11
[61] この日付は ISO 8601の日時形式とされます >>11。 年月日の値域の規定が RFC 4151 にはありませんが、 ISO 8601 の規定が適用されると思われます。 RFC 4151 は RFC 3339 も見よ、 と書いています >>11 が、 RFC 3339の日時形式の規定が適用されるとは書いておらず、 参照した理由は不明です。 >>11
[62] 月日を省略すると、1月1日を表します。 日を省略すると、1日を表します。 >>11
[63]
tag:
URL
を割り当てる者は、
0時0分 UTC
時点で自身に
authority name
が割り当てられているような精度の日付を用いなければなりません。
>>11
[76] clock skew によるずれを鑑み、 できれば数日の猶予がある authority name を使うべきです。 >>11
[64]
tag:
URL の比較では、
省略形と非省略形は区別されます。
>>11
[77] Unix time のようなより単純な日時形式を使わなかったのは、 他の部分の規定にあるように「人間可読性」を重視したためでしょうか。
[78] ただしその「人間」はグレゴリオ暦と西暦に慣れ親しんだ欧米人に限られています。
[79] といっても欧米人には馴染みが薄い大エンディアン (年月日順) が採用されていますし、月名ではなく月番号が採用されています。 実はこの日付形式が最も受け入れやすいのは、 年月日順、グレゴリオ暦、西暦年のどれにも馴染んでいる日本人の情報技術者かもしれません。
[80] でも UTC の日付という罠があります。英国在住の日本人の情報技術者が冬季に使うには適しているかもしれませんが、 それ以外の地域の人はうっかり地方時で書いてしまいそうです。
[81] これ、本当に「人間に優しい」ものだといえるのでしょうか?
[82]
機械は解釈しない、
人間が読み書きする、
人間に優しくするべきと言いながら構文の制限は厳しい、
という tag:
URL の矛盾した性質が凝縮されたのがこの日付の構文ではないでしょうか。
[46]
構文
specific
は、
RFC 3986 pchar,
/
,
?
の0文字以上の列です。
>>11
[48] specific は名前空間固有の部分であり、 URL を決める人が任意の文字列で構成できます。 人に優しくするべきです。 >>11
[50]
つまり簡潔な文字列でも構いませんし、
/
を使って path
風の階層構造を導入しても構いませんし、
?
を使って
query
風の構造を導入しても構いません。
すべては
authorityName
で表された名前空間の管理者の意志次第というわけです。
[51]
tag:
URL を規定した RFC 4151
が参照している、当時の URL 仕様である RFC 3986
は非ASCII文字の直接利用を認めていませんでした。
従って
tag:
の specific
でも非ASCII文字は構文上認められません。
[52]
ただし pchar
にはパーセント符号化が含まれていますので、
当時の IRI の仕様書 RFC 3987 に従えば、
IRI としては非ASCII文字を使うことができ、
URI として解釈するときには
UTF-8 でパーセント符号化することになります。
しかしそのような変換を介した関係性を、
tag:
URL の比較 (>>71) の場面でどう扱うべきかは疑問が残ります。
[54]
一方で、
tag:
URL
は人間の扱いやすさのためパーセント符号化を使うべきではないとされていました。
>>11
(この規定は specific の他に素片識別子も対象と思われます。)
[69] tagging entity は、その名前空間内の specific の固有性を保証するために、 記録を残す手続きを用いるべきです。 複数名で構成される tagging entity は、 グループの意思決定をも行って固有性を確保するべきです。 意思決定に基づき specific 内の階層構造の一部を移譲するような方法もあります。 >>11
[20]
素片識別子は、それが使えるということ以外特別の規定がなく、
当時の URL の仕様である RFC 3986 の一般の規則が参照されているだけでした。
>>11
[21]
一般に素片識別子は、 URL で指定された資源を、
関係するプロトコルを通じて取得して得られる表現に対して評価されるものです。
例えばそれが HTML文書だったなら、 id
属性値が一致する要素を探す、といった挙動を結び付いています。
[22]
ところが tag:
は特定のプロトコルと結び付いておらず (>>9)、
素片識別子はほとんど解釈し得ないものとなります。
[9] tag:
URL は特定のプロトコルと関連付けられたものではありませんでした。
解決 (resolution)
などの操作も規定されていません >>11。
[70] それは専ら識別子としての利用を想定したためで、 解決が必要なら他の URL scheme が適当とされました。 >>11
[14]
先行する tann:
URL scheme が同じような構文と用法を提案していました。
tag:
の方の初期案 >>5
と比較すると現行の tag:
はむしろ tann:
の影響が強いことがわかります。
[13]
Atom コミュニティーで好意的に受け入れられていました。
atom:id
などで積極的に使われました。
[17]
YAML は tag:
を推奨していました >>16。
[3] 【RDF】セマンティックウェブ【メタ情報】 http://pc5.2ch.net/test/read.cgi/hp/1057681807/422-
The tag algorithm lets people mint — create — identifiers that no one else using the same algorithm could ever mint. It is simple enough to do in your head, and the resulting identifiers can be easy to read, write, and remember.
[5] The tag: URI scheme ( 版) http://www.taguri.org/draft-2001-03-02.pdf
<guid isPermaLink="false">tag:soundcloud,2010:tracks/262680218</guid>
tag:
URL 全体が作られたり使われたりする日とは何の関係もありません。 既に失効したドメイン名や解約済みのメールアドレスでも、 過去の利用権を有していた日付がわかれば利用できます。