Edit

Page

Page title:

Page body:

[1] [DFN[[[Web Linking]]]] は、[[文書]]の形式や[[応用]]に依存しない[[型付きリンク]]の[[枠組]]です。
[[RFC 5988]] として [[IETF]] で標準化されています。

[48] 事実上、 [[HTTP]] の [CODE(HTTP)@en[[[Link:]]]] [[ヘッダー]]の[[データモデル]]を規定するものとなっています。
[[IETF]] としては[[リンク]]一般に適用される標準モデルとしたいようですが、
成功しているようには見えません。

[FIG(important)[
[61] 本項は[[固有名詞]]である [[Web Linking]] に関するものです。
[[Web]] における[[リンク]]一般については、[[リンク]]や[[ハイパーリンク]]を参照。
]FIG]

* 仕様書

[REFS[
- [2] '''[CITE@en[RFC 5988 - Web Linking]] ([TIME[2012-03-01 09:27:46 +09:00]] 版) <http://tools.ietf.org/html/rfc5988>'''
- [43] [CITE@en[RFC 6690 - Constrained RESTful Environments (CoRE) Link Format]] ([TIME[2014-09-27 02:33:02 +09:00]] 版) <http://tools.ietf.org/html/rfc6690>
- [49] [CITE@en[RFC 7641 - Observing Resources in the Constrained Application Protocol (CoAP)]] ([TIME[2015-10-01 09:47:49 +09:00]] 版) <https://tools.ietf.org/html/rfc7641#section-6>
]REFS]

* リンク

[7] [[Web Linking]] における[DFN[[RUBYB[リンク]@en[link]]]]は、
[[RFC 3987]] [[IRI]] によって識別される2つの[[資源]]の間の[RUBYB[型付きの連結]@en[typed connection]]です。
[[リンク]]は次の要素により構成されます。 [SRC[>>2 3.]]
[FIG(list members)[
:[[文脈IRI]]:
:[[リンク関係型]]:
:[[対象IRI]]:
:[[対象属性群]]:任意選択。
]FIG]

;; [8] これは、「(文脈 IRI) は (関係型) な[[資源]]を (対象 IRI) に持っており、
これは (対象属性群) である」という文と解釈できます [SRC[>>2 3.]]。

[9] [[リンク]]の[RUBYB[[[濃度]]]@en[cardinality]]には制限がなく、
ある [[IRI]] からの、あるいはある [[IRI]] への[[リンク]]が複数あっても構いませんし、
特定の2つの [[IRI]] の間に異なる[[リンク型]]の複数の[[リンク]]があっても構いません。
[SRC[>>2 3.]]

;; [10] 特定の2つの [[IRI]] の間に同じ[[リンク型]]の複数の[[リンク]]があっても良いかには言及されていません。

[11] 特定の[[直列化]]方式における、あるいは[[直列化]]方式をまたがった複数の[[リンク]]相互の順序やその意味は定義されていません。
[[応用]]によって順序に意味を持たせたければ、持たせることができます。
[SRC[>>2 3.]]

;; [22] [[Web Linking]] 本体の定義においては明記されていませんが、 [CODE(HTTP)@en[[[Link:]]]]
欄の説明によると、[[文脈IRI]]は「[RUBYB[匿名]@en[anonymous]]」となることがあるようです。
([CODE(HTTP)@en[[[anchor]]]] の項を参照してください。)

* 対象属性群

[12] [RUBYB[[[対象属性群]]]@en[target attributes]]は、[[リンク]]やその[[対象]]を説明する名前と値の組の集合です。
ただしその名前や用法については定義していません。
[SRC[>>2 3.]]

[EG[
[13] 例えば、[[対象IRI]]の[[MIME型]]のヒントを含めることができます。
]EG]

[23] これは [CODE(HTTP)@en[[[Link:]]]] 欄における [CODE(HTTP)@en[[[type]]]],
[CODE(HTTP)@en[[[hreflang]]]] などの[[引数]]が該当します。

[38] しかし各直列化法によりその表現方法は様々で、データモデルレベルでも一貫性がありません。
各直列化法は [[Web Linking]] のモデルに従った定義をしておらず、
それぞれの都合で必要な部分だけ独自に定義しているので、
[[Web Linking]] 全体で共通化した処理を行うのは困難でしょう。

;; [39] 構文だけ共通化した [[XLink]] と方向性は似ていますが、
どちらも等しく失敗しているように見えるのはおもしろいところです。

[37] [[Atom]] や [[WebFinger]] では、[[対象URL]]も [CODE(XML)@en[href]]
という名前で[[対象属性群]]と並列に表現されます。

