リンク関係型

リンク型 (HTML)

[39] リンク型 (link type) は、リンクにおける関係の種類を表す短い文字列です。

[180] 例えば、「次のページへのリンクである」、「スタイルシートへのリンクである」、 「上の階層へのリンクである」といったようなリンクの意味を記述できます。

仕様書

呼称

[216] HTML Standard は本項の概念をリンク型 (link type) と呼んでいます。

[217] 例外的に、 <link type> 属性の処理に関する規定1箇所と、 廃止された rev 属性の処理に関する規定1箇所でのみリンク関係性 (link relationship) 、 他の仕様書引用1件でのみリンク関係 (link relation) と呼んでいます。

[218] Web Linking とそれに従う仕様書は、本項の概念をリンク関係 (link relation) リンク関係型 (link relation type) と呼んでいます。

[219] 「関係」というのはこの値を含める HTML属性名rel であるように、 リンク始点終点の関係性を説明するための値であることに由来する語と思われます。

[220] rel=stylesheet のような外部資源リンクrel=noreferrer のようなハイパーリンク注釈などの広範な用法を踏まえれば、 リンク型という呼称の方が適切かもしれません。

意味

[32] リンク型は、リンクにおける始点終点との関係や性質を記述するものです。 リンクには、0個以上のリンク型を指定することができます。 リンク型には外部資源へのリンクであることを表すものと、 ハイパーリンクであることを表すものがあります。

[181] stylesheetスタイルシートという外部資源へのリンクを表しています。 人間利用者が直接使うことは想定されておらず、利用者エージェントが自動的に読み込むべきリンクです。

[182] 一方で next は次のページへのハイパーリンクを表しています。

[33] リンク型は元々 HTMLリンク関連の要素で規定されたものですが、 それに影響されて HTTPAtom などでも類似した仕組みが採用されています。


[227] HTML では、リンク型外部資源リンクを作るもの、 ハイパーリンクを作るもの、それにハイパーリンクを補足するハイパーリンク注釈の3種類に分類しています。

[228] 更に細かく次のように分類されると考えられます。

構文

リンク型の構文

[19] リンク型は、 HTML Standard または microformats wiki で示された値のいずれかとされています >>18microformats wiki には誰でも値を追加できることになっています >>18

[20] リンク型ASCII大文字・小文字不区別です >>11。 また microformats wiki に登録する値に : が含まれる時は、 絶対URLでなければなりません。それ以外に構文的制約はありませんが、 実用上は rel 属性で使うため、 1文字以上の間隔文字以外の文字の列とする必要があります。

[26] 適合性検査器は、 microformats wiki の内容を使わなければなりませんHTML Standardmicroformats wiki で承認されている値は認められ、 拒絶されている値や掲載されていない値は認められないとしなければなりません。 また掲載されていない値があれば、登録を勧めるべきです>>18

リンク型の集合の構文

[13] HTML rel 属性では、 値は字句の間隔分離集合とされています。ここで各キーワードは、 リンク型でなければなりません。キーワードASCII大文字・小文字不区別です >>11。原則として同じ値を複数指定してはなりません >>11

[17] リンク型のキーワードが含まれるか決定する時は、間隔で分割して ASCII大文字・小文字不区別で比較しなければなりません >>11

[14] rel 属性の項を参照。

[85] 含まれるリンク型は、それぞれ独立して解釈されます。ただし、 次の例外があります。

[170] pingback は他のリンク型との併用を禁じています。

リンク型とマーク付け言語

[51] リンク型およびその派生系は色々なマーク付け言語プロトコルで採用されています。 個々のリンク型の値も、複数のマーク付け言語で共通して使われているものがあります。 しかし、すべてのリンク型がすべての文脈で使えるわけではありませんし、 使えるかどうか明確になっていない組み合わせも多々あります。

[171] 文脈によっては、特定のリンク型を有する要素が必須だったり、 禁止されていたりすることがあります。

[52] HTMLリンク型は、 link 要素で使えるか否か、 a 要素および area 要素で使えるか否かがそれぞれ規定されることになっています。 ただし HTML Standardmicroformats wiki に登録されていないリンク型は、 これらを明確に規定していないことがよくあります。

[53] Web Linking に基づくリンク型は、 HTTP Link: ヘッダーなど Web Linking を採用する文脈で使うことができます。 しかし Web Linking を採用するマーク付け言語は多く、 明示的に禁止されていなくてもどう解釈するべきか定まらない組み合わせもあります。 明確に認められていない限り利用できないと保守的に解釈するのが相互運用性のためには好ましいのかもしれません。

Web Linking対象属性群の項も参照。

