今どき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として公開された。
- httpRange-14あるいはhttp:型URIの適用範囲 (2005-06-22)
- 作者を表すURIとホームページのURI (2005-07-23)