[56] ([[Web Linking]] 以前からある) [[Atom]] の[[リンク型]]の中には、
[[XML名前空間]]を使って拡張した独自の[[属性]]や[[子要素]]を規定するものもあります。
[[Web Linking]] の立場からそれらがどう位置付けられるのかは不明です。

;; [CODE(XMLe)@en[[[atom:link]]]] 参照。

[40] [CODE(HTTP)@en[[[Link:]]]] では [CODE@en[title]] [[属性]]は
[CODE(HTTP)@en[[[title]]]] や [CODE(HTTP)@en[[[title*]]]] として表現されます。
後者では[[言語タグ]]も指定できますが、複数の[[言語]]は指定できません。
[[Atom]] では [CODE(XMLa)@en[[[title]]]] [[属性]]として表現されます。
[[言語タグ]]は[[要素]]自体と共通にしかできません。
[[WebFinger]] では [CODE@en[[[titles]]]] として任意の[[言語タグ]]と値の組を指定できます。

[41] [[Metalink/HTTP]] が追加した [CODE(HTTP)@en[[[geo]]]] [[属性]]を
[CODE(HTTP)@en[[[Link:]]]] 以外の、例えば [[Atom]] や [[WebFinger]]
で指定できるのかは明確ではありません。

[42] [[XRD]] では[[対象資源]]の [[URL]] の代わりに [[URI Template]]
を指定できます。

[44] [[CoRE]] は [CODE(HTTP)@en[[[href]]]] を予約しています [SRC[>>43]]。

[50] [[CoRE]] 関連仕様の [[RFC 7641]] は、 [[CoAP]] [[資源]]への
[[Web Linking]] [[リンク]]で[[対象属性]] [CODE[[[obs]]]]
を使うことができる [SRC[>>49]] と規定しています。
[[CoRE link format]] での利用が例示されているものの、
それに限らないことが暗示されています。しかしそれ以上の規定はありません。
本属性は値を持ってはならないこと、複数指定してはならないこと、
複数指定されていれば最初のもの以外無視しなければならないことなどの規定がありますが、
[[CoRE link format]] 以外の場合では適用できるのかすら謎です。

;; [51] 例えば、仮に [[Atom]] でこの[[対象属性]]を使えるとしても、
「値を持たない」ことは [[XML]] の仕様上不可能です。

[59] [[Collection.Doc+JSON]] は[[リンク]]が「primary link relations」と
「secondary link relations」を持てるとしています。前者は必ず1つ、
後者は任意個持てるようです。

;; [54] [[リンク型]]のマーク付け言語との関係の項も参照。

* 直列化

[14] [[Web Linking]] 本体仕様としては、具体的に[[リンク]]をどう表現するか
([RUBYB[[[直列化]]]@en[serialization]]) を定義していません。 [SRC[>>2 3.]]

[15] [[RFC 5988]] は次のような直列化を示しています。
[FIG(list middle)[
- [16] [[HTTP]] [CODE(HTTP)@en[[[Link:]]]] [[欄]]
- [17] [[HTML4]] [CODE(HTMLe)@en[[[link]]]] [[要素]]
- [18] [[Atom 1.0]] [CODE(XMLe)@en[[[atom:link]]]] [[要素]]
]FIG]

;; [29] [[HTML4]] (や [[HTML Standard]]) と [[Web Linking]] の定義は類似していますが、異なっており、
[[HTML]] として[[直列化]]したときにその解釈が [[Web Linking]] と同じになる保証はまったくありません。
特に[[リンク型]]の登録簿は共有されていないので、片方で有効な[[リンク型]]が他方では無効かもしれません。

;; [30] [[Atom 1.0]] についても同様のことが言えますが、 [[Web Linking]] は [[Atom 1.0]]
の [[RFC]] を更新する形で発行されており、 [[Web Linking]] により [[Atom 1.0]] の規定は一部上書きされていると思われます。

[24] 他に次のような[[直列化]]方式があります。
[FIG(list middle)[
- [25] [[CoRE Link Format]]
- [28] [[HAL]]
-- 明記されていないが [[Normative Reference]] であり、実質的に利用している
- [33] [[Collection+JSON]]
-- [[Collection.Doc+JSON]]
- [[WebFinger]]
- [CODE(MIME)@en[[[application/link-format]]]]
- [[XRD]]
- [[XML2RFC]]
- [[RDAP]] [[JSON]] ([[RFC 7483]])
- [[XML Hypermedia]]
- [[restbus]]
- [[HTTP Link Hints]]
- [[ALPS]]
- [[Mason]]
- [[Siren]]
- [[UBER]]
- [[ResourceSync]]
- [[JSON Hyper-Schema]]
]FIG]