[54] Web Linking および関連仕様は HTML4Web Linking の応用だと主張していますが、 HTML4 はそのように規定していませんし、 HTML Standard の規定とも整合していません。個別のリンク型HTML でも使えるように規定・登録されていない限り、 Web Linking リンク型HTML で使えるわけではありませんし、 同名で登録されていても意味や処理方法が同じとは限りません。

[194] HTMLWeb Linkingリンク型ASCII大文字・小文字不区別ですが、 Atom では区別されます。 その他の仕様でも、区別するかどうかはそれぞれに異なります。

[204] Atomリンク関係型IANA登録簿Web Linking に乗っ取られましたが、 Atom 自体は改訂されていないので、 これをどう解釈するべきかは謎に包まれています。 例えば IANA登録簿convertedFrom という値が登録されており、 Web Linking としては convertedfrom とも CONVERTEDFROM とも同じ値という扱いです。 Atomrel 属性値convertedfrom が指定されたとき、これが IANA登録簿にある convertedFrom であると解釈できるのかどうかは不明です。

[81] HTML は複数のリンク型を組み合わせて特別な意味を表すことがありますが (例えば alternate stylesheetup up)、 Atom など一部のマーク付け言語では同時に複数のリンク型を指定することを認めていません。

[193] AtomURL でないリンク型http://www.iana.org/assignments/relation/ を前に連結したものと等価だと規定しています (>>79) が、 Atom更新する Web Linking にはそのような規定はありませんし、 HTML その他のリンク型の仕様にもそのような規定はありませんから、 http://www.iana.org/assignments/relation/ が含まれるリンク型をどう解釈するべきかは定かではありません。

[60] RDFarel 属性rev 属性を独自の用法に流用していますが、この用法は HTML Standard の規定と矛盾しています。 RDFa を採用している実装とそれ以外では、 同じリンク型でも解釈が全く異なることがあり得ます。

[196] BEACONRFC 3986 URI または RFC 5988IANA 登録済みリンク関係を使えるとしています。 RDF写像する際の省略時の既定値は http://www.w3.org/2000/01/rdf-schema#sameAs と定義しています。 URI でないリンク関係写像はありません。

[179]言語はそれぞれの応用のためにそれぞれの語彙を規定しているのですから、 リンク型を1つ定義すればどこでも使えるというのは安易すぎます。(もちろんばらばらであるよりは、 整合性があった方が好ましいのでしょうが。) HTML に限っても、 リンクを表す要素は多数あり、どこでどのリンク型を使うことができ、 どのような意味を表し、どう処理されるかはそれぞれで異なっています。 (歴史的には、 HTML4 までは文脈による違いを考えず、ただの値の意味を曖昧に規定するだけでしたが、 HTML5 以後詳細に規定されるようになりました。) 登録簿だけを無理に統合して個々のリンク型の各言語での用法を曖昧なままにするのではなく、 各言語がどのリンク型を利用し、その言語においては何を表し、どう処理されるべきなのか、 どのリンク型は利用できないのかを明確に規定することが望まれます。 (が、 残念ながら現時点でそれをしているのは HTML だけです...)

[172] link 要素sizes 属性as 属性の適合性は、 リンク型の影響を受けます。

[192] Atom で用いられるリンク型のいくつかは、独自の追加属性子要素を規定しています。

Atom 1.0 におけるリンク関係型

[74] Atomatom:linkrel 属性の値としてリンク関係型 (link relation type) を使っています。

[150] 関係 (relation (of)) とは、 atom:link 要素rel 属性値を指します >>149

構文

[75] 属性値RFC 3987isegment-nz-ncIRI のいずれかの生成規則一致しなければならないとされています RFC 4287 4.2.7.2.

[77] RELAX NG スキーマ (参考) では atomNCName または atomUri とされています RFC 4287 4.2.7.2.

[78] HTML4HTML5 と比較すると、任意の文字列ではなく IRI に制限されている点、複数の型は指定できず、1つだけである点が異なります。 Atom大文字・小文字区別ありの比較である点も異なります。

意味

[79] isegment-nz-nc による名前が与えられた場合、 IANA登録簿にあるのと同じ名前、従って http://www.iana.org/assignments/relation/ の後に当該文字列が連結された値と同じものが指定されたのと同じとみなされなけばなりません RFC 4287 4.2.7.2.

http://www.iana.org/assignments/relation/

[112] http://www.iana.org/assignments/relation/ は現在 404 エラーを返していますし、 Internet Archive によれば以前から存在していなかったようです。 リンク型を結合した URL についても同様です。

[113] HTTP Link: も以前の Internet DraftAtom と同じくこの URL を使っていましたが、 RFC 5988 は採用していません。

