ちょっとしたメモ

時間軸を使うURIスキーム、tag:がRFCに

今どきtagというと流行のfolksonomyのことと思ってしまいそうだが、これは全く別物で、tag:というスキームを用いる新しいURIを定義するもの。近くInformational RFCとなることが告知された。特徴としては、名前解決(リソース取得)を前提としないのでネットワーク上に存在しないものの名前付けに使いやすいこと;時間軸を持っているので、将来にわたって名前の衝突(重複)を回避できること;が挙げられる。

URIは、ブラウザなどでリソースを取得するための「アドレス」としてだけでなく、リソース一般を名前付け(識別)する役割を持つ。しかし、このときhttp:を使うと、そこには何か取得できるリソースがあるように思われやすいため、以前から混乱の要因になっていた。たとえば、名前空間URIにはその文書型のスキーマがあるべきかどうかとか、RDFのリソースはHTTPでアクセスできるのか、など。

tag:スキームは、次のように述べてその特徴を明確にした。

They are distinct from most other URIs in that there is no authoritative resolution mechanism. A tag may be used purely as an entity identifier. Furthermore, using tags has some advantages over the common practice of using "http" URIs as identifiers for non-HTTP-accessible resources.

名前付けという意味では、urn:スキームも同様だが、こちらはいろいろと登録が必要で面倒だ。これに対し、tag:の場合はドメイン名かメールアドレスを持っていれば、誰でも簡単にURIをつくることができる。

tag: URIの基本的な形は、「tag: DNS名もしくはメールアドレス ',' 年月日 ':' ローカル名」というもの。たとえば、pochiという名前のペットにURIを与えるならば、次のような具合だ。

(例)

tag:kanzaki.com,2005-02-25:pochi
tag:webmaster@kanzaki.com,2005:pochi

日付の部分は、年-月-日、年-月、年のどれでもよいが、月(日)を省略するとその年(月)の最初の日を表す。この日付を加えることで、来年にこのサイトのウェブマスターが誰かに交代したとしても、このURIで識別している内容は不変ということになるわけだ(URIと時間の関係は長年のテーマであり、tag:によく似たurn:duri:という提案もあった)。

FOAFでは、人間にURIを与える一般的な規則がなかったり、「私は人間であってURIじゃない」みたいな話もあったり(もちろんそれは勘違い)してコンセンサスがとりにくいことから、通常はfoaf:Person型リソースにはURIを与えず、foaf:mboxなどのIFPで識別しているわけだが、tag:スキームURIなら、案外すきりいくかもしれない(関連スレッド)。もっとも、メールアドレスをURIの一部に使うのはプライバシー上は嬉しくない部分もあるから、sha1が使えるIFPの方が便利ではあるけれども。

なお、tag:スキームのRFCはまだ発行されていないが、最終版のインターネットドラフトThe 'tag' URI schemeで内容を確認することができる。2005年10月にRFC 4151として公開された。

関連メモ: