4. Link Relation Types
In the simplest case, a link relation type identifies the semantics of a link. For example, a link with the relation type "copyright" indicates that the resource identified by the target IRI is a statement of the copyright terms applying to the current context IRI.
Link relation types can also be used to indicate that the target resource has particular attributes, or exhibits particular behaviours; for example, a "service" link implies that the identified resource is part of a defined protocol (in this case, a service description).
Relation types are not to be confused with media types [RFC4288]; they do not identify the format of the representation that results when the link is dereferenced. Rather, they only describe how the current context is related to another resource.
Relation types SHOULD NOT infer any additional semantics based upon the presence or absence of another link relation type, or its own cardinality of occurrence. An exception to this is the combination of the "alternate" and "stylesheet" registered relation types, which has special meaning in HTML4 for historical reasons.
There are two kinds of relation types: registered and extension.
4.1. Registered Relation Types
Well-defined relation types can be registered as tokens for convenience and/or to promote reuse by other applications. This specification establishes an IANA registry of such relation types; see Section 6.2.
Registered relation type names MUST conform to the reg-rel-type rule, and MUST be compared character-by-character in a case-insensitive fashion. They SHOULD be appropriate to the specificity of the relation type; i.e., if the semantics are highly specific to a particular application, the name should reflect that, so that more general names are available for less specific use.
Registered relation types MUST NOT constrain the media type of the context IRI, and MUST NOT constrain the available representation media types of the target IRI. However, they can specify the behaviours and properties of the target resource (e.g., allowable HTTP methods, request and response media types that must be supported). Additionally, specific applications of linking may require additional data to be included in the registry. For example, Web browsers might want to know what kinds of links should be downloaded when they archive a Web page; if this application-specific information is in the registry, new link relation types can control this behaviour without unnecessary coordination.
To accommodate this, per-entry application data can be added to the Link Relation Type registry, by registering it in the Link Relation Application Data registry (Section 6.3).
4.2. Extension Relation Types
Applications that don't wish to register a relation type can use an extension relation type, which is a URI [RFC3986] that uniquely identifies the relation type. Although the URI can point to a resource that contains a definition of the semantics of the relation type, clients SHOULD NOT automatically access that resource to avoid overburdening its server.
When extension relation types are compared, they MUST be compared as strings (after converting to URIs if serialised in a different format, such as a Curie [W3C.CR-curie-20090116]) in a case-insensitive fashion, character-by-character. Because of this, all-lowercase URIs SHOULD be used for extension relations.
Note that while extension relation types are required to be URIs, a serialisation of links can specify that they are expressed in another form, as long as they can be converted to URIs.