関連

[147] Web Linking のリンク型 (>>99) とは、 URI ではなく IRI をベースにしていることや、 >>79 の通り短い文字列も URL として表した長い文字列の簡略形である点、 短い文字列の大文字小文字を区別する (Web Linking は区別しない) 点が異なっており、 厳密には互換性がありません。

[148] IANA登録簿については Web Linking によって置き換えられています (>>118) が、 Atom のデータ型として、あるいは atom:link 要素の定義としては置き換えられているとは記載されておらず、 引き続き RFC 4287 の規定が有効であるようです。

[164] このような曖昧性があるので、差分仕様書はやめてほしいものです・・・。

Web Linking におけるリンク型

[99] Web Linking におけるリンク関係型 (link relation type) は、 リンク意味や、対象となる資源が有する属性や動作を表すものです。 >>98

[100] 例えば、リンク関係型 copyright は、対象IRIで識別される資源文脈IRI で表される資源に関する著作権を記述している、というリンクの意味を表しています。 >>98

[101] 例えば、リンク関係型 service は、対象IRIで識別される資源があるプロトコルの一部、 この場合はサービス記述文書であることを暗示しています。 >>98

仕様書

相互関係

[103] リンク関係型は、他のリンク関係型が存在する、あるいは存在しないことにより、 あるいは同じリンク関係型の個数により、意味が変わるべきではありません。 ただし、 alternatestylesheet の組み合わせは例外とします。 >>98

[104] HTMLリンク型はこれ以外にもいくつかこの手のリンク型が存在するので、 その意味で HTMLWeb Linking には互換性がありません。

登録関係型

[105] 登録関係型 (registered link type) とは、 IANA に登録されたリンク関係型を言います。

[106] 登録関係型の名前は reg-rel-type 生成規則に適合しなければなりません。 比較は大文字・小文字不区別で行わなければなりません登録関係型の名前は十分詳しくあるべきであり、 特定の応用のための関係が一般的な名前を使うべきではありません。 文脈IRIMIME型を含んだり、制約したりしてはなりません>>98

  reg-rel-type   = LOALPHA *( LOALPHA | DIGIT | "." | "-" )

[107] 特定の応用での処理のための情報、例えば Webブラウザーの処理方法についても登録簿に含めることができます。 >>98

拡張関係型

[108] 拡張関係型 (extension relation type) とは、 URI として表されるリンク関係型を言います。

[109] 登録したくない応用RFC 3986 URI拡張関係型として使うことができます。 URI が指す資源リンク関係型の意味の定義を含めることができますが、 クライアントがこれに自動アクセスするべきではありません。 比較の際は大文字・小文字不区別で文字列として行わなければなりません。 すべて小文字URI を使うべきです

[110] URI はすべてASCII文字なので、ASCII大文字・小文字不区別です。 文字列として、ということなので相対参照解決は行われません。ただし、 CURIE として記述されている URI を元の URI に復元する、という処理が言及されているので、 同様に任意のURI参照として記述されている URI解決して元の URI に復元する、という記述形式を定義することは可能だと思われます。

[146] リンク関係型URI であって IRI でないのは、比較の容易のためであるとされています。 また、 リンク関係型利用者に対して表示するものではないともされています。 >>98 8.

[156] HTML でもリンク型URL を使うことはできますが、 特別扱いはされておらず、 microformats wiki への登録が必要な点、 HTML では RFC 3986 URI でない URL も禁止されていない点が異なっています。

関連

[102] >>101 のような使われ方から、 MIME型と混同しそうですが、資源表現の書式を表すために使うものではなく、 あくまでも関係性を述べるものに過ぎない、とされています。 >>98

Activity Streams のリンク関係

[212] Activity StreamsLinkRFC 5988 を参照しつつ、 rel プロパティーにおける独自のリンク関係 (link relation) の用法を規定しています >>213

[214] 複数の値を JSON配列により表現できます >>213順序に意味があるのかは不明です。

[215] rel プロパティーを指定しない場合、リンク関係未指定 (unspecified) と解釈されます >>213

[221] Activity Streams は、HTML 5.0RFC 5988 とは違った「リンク関係 (link relation) 」 の定義が含まれるとし >>213HTMLの空白, を含まない任意の文字列HTML 5.0妥当なリンク関係 (valid link relation) である >>213, >>225、 と述べています。 その上で、 Activity Streams では RFC 5988HTML 5.0 の両方で構文的に >>213 妥当なリンク関係のみを用いなければならない >>213, >>225 とし、 未登録のリンク関係の値の利用を認めています >>213

[222] 厳密に言えば、 HTML 5.0 (やそのコピペ元の HTML Standard) はリンク型を定義していますが、リンク関係は定義していません。