[45] [[Web Linking]] および関連仕様は次の仕様を [[Web Linking]]
の[[応用]]であるかのように扱うことがありますが、
当該仕様側にはそのような規定がありません。
[FIG(short list)[
- [[HTML]]
- [[OpenSearch]]
- [[Maze+XML]]
]FIG]

;; [57] [[Web Linking]] の立場から [[HTML]] の [CODE(HTMLe)@en[[[a]]]]
[[要素]]や [CODE(HTMLe)@en[[[area]]]] [[要素]]がどう扱われているのかは謎です。
これらは [CODE(HTMLe)@en[[[link]]]] [[要素]]と似たところもあれば、
異なるところもあります。最も大きな違いは、
[CODE(HTMLe)@en[[[link]]]] [[要素]]は[[文書]]全体について記述するのに対し、
[CODE(HTMLe)@en[[[a]]]] [[要素]]や [CODE(HTMLe)@en[[[area]]]]
[[要素]]には「文脈」があることでしょうが、それを [[Web Linking]]
のモデルでどう扱う (あるいは扱わない) のかは定かではありません。

;; [58] 理論上は [[XLink]] も [[Web Linking]] の一直列化法だと主張できそうなものですが、
そのような主張はまだ確認できていません。

[64] [[Activity Streams]] の [CODE[Link][Link (Activity Streams)]]
は、「closely related to the conceptual model of Links as established in [RFC5988]」 
というものを [[RFC 5988]] を一部参照しつつ規定しています [SRC[>>63]]。
あるいは「fundamental model for links is established by [ RFC5988]」
と説明しています [SRC[>>65]]。 [[RFC 5988]] に基づきつつも独自の規定を積み上げているようではありますが、
具体的にどの規定がどこまで適用されるのか、よくわかりません。
[[リンク関係]]に関しては [[RFC 5988]] のみならず [[HTML 5.0]] も参照しています。

;; [[リンク型]]も参照。

[REFS[
- [63] [CITE@en[Activity Streams 2.0]] ([TIME[2017-05-21 23:50:36 +09:00]]) <https://w3c.github.io/activitystreams/core/#dfn-link>
- [65] [CITE@en[Activity Vocabulary]] ([TIME[2017-05-21 23:50:36 +09:00]]) <https://w3c.github.io/activitystreams/vocabulary/#dfn-link>
]REFS]

[47] [[GitHub]] の [[Web API]] は [[JSONP]] の [[JSON]] 部分に 
[[HTTP]] [CODE(HTTP)@en[[[Link:]]]] [[ヘッダー]]に相当する情報を含めています [SRC[>>46]]。

[REFS[
- [46] [CITE@en[GitHub API v3]] ([TIME[2015-02-19 00:56:09 +09:00]] 版) <https://developer.github.com/v3/#json-p-callbacks>
]REFS]

[60] [[BEACON]] は [[RFC 5988]] [[リンク関係]]を使っていますが、
それ以外に [[Web Linking]] に基づくとは言っていません。

[21] 定義上[[対象IRI]]や[[文脈IRI]]は [[IRI]] とされていますが、実際には[[プロトコル]]等の制限で
[[URI]] となることもあります。 [SRC[>>2 3.]]

* 処理モデル

[34] [[Web Linking]] は、[[リンク]]の[[データモデル]]を定義し、
いくつかの[[ハイパーテキスト]]形式への[[直列化]]の方法を説明していますが、
逆にそれを[[構文解析]]し、何らかの処理を加える方法は定義していません。

[35] ですから、ある[[ハイパーテキスト]]形式で記述された[[リンク]]を [[Web Linking]]
にのっとり処理する方法は、明確ではありません。特に [[HTML]] や [[Atom]]
は、 [[Web Linking]] ではなく、それぞれの仕様で定義された[[リンク]]の意味と処理が存在しますから、
これを [[Web Linking]] の仕様に従って処理しようと試みても、 [[HTML]] や [[Atom]]
の仕様上の定義とは矛盾してしまいます。

[36] 実際上は、 [[Web Linking]] に基づき定義されたそれぞれの[[リンク関係型]]において、
その処理が定義されていることがあります。 (それぞれの項を参照してください。)
ただし、すべての[[リンク関係型]]の処理がすべての形式・場面で定義されているわけではありません。
例えば[[リンク関係型]] [CODE(HTML)@en[[[stylesheet]]]] が [[HAL]]
で用いられていたとして、それがどう解釈されるのかはまったく不明です。

