793.txt

[6] [DFN[[CODE(URI)@en[[[tag:]]]]]] は、
任意の[[文字列]]を[[識別子]]として使うための
[[URL scheme]] です。

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

* 代替

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

* 仕様書

[REFS[
- [11] [CITE@en[[[RFC 4151]] - The 'tag' URI Scheme]] ([TIME[2017-05-07 16:48:27 +09:00]]) <https://tools.ietf.org/html/rfc4151>
- [12] [CITE[RFC Errata Report » [[RFC Editor]]]], [TIME[2021-07-14T03:39:30.000Z]] <https://www.rfc-editor.org/errata_search.php?rfc=4151&rec_status=0>
]REFS]

* 構文

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

[FIG(railroad)[ [19] [CODE[tag:]] [[URL]]
= [CODE[tag:]]
= [VAR[taggingEntity]]
= [CODE[:]]
= [VAR[specific]]
= ?
== [CODE[#]]
== [[素片][素片識別子]]

]FIG]

** [VAR[taggingEntity]]

[24] 
[DFN[[VAR[taggingEntity]]]]
は、
[VAR[authorityName]]
と
[VAR[date]]
を
[CODE[,]]
で連結したものです。
[CODE[tag:]]
[[URL]]
のうち[[名前空間]]として機能する部分です。
[SRC[>>11]]

[FIG(railroad)[ [25] [VAR[taggingEntity]]
= [VAR[authorityName]]
= [CODE[,]]
= [VAR[date]]

]FIG]

-*-*-

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

[FIG(railroad)[ [27] [VAR[authorityName]]
= |
== [VAR[[[DNSname]]]]
== [VAR[[[emailAddress]]]]

]FIG]

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


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

-*-*-

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

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

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


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


[FIG(railroad)[ [34] [VAR[emailAddress]]
= +
== |
=== [[ASCII英数字]]
=== [CODE[-]]
=== [CODE[.][FULL STOP]]
=== [CODE[_]]
= [CODE[@]]
= [VAR[DNSname]]
]FIG]


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

;; [29] [[RFC 1035]] を参照しつつも、構文は独自に規定されていました。
[[RFC 1123]] は参照されていませんが、
[[RFC 1123]] での[[ラベル]]の制限緩和が適用された構文となっていました。
[SEE[ [[DNSname]] ]]

;;
[30] 
[[ドメイン名]]の[[ラベル]]の文字数制限が構文にも仕様書本文にも現れておらず、
適用されるのか不透明です。

;; [31] 
[[末尾の点]]は認められていません。

;; [32] 
[[IDN]] は言及されていません。構文上 [[Unicodeラベル]]は使えず
(従って[[パーセント符号化]]しても書くことは出来ず)、
[[ASCIIラベル]]に変換してなら記述できます。


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


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

[39] 
[CODE[tag:]] [[URL]] の比較では、[[ドメイン名]]の[[大文字]]と[[小文字]]は区別されます。
[SRC[>>11]]





** 素片識別子

[20] 
[[素片識別子]]は、それが使えるということ以外特別の[[規定]]がなく、
当時の [[URL]] の仕様である [[RFC 3986]] の一般の規則が参照されているだけでした。
[SRC[>>11]]
[SEE[ [[素片識別子]] ]]

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

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

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



* プロトコル

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

* 日時

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

* 文脈

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

[17] 
[[YAML]] は [CODE[tag:]] を[[推奨]]していました [SRC[>>16]]。

[REFS[
- [16] [CITE[YAML Ain’t Markup Language ([[YAML]]™) Version 1.2]], [TIME[2021-06-13T20:39:49.000Z]], [TIME[2021-07-14T03:53:33.857Z]] <http://yaml.org/spec/1.2/spec.html#id2764295>
]REFS]

* 歴史

- [1]
[CITE[Tag URI]] <http://www.taguri.org/>
-- [15] 
[CITE[Tag URI draft history]], [TIME[2009-01-06T16:25:13.000Z]], [TIME[2021-07-14T03:51:42.178Z]] <http://www.taguri.org/draftHistory.html>

- [2]
[CITE[Webweavers - weavin' - [[Tag URI]] vs [[FOAF]] IFP]] <http://webweaver.g.hatena.ne.jp/kotastyle/20050106/p2>
-- 消滅確認 [TIME[2021-07-14T03:45:11.900Z]]
-- [CITE[Webweavers - weavin' - [[Tag URI]] vs FOAF IFP]], [TIME[2021-07-14T03:44:56.000Z]], [TIME[2005-03-26T18:37:52.317Z]] <https://web.archive.org/web/20050326183747/http://webweaver.g.hatena.ne.jp/kotastyle/20050106/p2>


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


[FIG(quote)[
[FIGCAPTION[
[4] [CITE[Tag URI]]
([TIME[2011-03-23 23:32:27 +09:00]] 版)
<http://www.taguri.org/>
]FIGCAPTION]

> 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. 

]FIG]


[5] [CITE[The tag: URI scheme]]
([TIME[2004-02-13 05:01:34 +09:00]] 版)
<http://www.taguri.org/draft-2001-03-02.pdf>

[FIG(quote)[
[FIGCAPTION[
[10] ([TIME[2016-05-06 12:26:53 +09:00]] 版)
<http://feeds.soundcloud.com/users/soundcloud:users:62921190/sounds.rss>
]FIGCAPTION]

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

]FIG]