[223] HTMLの空白以外の任意の文字列が認められるというのは雑な説明で、 実際にはより細かな制約がありますし、利用する値は登録する必要があります。 あたかも HTML 5.0 のために未登録の値が認められると誤認するような書き方になっていますが、 実際には HTML 5.0 とは関係のない、 Activity Streams 独自の規定です。

[226] HTML 5.0, を認めていないとするのは、事実に反します。

[224] RFC 5988リンク関係HTML 5.0リンク型はどちらも大文字・小文字不区別ですが、 Activity Streams には何の言及もなく、同じく不区別とするべきなのか、はっきりしません。

リンク型の一覧

[97] リンク型の一覧を参照。

Microformats Wiki の登録簿

[44] HTML Standardmicroformats wikiリンク型の一覧 >>38 を参照しています。 microformats wiki の当該ページには HTML 以外で使われるリンク型の一覧なども掲載されていますが、そのうちの一つの表が HTML 用の登録簿となっています。

[202] Wiki なので基本的には誰でも好きなように変更できますが、 実際には長期間安定して運用されているようです。 ある日突然おかしな内容に書き換えられていることもありません。

IANA リンク関係型登録簿

[116] IANAWeb Linking 仕様に基づく IETFリンク関係型の登録簿を管理しています。

仕様書

[128] 登録簿 (>>122) は他の IANA登録簿同様、 HTMLXML平文で提供されています。

登録手続き

[132] 登録はまず link-relations@ietf.org メーリング・リストに登録雛形を埋めて送信することで行われます。 >>124

[127] RFC 5226 指定専門家 (Designated Expert) の助言に基づき、 仕様書必須 (Specification Required) の形で登録されることとなっています。 >>124

[129] 登録雛形を埋めたものは通常 RFC または RFC 2026 開放型標準 (Open Standard) により出版されることになっていますが、 指定専門家は出版されることを前提に出版前に承認して構いません。 >>124

[130] 未登録のリンク関係型が広く使われており、直ちに登録される見込みもない場合、 指定専門家の判断により第三者が登録することもできます。 >>124

[133] 指定専門家は承認または拒否を14日以内に決定します。 決定に対する不服は Application Area Directorsへ、更には IESG 全体へと申し立てられます。 >>124

[131] 登録雛形には次の項目が含まれます >>124

メモ

[158] この登録簿の運用はほとんど滅茶苦茶で、何の役に立つのかとても怪しいです。

[161] 例えば alternate という値は Atom 登録簿時代 >>157 には RFC 4287 (Atom 1.0) を出典にしていて、当然ながら RFC 4287 には Atom における用法の規定が含まれていました。ところが現在 () は <http://www.w3.org/TR/html5/links.html#link-type-alternate> が出典になっていて、 リンク先には W3C HTML 5.0 における用法の規定しか含まれていません。 W3C HTML 5.0Web Linkingリンク関係型とは異なるリンク型としての alternate を規定しているだけで、 Atom での用法は一切言及していません。従って、公式には Web Linking においてリンク関係型 alternate は「登録されているが規定は存在しない」という意味不明な状態となります。

[162] previous という値は Atom 登録簿時代 >>157 には RFC 5005 (Atom ページング) を出典に Atom における用法の規定を参照していました。現在 () は <http://www.w3.org/TR/1999/REC-html401-19991224> を出典にしていますが、 やはり Web Linkingリンク関係型とは異なるリンク型としての言及で、 しかも「実装する利用者エージェントもある」との記載であって規定ですらありません。 IANA登録簿の説明文も HTML4prev の 「Synonym」としていますが、そちらは <http://www.w3.org/TR/html5/links.html#link-type-prev> を出典としていて、 Web Linking とは異なるリンク型の規定です。 こちらには previous も同義として実装しなければならないとの規定があり、 なぜ previous の出典がこちらでないのかは謎です。 リンク関係型リンク型の違いを無視したとしても、 previous は実装しなければならないが使ってはならず、 prev を使わなければならないとの HTML の規定が Atom にも適用されるかは明らかではありません。 (RFC 5005prev に言及すらしておらず、 RFC 5005 の実装は prev を知らない可能性があります。)

[203] derivedfrom という値は突然削除されました。 登録手続きはあっても削除手続きはないので、どのように削除されたのかは謎です。

derivedFrom 参照。

IANA リンク型応用データ登録簿

[137] RFC 5988リンク関係型に加えて、リンク型応用データに関する IANA 登録簿 (Link Relation Application Data Registry) も定義しています。