;; [55] [[リンク型]]の項も参照。

* 歴史

[3] [[Web]] 上の[[資源]]の関係や、その関係の[RUBYB[型]@en[type]]を表現する方法
[WEAK[(すなわち[[リンク]])]] は [[HTML]] や [[Atom]] で定義されていますが、
これらは概念的に類似しているものの、別個に規定されています。[[資源]]が複数の[[表現]]を持つ場合など、
具体的な表現方法の如何に関わらず、書式に依存しない[[型付きリンク]]の枠組を規定することは有用であると考えられたことから、
[[IETF]] は [[RFC 5988]] でこれを [[Web Linking]] として標準化しました。 [SRC[>>2 1.]]

[4] 既に [[Atom]] は [CODE(XMLe)@en[[[atom:link]]]] [[要素]]の [CODE(XMLa)@en[[[rel]]]]
[[属性]]のために[[リンク型]]の [[IANA]] 登録簿と語彙を規定していましたが、 [[RFC 5988]]
はこれを改訂して書式に依存しない[[リンク型]]の登録簿としました。更に、 [[HTML4]]
で規定されていた[[リンク型]]を登録簿に追加しています。

[5] [[RFC 5988]] の支持者は [[HTML]] の[[リンク型]]の定義を [[RFC 5988]]
に変更するべく [[HTML WG]] で工作活動を行いましたが、結局十分な支持を集められませんでした。

;; [6] とはいえ一連の議論で元々 [[WHATWG Wiki]] にあった [[HTML]] の登録簿は廃棄させられ、
[[microformats wiki]] に新しく登録簿が作られることになりました。

[26] [[RFC 5988]] に基づき[[リンク型]]を定義する [[RFC]] は、このような流れの中で勝手に [[HTML]]
の [CODE(HTMLa)@en[[[rel]]]] [[属性]]で当該[[リンク型]]を使った例を示していたりします。

;; [27] しかしながら [[Web Linking]] および関連 [[RFC]] は [[HTML]] で使うために十分な規定を含んでいません。
[[大文字]]と[[小文字]]の違いなど [[Web Linking]] と [[HTML]] の定義の違いについて明確な規定がありませんし、
[[ハイパーリンク]]と[[外部資源へのリンク]]の違いなど [[HTML]] での[[適合性]]や[[処理モデル]]との関係も不明確です。

* 実装

[52] 先述の通り、「[[Web Linking]]」全体の一般化された実装はほとんど不可能か、
意味をなしません。「[[Web Linking]]」の実装を名乗るものの多くは、実際は単なる
[[HTTP]] [CODE(HTTP)@en[[[Link:]]]] [[ヘッダー]]の実装のようです。

* 関連

[19] 抽象的な「[[リンク]]」の形式を規定し、それに則った具体的な[[リンク]]を各種文書形式に規定させる、
という発想は [[HyTime]] や初期の [[XLink]] 案、あるいは [[HLink]] と共通していますが、 [[Web Linking]]
はより抽象的かつ単純です。[[リンク]]そのものの標準化を試みた [[HyTime]] などと異なり、
[[Web Linking]] における[[リンク]]の定義はむしろ[[リンク型]]の登録簿の標準化の試みのために最低限の体裁を整えたに過ぎないと評価することもできるでしょう。

[20] [[Web Linking]] はその一般的な名前に反して [[Web]] における[[リンク]]のごく一部の限られた種類しかカバーしていません。
例えば [[HTML]] の [CODE(HTMLe)@en[[[a]]]] [[要素]]のように [[IRI]] 
で表現できるとは限らない[[アンカー]]を扱う[[リンク]]は表現できません。

* メモ

[62] [[Web Linking]] における[[リンク]]の捉え方は [[Semantic Web]] とも親和性は高そうですが、
[[RDF]] との関係も定義されていませんし、
意外と関心が重なっていないのか相互に言及も無さそうです。

[31] [CITE@en-US[Five JSON REST API Link Formats Compared | Sam Placette]]
( ([TIME[2014-07-01 13:09:40 +09:00]] 版))
<http://samplacette.com/five-json-rest-api-link-formats-compared/>

[32] [CITE[mnot’s blog: Linking in JSON]]
( ([TIME[2014-05-08 02:20:00 +09:00]] 版))
<https://www.mnot.net/blog/2011/11/25/linking_in_json>

[53] [CITE@en[Web Linking]]
([TIME[2015-11-16 15:10:32 +09:00]] 版)
<https://mnot.github.io/I-D/rfc5988bis/>

Historical Legal Sensitive Parent: [Help / License]

Edit

Page

Errors

Page name(s)