4. リンク関係タイプ

最も単純なケースでは、リンク関係タイプ (link relation type) はリンクのセマンティクスを識別します。例えば、関係タイプ "copyright" を持つリンクは、ターゲット IRI によって識別されるリソースが、現在のコンテキスト IRI に適用される著作権条項の表明であることを示します。

リンク関係タイプは、ターゲットリソースが特定の属性を持つこと、または特定の振る舞いを示すことを示すために使用することもできます。例えば、"service" リンクは、識別されたリソースが定義されたプロトコル（この場合はサービス記述）の一部であることを含意します。

関係タイプはメディアタイプ [RFC4288] と混同しないでください。関係タイプは、リンクが逆参照された結果として得られる表現の形式を識別するものではありません。むしろ、現在のコンテキストが別のリソースとどのように関係しているかを記述するだけです。

関係タイプは、別のリンク関係タイプの存在または不在、あるいは自身の出現回数に基づいて、追加のセマンティクスを推論すべきではありません (SHOULD NOT)。これの例外は、"alternate" と "stylesheet" という登録済み関係タイプ (registered relation type) の組み合わせであり、これは歴史的な理由により HTML4 において特別な意味を持ちます。

関係タイプには二種類あります。登録済みと拡張です。

4.1. 登録済みの関係タイプ

明確に定義された関係タイプは、利便性のため、および/または他のアプリケーションによる再利用を促進するために、トークンとして登録できます。本仕様は、そのような関係タイプの IANA レジストリを確立します。6.2 節を参照してください。

登録済み関係タイプの名前は、reg-rel-type 規則に適合しなければならず (MUST)、大文字小文字を区別しない方法で文字ごとに比較されなければなりません (MUST)。それらは関係タイプの特異性に適したものであるべきです (SHOULD)。すなわち、セマンティクスが特定のアプリケーションに高度に固有である場合、より一般的な名前をより特定度の低い用途のために利用できるようにするため、その名前はそれを反映すべきです。

登録済み関係タイプは、コンテキスト IRI のメディアタイプを制約してはならず (MUST NOT)、ターゲット IRI の利用可能な表現メディアタイプを制約してはなりません (MUST NOT)。ただし、それらはターゲットリソースの振る舞いと特性を指定することはできます（例えば、許容される HTTP メソッド、サポートされなければならないリクエストおよびレスポンスのメディアタイプなど）。さらに、リンクの特定のアプリケーションでは、レジストリに含めるべき追加データが必要になる場合があります。例えば、Web ブラウザーは、Web ページをアーカイブする際にどの種類のリンクをダウンロードすべきかを知りたいと考えるかもしれません。このアプリケーション固有の情報がレジストリにあれば、新しいリンク関係タイプが不必要な調整なしにこの振る舞いを制御できます。

これに対応するため、エントリごとのアプリケーションデータを、リンク関係アプリケーションデータレジストリ（6.3 節）に登録することにより、リンク関係タイプレジストリに追加できます。

4.2. 拡張関係タイプ

関係タイプを登録したくないアプリケーションは、拡張関係タイプ (extension relation type) を使用できます。これは、関係タイプを一意に識別する URI [RFC3986] です。その URI が関係タイプのセマンティクスの定義を含むリソースを指すことはできますが、クライアントは、そのサーバーに過剰な負荷をかけないよう、そのリソースに自動的にアクセスすべきではありません (SHOULD NOT)。

拡張関係タイプを比較する場合、それらは（Curie [W3C.CR-curie-20090116] のような異なる形式でシリアライズされている場合は URI に変換した上で）文字列として、大文字小文字を区別しない方法で文字ごとに比較されなければなりません (MUST)。このため、拡張関係にはすべて小文字の URI を使用すべきです (SHOULD)。

拡張関係タイプは URI であることが要求されますが、リンクのシリアライゼーションは、それらが URI に変換できる限り、別の形式で表現されることを規定できることに注意してください。