[145] ただし RFC には具体例が示されておらず、現時点で1つも登録が無いため、 どのような利用を想定しているのかはっきりしていません。

登録手続き

[140] 登録は RFC 5226 指定専門家 (Designated Expert) の助言により RFC 5226 仕様書必須 (Specification Requred) の方式により行います。 >>136

[144] 登録雛形は link-relations@ietf.org に送られるべきであり、 指定専門家は14日以内に承認または拒否の判断を下します。 21日を超えて決定が下されないときは IESG に上訴できます。 >>136

[141] 登録雛形には次の項目が含まれます >>136

[142] ここで説明には応用データの値空間を含めるべきです>>136

[143] 既定値は応用データが適用されないリンク関係型に対して適当でなければなりません。 応用データの登録以前に登録されたリンク関係型には既定値が適用されるものとみなします。 これが不適当であるときは指定専門家や (可能なら) 登録者と相談の上適切に修正するべきであります。 >>136

歴史

HTML 4 のリンク型

[35] HTML4 の仕様書で認められた (recognized) リンク型は <http://www.w3.org/TR/html4/types.html#type-links> に、 その慣習的な (conventional) 解釈と共に挙げられています。

わざわざ「慣習的」と言っているからには、 特に HTML 4 で規定するのではなく、そう解釈されてきたからこれからもそうするといいよと言っているように思われます。

[183] 連結役割 (role) は、 a 要素や link 要素の rel 属性や rev 属性で指定します。

Atom 0.3 におけるリンク型

[34] Atom 0.3 atom:link 要素rel 属性の値は、 Atom API 仕様案で規定された値のいずれかとされていました。

[36] Atom 1.0 で導入される複雑な仕組みはまだありませんでした。
[37] 値の一覧はリンク型の一覧を参照。

Atom リンク関係登録簿

[80] RFC 4287 (2005年) は Atomリンク関係型のための登録簿 (「Registry of Link Relations」) を定義していました。

[120] IANA 登録簿への登録は、 IANA において受け付けた後、転送されて RFC 2434 IESG承認 (IESG Approval) によるとされていました。 >>80

[119] 登録簿は、次の内容を含めることになっていました。 >>80

  • 属性値
  • 説明
  • 期待される表示上の性質
  • セキュリティに関して

[121] 初期状態として、 RFC 4287 で規定される5つの値 alternate, related, self, enclosure, via >>80 が登録されていました。

[165] 当初は登録時の雛形を埋めたものが登録簿とともに用意されていました >>163 が、登録簿の XML 化のタイミングで無くなったようです。 (仕様書無しで登録された場合は内容が XML 版に引き継がれているようです。)

[118] この登録簿は RFC 5988 により置き換えられています。

[123] 登録簿の URL>>122 でした。内容はそのまま新しい登録簿に引き継がれています。 Atom としての登録簿で Internet Archive に残っている最後のものは >>157 のようです。

[189] なお、 rel 属性は明らかに HTML の影響を受けたものでしたが、 Atom 1.0 出版時点で HTMLリンク型との関係は規定されていませんでしたし、 互換性もありませんでした。

XHTML2 と RDFa

XXX

HTML5 による整理

[46] HTML4要素意味を厳密に運用することを求める流れやマイクロフォーマットへの注目の中で、 Web Applications 1.0 (HTML5) は当初 HTML4HTMLメタ情報プロファイルを引き継ぎ、より厳密に規定していました。 しかしその後の見直しにより、実質的に運用できていないとして、 プロファイルの仕組みは廃止されました。

[188] 統計データ上ほとんど意味のある形で運用されていない状況でしたし、 本家本元といえる microformats コミュニティーでもプロファイルは形骸化し、 正しく用いられてはいませんでした。

[45] Web Applications 1.0 (HTML5) は、利用状況を勘案して、 rev 属性廃止しました。よってリンク型を使うのは rel 属性のみとなりました。

rev 属性の項を参照。

[48] HTMLメタ情報プロファイルにかわり導入されたのは WHATWG Wiki への登録の仕組みでした。 HTML5 に含まれないリンク型も誰でも一覧ページ >>47 に追加できることとされていました。

W3C HTML 5.0 による混乱

[49] HTML5 が新 W3C HTML WG に持ち込まれた後、 WHATWG Wiki を参照する形は好ましくないと声高に主張する人達がおり、 profile 属性の廃止への反対や IANA への移管など色々な思惑が交錯し議論になりました。 最終的には一覧ページを WHATWG Wiki から、 microformats wiki にあった rel 属性値の一覧ページ >>69 に移動することで決着しました。

