tag

tag: URL scheme

[6] tag: は、 任意の文字列識別子として使うための URL scheme です。

[7] 00年代中頃 (平成時代中期)、 Semantic WebAtom などの世界で一時流行しました。 その後それらの衰退と共に使われなくなりました。

代替

[8] tag: URL廃止されたわけではありませんから、 現在でも必要があれば使うことができます。しかし互換性などの制約が無い限り、 ほとんど有用性は無いと思われます。

仕様書

構文

[18] tag: URL は、 URL scheme の後に tagging entityspecific: で区切って記述したものです。 素片識別子を使うこともできます。 >>11

[19] tag: URL
  1. tag:
  2. tagging entity
  3. :
  4. specific
  5. ?
    1. #
    2. 素片

tagging entity

[24] tagging entity (構文 taggingEntity) は、 authority name日付, で連結したものです。 tag: URL のうち名前空間として機能する部分です。 >>11

[56] ある日付の時点である authority name を保有する者は一意に定まることから、 この組み合わせによって tag: URL を一意にすることが意図されています。 >>11

[25] taggingEntity
  1. authority name
  2. ,
  3. 日付

[57] tagging entity は、 日付UTC 0時0分時点で当該 authority name に割り当てられていた者を表します。 過去であっても構いません。 >>11

[58] つまりこの日付tag: URL 全体が作られたり使われたりするとは何の関係もありません。 既に失効したドメイン名や解約済みのメールアドレスでも、 過去の利用権を有していた日付がわかれば利用できます。
[59] ドメイン名が開発されるよりも前には遡り得ないことになります。

[65] tag: URL を割り当てる者は、 日付の 0時0分 UTC 時点で他者に割り当てられた authority name を使ってはなりません>>11

[67] tag: URL を割り当てる者は、 authority name を一旦手放して再取得した場合に、 その間も割り当てられていたものと扱うことができます。 ただし、その間に未割当だったとする根拠を有していなければなりません>>11

[66] tag: URL を割り当てる者は、 将来の日付を使ってはなりません>>11

[60] あくまで紳士協定的なものです。利用権限を確認したり、 利用権限のない者の利用を拒絶したりする仕組みはありません。 未到来の将来の日付の利用も仕組みとしては避けられません。
[68] 誰にも割り当てられていない authority name の利用を認める意図があるとは思えませんが、明示的には禁止されていないようです。

[72] tag: URL を扱うソフトウェアはそうした誤りを検出する補助機能を提供して構いません>>11

[73] 実際問題、有用な補助が提供できるか疑問ですし、そのようなソフトウェアが実在したかも不明です。

[74] 悪意ある者が1つの authority name を複数の者に割り当てられているように見せるかもしれませんから、 tagging entity となる者は評判の良い事業者を選んで注意して使うべきとされます。 >>11

[75] 事故によりドメイン名メールアドレスが複数の者に一時的に割り当てられることや、 ドメイン名メールアドレスを意図的に複数人で共有するサービスが提供されることはあるでしょうが、 それ以外に実際上そのようなことが起こり得るのでしょうか。 tag: 以外の一般的なドメイン名メールアドレスの用途に支障が出るような悪意あるサービスは、 評判の良し悪し以前に実用に耐えない詐欺か何かではないでしょうか。 そんな状況で tag: URL を割り当てようとする人が出てくる危険性より、 悪意ある者が自身が利用権を持たない authority name を悪用する危険性の方が大きそうかつ簡単そうですが、 RFC 4151 はそちらには何も言及していません。

[26] authority name (構文 authorityName) は、 ドメイン名またはメールアドレスです。 >>11

[27] authorityName
  1. |
    1. DNSname
    2. emailAddress

[40] 将来他の構文が認められるかもしれません。 処理するソフトウェアは、 構文に合致しないからといって拒絶してはなりません>>11

[41] 人々から忘れ去られつつあるので、そのような将来は到来しなそうですが。

[33] メールアドレス (構文 emailAddress) は、 1文字以上のASCII英数字-, ., _ の列の後に、 @DNSname を連ねたものです。 >>11

[35] インターネットメール電子メールアドレスであることは文脈上明らかですが、 仕様書は RFC 2821RFC 2822 を参照しておらず、 この構文がどのような意味を持つのか明らかにしていません。

[36] インターネットメール電子メールアドレスと比べると、 local-part 相当の部分はかなり厳しい制限が加わっています。 インターネットメールで使える記号類のほとんどが認められません。 非ASCII文字も使えません。 ドメイン名部分はインターネットメールで使える IPv6アドレスが認められません。

[42] local-part 部分の大文字小文字については明文規定がなく、 区別されるものと思われます。インターネットメールでも区別されます。

[34] emailAddress
  1. +
    1. |
      1. ASCII英数字
      2. -
      3. .
      4. _
  2. @
  3. DNSname

[28] 構文 DNSname は、 RFC 1035 ドメイン名. 区切りで0個以上のラベル (構文 DNScomp) を連結したものです。 >>11

[29] RFC 1035 を参照しつつも、構文は独自に規定されていました。 RFC 1123 は参照されていませんが、 RFC 1123 でのラベルの制限緩和が適用された構文となっていました。 DNSname
[30] ドメイン名ラベルの文字数制限が構文にも仕様書本文にも現れておらず、 適用されるのか不透明です。
[31] 末尾の点は認められていません。
[32] IDN は言及されていません。構文上 Unicodeラベルは使えず (従ってパーセント符号化しても書くことは出来ず)、 ASCIIラベルに変換してなら記述できます。