[50] なぜそれで話がまとまったのか謎です。また <meta name> など他の登録簿は WHATWG Wiki に残されており、なぜそちらには反対しなかったのかも謎です。 技術的制約はありませんから、政治的な理由で反対していたとしか言えないわけですが、 (他の登録簿が WHATWG にあるので) 反 WHATWG 勢力が反対していたわけでも microformats 中心主義者勢力が反対していたわけでもないことになり (microformats コミュニティーと WHATWG は距離が近いので後者はそもそもあり得ない)、 (IANA登録簿が採用されていないので) IETF/IANA 中心主義者勢力の意見が通ったわけでもありません。 いったい何がしたくて反対していたのでしょうね。

[207] その他、 W3C での反対により、いくつかのリンク型は削除されることで政治決着しました。 そのうちのいくつかは、のちの WHATWGW3C の決別後に WHATWG 版で復活していますが、いくつかは削除されたままになっています。


[84] W3C HTML 5.0 は、なぜか、次のような独自の規定を設けています >>82

このような独自規定に従う実装があるのかどうかは、不明です。

[206] microformats wiki: が含まれる場合、 その値は絶対URLでなければならないと、 WHATWG HTML Standard は規定しています。 W3C HTML 5.0 はその規定を変更せずにコピペしています。

そのため、 HTML 5.0 の独自規定に従う場合、 非ASCII文字を含む URL を登録できるにも関わらず、 適合検査器に非妥当だと指摘されることになります。

またASCII大文字を含む URL を登録することもできますが (比較ASCII大文字・小文字不区別なだけであって、 登録する値の大文字小文字に関する要件はなく、 W3C HTML 5.0 でも変更されていない)、 Note (参考) に従う適合性検査器には警告されることになります。

[208] W3C HTML 5.0: を含む値について表を参照せず絶対URL かどうかだけを使うように適合性検査器の規定を変更していますが、 著者の要件は、変更されていません。 WHATWG 版と同じく、 仕様本体と microformats wiki で有効に定義されたものだけしか明確に利用を認めていません。 つまり、登録されていない絶対URLは、著者が使ってはならないものであるにも関わらず、 適合性検査器はこれを検出しないことになります。

[209] なぜこのような不可解な規定にしたのかは、謎です。 仕様書規定の構造を理解していない編集者が杜撰な変更を加えて破綻した、 というようなことは、慎重な審議が行われているはずの W3C勧告では起こらないはずなのですが・・・。

[160] ちなみに W3C HTML 5.0microformats wiki の一覧表を参照しつつも、 その参照を規定ではなく参考としています >>159。 一覧表を使わなければならないとの部分は規定なので >>82、 仕様書として破綻しています。 (コピペ元の WHATWG HTML Standard では規定になっているので、 W3C の独自の編集によるエンバグです。)

[211] HTML 5.1 では修正されています >>210

RFC 5988 リンク関係型登録簿

[125] RFC 5988RFC 4287 によるIANA登録簿に替えて、 Web Linking 仕様に基づくリンク関係型の登録簿「Link Relation Type Registry」を規定しています。

[126] RFC 5988 によれば XML 版は BSDライセンス文を含まなければならないことになっています >>124 が、 現時点ではそのようにはなっていません。

[134] RFC 5988 は元の RFC 4287 の登録簿に登録されていたリンク型を初期状態として改めて規定しています。 出典なしで登録されていたリンク型RFC 5988 が出典という扱いになっています。 >>124

[135] RFC 4287 では登録されたリンク型も長い URL としての形式に対応づけられることになっていましたが、 RFC 5988 にはそのような言及がまったくありません。 (>>113)

RFC 5988 リンク型応用データ登録簿

[138] リンク型応用データ登録簿は RFC 5988 により新設されました。

[139] 現時点で何も登録されていません。

参考

[40] Specifying schemas for document link relationships <http://www.protogenius.com/rel-schemas/draft-scheid-rel-schemas-00.htm> (名無しさん)

[41] Webweavers - weavin' - rel=&quot;nofollow&quot; <http://webweaver.g.hatena.ne.jp/kotastyle/20050117/p1> (名無しさん)

[42] Preventing comment spam <http://www.google.com/googleblog/2005/01/preventing-comment-spam.html> (名無しさん 2005-01-22 00:40:49 +00:00)

[43] DTV A S E L 1 (DASE-1) P 2: D A E ATSC Standard <http://www.atsc.org/standards/a_100_2.pdf> は、 rel 属性で HTML 4 リンク型以外には x- を接頭辞として付けることを要求しています。 5.1.1.6.6 link element

[55] XHTML link types in RDF <http://www.w3.org/2005/05/hrel/>

XHTML 2.0リンク型 as RDF語彙 (名無しさん)

[56] Bug 103469 - Need unified spec for rel="" <https://bugzilla.mozilla.org/show_bug.cgi?id=103469> (名無しさん)

[57] Index of /specs/html/link <http://www.hixie.ch/specs/html/link/>

Ian Hicksonの昔の提案。 (名無しさん [sage])

[58] Bug 2800 - No UI for HTML2 "LINK" element <https://bugzilla.mozilla.org/show_bug.cgi?id=2800> (名無しさん [sage])

[59]

複数の値についてのまとめが必要

[61] HyperText Design Issues: Link types (2000-02-25 02:43:14 +09:00 版) <http://www.w3.org/DesignIssues/LinkTypes.html> (名無しさん)

[62] Describing and Linking Web Resources (1996-11-13 23:39:22 +09:00 版) <http://www.w3.org/Architecture/NOTE-link.html> (名無しさん)

[63] Relationships in HTML links (1996-05-30 22:21:50 +09:00 版) <http://www.w3.org/MarkUp/Relationships.html> (名無しさん)

[64] The Continuous Media Markup Language (CMML), Version 2.1 (2006-05-06 10:39:46 +09:00 版) <http://annodex.net/TR/cmml.html#rfc.section.2.2> (名無しさん)

[65] RDF Sitemaps using HTML link types and Dublin Core (1999-04-16 16:23:49 +09:00 版) <http://www.ilrt.bris.ac.uk/discovery/rdf-dev/purls/papers/sitemap/> (名無しさん)

[66] RDF Sitemaps using HTML link types and Dublin Core (1999-04-16 16:23:49 +09:00 版) <http://www.ilrt.bris.ac.uk/discovery/rdf-dev/purls/papers/sitemap/> (名無しさん)

[67] Hatena::agenda (2007-07-07 14:25:21 +09:00 版) <http://d.hatena.ne.jp/jintrick/20070707> (名無しさん)

[68] Re: Where did the "rev" attribute go? (Ian Hickson <ian@...> 著, 2007-08-08 04:15:31 +09:00 版) <http://permalink.gmane.org/gmane.org.w3c.whatwg.discuss/11605>

[70] Hypertext links in HTML ( 版) <http://xml.coverpages.org/maloneyRelationships.html>

[71] HTML WG face-to-face meeting -- 23 Oct 2008 ( 版) <http://www.w3.org/2008/10/23-html-wg-minutes.html#grddl-talk>

[72] <http://www.annodex.net/TR/draft-pfeiffer-cmml-03.txt>

[73] RDFa in XHTML: Syntax and Processing ( 版) <http://www.w3.org/TR/2008/REC-rdfa-syntax-20081014/#relValues>

[83] <http://alexandre.alapetite.fr/divers/vrac/20091115_HTML_link_rel.html>

[86] Working Group Decision on ISSUE-118 broken-link-types ( ( 版)) <http://lists.w3.org/Archives/Public/public-html/2011Feb/att-0481/issue-118-decision.html>

[87] IRC logs: freenode / #whatwg / 20110201 ( ( 版)) <http://krijnhoetmer.nl/irc-logs/whatwg/20110201#l-80>

[88] IRC logs: freenode / #whatwg / 20110301 ( ( 版)) <http://krijnhoetmer.nl/irc-logs/whatwg/20110301#l-423>

[89] IRC logs: freenode / #whatwg / 20110310 ( ( 版)) <http://krijnhoetmer.nl/irc-logs/whatwg/20110310#l-480>

[90] Web Applications 1.0 r6000 8793 ( ( 版)) <http://html5.org/tools/web-apps-tracker?from=5999&to=6000>

[91] existing rel values · Microformats Wiki ( ( 版)) <http://microformats.org/wiki/existing-rel-values>

[92] IRC logs: freenode / #whatwg / 20110517 ( ( 版)) <http://krijnhoetmer.nl/irc-logs/whatwg/20110517>

[93] IRC logs: freenode / #whatwg / 20110606 ( ( 版)) <http://krijnhoetmer.nl/irc-logs/whatwg/20110606>

[94] IRC logs: freenode / #whatwg / 20110613 ( ( 版)) <http://krijnhoetmer.nl/irc-logs/whatwg/20110613>

[95] Web Applications 1.0 r6486 Remove pointless part of this requirement. ( ( 版)) <http://html5.org/tools/web-apps-tracker?from=6485&to=6486>

[96] OData Protocol Atom Format ( ( 版)) <http://www.odata.org/developers/protocols/atom-format>

[114] Web Application Description Language ( ( 版)) <http://www.w3.org/Submission/2009/SUBM-wadl-20090831/#x3-290002.12.4>