[37] 単体でもメールアドレスでも、 ドメイン名完全修飾でなければなりません>>11

[84] と規定されていますが、実際には FQDN になっていない謎のホスト名なども使われています。

[83] alternative rootの利用には触れられていません。 (IETF 的には触れられないのでしょうか。)

[38] ドメイン名小文字とするべきです>>11

[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 4151RFC 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

[44] date
  1. ?
    1. -
    2. ?
      1. -

[77] Unix time のようなより単純な日時形式を使わなかったのは、 他の部分の規定にあるように「人間可読性」を重視したためでしょうか。

[78] ただしその「人間」はグレゴリオ暦西暦に慣れ親しんだ欧米人に限られています。

[79] といっても欧米人には馴染みが薄い大エンディアン (年月日順) が採用されていますし、月名ではなく月番号が採用されています。 実はこの日付形式が最も受け入れやすいのは、 年月日順、グレゴリオ暦西暦年のどれにも馴染んでいる日本人情報技術者かもしれません。

[80] でも UTC日付という罠があります。英国在住の日本人情報技術者が冬季に使うには適しているかもしれませんが、 それ以外の地域の人はうっかり地方時で書いてしまいそうです。

[81] これ、本当に「人間に優しい」ものだといえるのでしょうか?

[82] 機械は解釈しない、 人間が読み書きする、 人間に優しくするべきと言いながら構文の制限は厳しい、 という tag: URL の矛盾した性質が凝縮されたのがこの日付の構文ではないでしょうか。

specific

[46] 構文 specific は、 RFC 3986 pchar, /, ? の0文字以上の列です。 >>11

[49] pchar にはパーセント符号化されたオクテットも含まれます。

[48] specific名前空間固有の部分であり、 URL を決める人が任意の文字列で構成できます。 人に優しく (human-friendly) するべきです>>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) の場面でどう扱うべきかは疑問が残ります。

[53] 当時の URI/IRI 仕様はかくも難解でした。 IRI

[54] 一方で、 tag: URL人間の扱いやすさ (tractability to humans) のためパーセント符号化を使うべきではないとされていました。 >>11 (この規定は specific の他に素片識別子も対象と思われます。)

[55] 非ASCII文字をほとんど使わない英語圏にあらずんば人にあらずという、 あまりに独善的な規定です。 この時代既に IETF では国際化の専門家と称する人々が幅を利かせて仕様制定手続きの過程でレビューしていたはずなのに、 どうしてこんな規定が平気で残存しているのですかね?
[47] specific
  1. *
    1. |
      1. pchar
      2. /
      3. ?

[69] tagging entity は、その名前空間内の specific の固有性を保証するために、 記録を残す手続きを用いるべきです。 複数名で構成される tagging entity は、 グループの意思決定をも行って固有性を確保するべきです。 意思決定に基づき specific 内の階層構造の一部を移譲するような方法もあります。 >>11

素片識別子

[20] 素片識別子は、それが使えるということ以外特別の規定がなく、 当時の URL の仕様である RFC 3986 の一般の規則が参照されているだけでした。 >>11 素片識別子 (ただしパーセント符号化は規制されていました (>>54)。)

[21] 一般に素片識別子は、 URL で指定された資源を、 関係するプロトコルを通じて取得して得られる表現に対して評価されるものです。 例えばそれが HTML文書だったなら、 id 属性値が一致する要素を探す、といった挙動を結び付いています。

[22] ところが tag: は特定のプロトコルと結び付いておらず (>>9)、 素片識別子はほとんど解釈し得ないものとなります。

[23] tag: URL の開発に関与した人々がそのことをどう認識していたのかは不明です。 当時 Semantic Web 界隈の人々は RDF の世界において取得操作が発生しない限りは任意の値が許されるといった超然的な解釈を導入していました。 素片識別子 tag: URLRDF URI参照と似た性質と近接した歴史背景を持ちますから、 同じような意識だったのかもしれません。

比較

[71] tag: URLの比較は、単純な文字列の比較によります。 >>11

プロトコル

[9] tag: URL は特定のプロトコルと関連付けられたものではありませんでした。 解決 (resolution) などの操作も規定されていません >>11

[70] それは専ら識別子としての利用を想定したためで、 解決が必要なら他の URL scheme が適当とされました。 >>11

日時

[14] 先行する tann: URL scheme が同じような構文と用法を提案していました。 tag: の方の初期案 >>5 と比較すると現行の tag: はむしろ tann: の影響が強いことがわかります。

文脈

[13] Atom コミュニティーで好意的に受け入れられていました。 atom:id などで積極的に使われました。

[17] YAMLtag:推奨していました >>16

歴史

[3] 【RDF】セマンティックウェブ【メタ情報】 http://pc5.2ch.net/test/read.cgi/hp/1057681807/422-

[4] Tag URI ( 版) http://www.taguri.org/

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

[10] ( 版) http://feeds.soundcloud.com/users/soundcloud:users:62921190/sounds.rss

<guid isPermaLink="false">tag:soundcloud,2010:tracks/262680218</guid>