[115] IRC logs: freenode / #whatwg / 20120531 ( ( 版)) <http://krijnhoetmer.nl/irc-logs/whatwg/20120531#l-1793>

[152] IRC logs: freenode / #whatwg / 20121002 ( ( 版)) <http://krijnhoetmer.nl/irc-logs/whatwg/20121002#l-287>

[167] Specifying schemas for document link relationships ( ( 版)) <http://web.archive.org/web/20041110195640/http://protogenius.com/rel-schemas/draft-scheid-rel-schemas-00.htm>

[168] [whatwg] link-types ( ( 版)) <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2004-September/002235.html>

[166] OASIS Specification Template ( 版) <http://docs.oasis-open.org/cmis/CMIS/v1.0/cs01/cmis-spec-v1.0.html#_Toc243905521>

[169] Specifications/OpenSearch/1.1/Draft 5 - OpenSearch ( 版) <http://www.opensearch.org/Specifications/OpenSearch/1.1/Draft_5#Url_rel_values>

Rel attribute strings can contain a space-delimited list of one or more semantically meaningful rel value tokens. An empty rel attribute value should be treated by the client as if the rel attribute was not present at all.

[173] Web Applications 1.0 r5924 Drop support for rel=up, rel=last, rel=index, rel=first, and any related synonyms. ( 版) <https://html5.org/r/5924>

[174] Web Applications 1.0 r5925 Drop support for rel=archives and any related synonyms. ( 版) <https://html5.org/r/5925>

[175] Web Applications 1.0 r6000 apply wg decision ( 版) <https://html5.org/r/6000>

[176] Web Applications 1.0 r6486 Remove pointless part of this requirement. ( 版) <https://html5.org/r/6486>

[177] link relations for RDF · Issue #39 · mnot/I-D ( 版) <https://github.com/mnot/I-D/issues/39>

[178] use full URI in HTTP Header or add to IANA link relations registry · Issue #1 · aaronpk/Micropub ( 版) <https://github.com/aaronpk/Micropub/issues/1>

[186] rel registry · Microformats Wiki ( 版) <http://microformats.org/wiki/rel-registry>

[187] HyperText Design Issues: Link types ( 版) <http://www.w3.org/DesignIssues/LinkTypes.html>

[190] VMware ドキュメント センター ( 版) <http://pubs.vmware.com/vca/index.jsp#com.vmware.vcloud.api.doc_56/GUID-EECCA924-4DCE-490F-B352-5C212AD22411.html>

[191] >>190リンク型と似た独自のものを使っています。 語彙HTML のものとも IETF のものとも異なっていて、 どちらかといえばメソッド名のような性質のようです。

[195] Mason/Mason-draft-2.md at master · JornWildt/Mason ( 版) <https://github.com/JornWildt/Mason/blob/master/Documentation/Mason-draft-2.md>

The name of a control can either be a simple predefined token from the IANA relationship registry, a curie or a complete URI. The use of URIs (and curies) as a namespace mechanism makes it easy to declare names without colliding with similar names from other systems.

[197] Allow pingback/prefetch/stylesheet links in body · whatwg/html@179983e ( 版) <https://github.com/whatwg/html/commit/179983e9eb99efe417349a40ebb664bd11668ddd>

[198] Move statement on rel synonyms for more visibility · whatwg/html@f200173 ( 版) <https://github.com/whatwg/html/commit/f200173351fa541c829f6e3de98fbe8ba8ef608b>

[199] Add some clarity about body-ok rel keywords · whatwg/html@6820420 ( 版) <https://github.com/whatwg/html/commit/68204209474f6fa52e5fb1e3ce42115c13c2d458>

[200] Consider not restricting "possible supported tokens" for <link>/<a>/<area> · Issue #1184 · whatwg/html ( ()) <https://github.com/whatwg/html/issues/1184>

[201] Allow <link rel=apple-touch-icon sizes=… href=…> (sideshowbarker著, ) <https://github.com/whatwg/html/commit/4c84c5a531bbdd1982d76abef13f2b91f52a66b6>

[205] #whatwg
2017/04/01 09:53:10 (MikeSmit1)

Domenic: about rel=canonical, I added use counters to the HTML checker for a bunch more rel values https://validator.w3.org/nu/stats.html

rel=canonical is tied for 3rd place as most commonly used

rel=stylesheet found 118918 0.831269

rel=icon found 82216 0.574712

rel=canonical found 46503 0.325069

rel=alternate found 46417 0.324467

next closest is rel=nofollow

rel=nofollow found 34354 0.240144

after that, usage for the rest drops down to under 10% each

[234] rel=canonical — Anne’s Blog () <https://annevankesteren.nl/2009/02/rel-canonical>