HTML 4.01 (and most earlier versions of the language) allow authors to identify the relationships between web resources (things with URIs) through use of the rel and rev attributes. These attributes, which may be included in the A or LINK elements, use human-readable keywords to explain the relationships.
Adding link relationships to your hyperlinks is a backward- (and forward-) compatible way of adding functionality to your web pages, while still following the HTML specifications. Link relationships are already used by a few browsers (including iCab and Mozilla). Future browsers (and other user agents like search engine robots) will probably make link relationships even more useful.
Link relationship information is usually added to a hyperlink (in the A or LINK elements) by adding a rel attribute to the linking element. For example, this link tells both the user and the browser that the document "toc.html" is a table of contents for the current document, and that "faq.html" is an appendix for the currently viewed document:
<a href="/toc.html" rel="Contents">Table of Contents</a>
<a href="/faq.html" rel="Appendix">Appendix</a>
Link relationships are actually more commonly used with the link element, as more browsers (and web robots) make use them in the LINK than in A.
Link relationships were metadata before metadata was popular. Relationships don't provide information about the subject of a page, rather they provide information about the page itself, by describing that page's direct relationships to other "web resources".
A "web resource" (in this context) is anything that can be assigned a URI, including other web pages, graphics, e-mail addresses, books, and even human beings. (Linking to human beings is tricky, though, for reasons explained below.)
In the terminology of metadata specialists, the page containing a link is the "subject", the resource being linked to is the "object", and the relationship itself is the "predicate". An easy way to understand the subject-predicate-object relationshiop described by a rel attribute is to rearrange the components of a hyperlink into the sentence "this page has a REL called HREF". For example, the link relationships listed in the head of this page tell you:
The syntax is stilted, but you get the point. (You also see, in the case of the author relationship, the target URI (object) isn't literally me, it's an e-mail address standing in for me. This is technically wrong, but widely tolerated, because there currently is no useful scheme for assigning URIs directly to human beings.)
HTML also allows you to specify reversed relationships using the rev attribute. Using the rev attribute is semantically equivilent to saying "this page is REV for HREF". For example:
<link href="/novel.html" rev="Appendix">
Tells web browsers that the current page is an appendix for the page "novel.html".
You could easily drive yourself mad with the rev relationships, since certain relationships (like Start and Index) would require you to include them in every outgoing link from key pages like your homepage or search page, and list every page in your site in the LINK elements. Nobody actually does this, so you should concentrate on adding rel attributes for now.
Although they've been underimplemented for most of their existence, link relationships endured several attempts to create "standard sets" that could be used by page authors. At the same time, the HTML specifications themselves were underwent four major revisions which altered the parameters of acceptable relationship values. After ten years of development, a few key design issues have cropped up. You should consider these issues when choosing what relationships to use in your web pages.
Questionable syntax. Technically, the HTML 4.01 specifications use a space character to separate multiple link relationships of the same hyperlink. (For example, rel="Top Index" would be a legal value if your top page is also your index page. There are at least two link relationships (Alternate Stylesheet and Shortcut Icon) that bend/break this rule.
Reserved words. As Maloney and Quinn have pointed out, several attempts at defining useful relationships use labels that coincide with the common buttons (functions) of popular web browsing software. Maloney and Quinn argue that any such "button names" should be "reserved" for use by the browser, and not used for link relationships. This argument is especially persuasive when you remember that some browsers render the LINK element by adding buttons to the browser toolbars; presenting user with two "Home" or "Forward" buttons creates a potential for confusing users.
Verb problem. Most of the popular link relationships use simple nouns as their labels, because nouns are the easiest relationships for end-users to understand. Over the years, however, a few verbs sneaked into the recommendations, but there's some confusion on how to use them.
Most of the confusion can be traced back to the made relationship, which was one of the first verb relationships widely promoted by browsers. Unlike most relationships, made is most common in its reversed form, using rev="made" to target an e-mail as the address of a page author.
There's actually been some debate as to whether this is the proper way to state the relationship, but rev="made" is too entrenched to change it now. That's where the problem begins: So many people got used to verbs being used as reversed relationships, they get confused by them not being reversed, and get caught up in picayune discussions of which is better (regular or reversed). It may be better to skip the verb relationships completely.
Indirect Relationships. As explained earlier, hyperlink relationships are meant to describe the relationship between the current document (web page) and another "web resource" (which is usually another web page). Some implementors, however, have attempted to use hyperlink relationships to describe the relationships not between pages, but between people and organizations represented by those pages. For example, the includes relationship attempts to say that the group who owns the current page includes the person who owns the target page.
This is what metadata experts call "a dereferencing problem". Normally, a URI refers to exactly one resource at a time. Indirect relationships are effectively using a URI to refer to two things at once: the URI's true representation (a computer file on the web) and the representation's owner. Instead of saying "this page has a REL called HREF", the relationship is saying "the entity associated with this page has REL who is the entity associated with HREF". What's supposed to be a "two resources relationship" is now a "four resources" relationship (two web files and two people).
I know that sounds like a pedantic distinction, but it's not: Using indirect relationships creates two contradictory meanings for the rel attribute (and by extension, the A and LINK elements), and contradictory relationships are a very bad thing in a computer-readable markup language. If your web browser can't be sure what the LINK element means, your web browser is severly limited in what it can do with the element, especially when encountering relationship values that haven't been hard-coded into the software.
If a link relationship uses a web page to stand in for a person as the subject of the relationship, it's bad for the web. (While the 1991 HTML Draft included several indirect relationships, all versions of HTML since them have excluded such relationships, presumably for this very issue.) This isn't to say that a link relationship can never have a human being as its target (object), because human beings can have their own URIs. (Currently, however, none do, so "mailto" URIs are used as cheap substitutes, which has to tolerated until somebody starts assigning URIs directly to people.) Therefore, relationships like author and editor aren't necessarily indirect relationships.
The namespace collision problem. The creation of link relationships has never really been coordinated, so there are a few relationship labels that have more than one meaning.
This is the list all the link relationships I encountered in assorted specifications, Internet Drafts, and browser manuals. The explanation of each label is prefaced with a phrase telling you where Websnob stands on the use of the realationship label.
Recommended relationships are the ones I think you should use, either because they're from the HTML 4.01 specifications, they're widely supported in current browsers, or they fill logical holes in currently popular relationship sets.
The Not Recommended relationships mostly leftovers from old recommendations, utilized only by no-longer developed browsers, or suffer from one of the "problems" listed above. (In the last case, I'll note which problem.) Using these relationships shouldn't cause any serious trouble (most browsers will ignore them, or file them away in submenu), but most such tags are better ignored in favor of a recommended equivilent.
Not Recommended. Indirect Relationship Indicates that the person represented by the current page has "exchanged greetings" with the person represented by the target page. Yes, that's right, a relationship for everyone you've ever said 'hello' to.
References: XHTML Friends Network 1.0
Recommended. According the HTML 4.01 Specification, this relationship indicates the target is a "substitute version" of the current document, meaning it serves the same purpose but differs in content-type, language, or intended media. Unlike most of the relationships discussed here, Alternate almost always requires you add a third attribute (in addition to rel and href) to your anchor tag.
If you're specifying a substitute version that uses another language, you need the hreflang attribute, which uses RFC 1766 language codes to identify the language of the target. For example, if there was Spanish version of this page, I might link to it like this:
<link rel="Alternate" hreflang="es"
href="relaciones.html">
On the other hand, if I was providing a WAP version of this page for use on handheld devices, I'd probably use the type and media attributes:
<link rel="Alternate" type="text/x-wml" media="handheld"
href="relationships.wml">
Another use of Alternate becoming popular with webloggers is pointing news aggregators to RSS counterparts of their HTML pages. As proposed by bloggers Matt Griffith and Mark Pilgrim, the link uses the media and title attributes, like this:
<link rel="Alternate" type="text/xml" title="XML" href="rss.xml">
or
<link rel="Alternate" type="application/rss+xml" title="RSS" href="rss.xml">
They jumped the gun using XML as the title (XML is used for reasons other than syndication), but there's no stopping the memesluts once they get started. Expect to this use of LINK on a lot of weblogs in the future.
References: HTML 4.01, XHTML 1.0, XHTML 2.0
Recommended. Although is does't appear in HTML 4.01's list of link types, Alternate Stylesheet is explained in the Specification's Section 14.3.2: Specifying external style sheets. Alternate Stylesheet is used (with the LINK element) to inform the document user that s/he has a choice of stylesheets when viewing the current document.
When using Alternate Stylesheet, you must use the title attribute to label it, so that the user's software can label the choices and offer the user has a hint of what's different about the various stylesheets. For example:
<link rel="Alternate Stylesheet" title="Monochrome"
href="monochrome.css">
provides the user with the hint that this stylesheet is best suited for monochrome displays.
When presenting alternate stylesheets, you should continue to identify your preferred (default) stylesheet by continuing to use rel="Stylesheet" when linking to that sheet.
References: HTML 4.01
Not Recommended. The Annotation element was proposed by Tim Berners-Lee for identifying documents that provide commentary, criticism, or corrections to the currently viewed document but aren't necessarily on equal footing with current document. For targets of equal stature, use the Reply relationship.
Given that most web authors incorporate new content directly into old documents, most Annotations are created by someone other than the original author. I have, for example, used Annotation to point to archived e-mail messages commenting on my web pages. It could likewise be used to reference newsgroup posts, weblog entries, or other small messages that comment on a page.
The Annotation relationship isn't really useful as of 2002, but might become relevant again if serious web annotation systems ever become popular.
References: TimBL, HTML, HTML+
Recommended. Intended to mark documents that serve as an appendix to a collection of documents. You're probably not going to use this one unless your site is adopting a "book-like" structure, which is becoming increasingly rare on the Web.
If your document has multiple appendices, you can differentiate them using the title attribute.
References: HTML 4.01, Mozilla, XHTML 2.0
Not Recommended: Verb Problem and Indirect Relationship. This relationship indicates that the person(s) represented by the current document approve of the content of the target document. Intended as a simple form of web annotation, this relationship suffers from the verb problem.
References: HTML
Recommended. The Author relationship (and its relatives like editor and made) represent an interesting problem. Technically, Author is not an indirect relationship because it relates the current document to the human being who created it. That's an explict "two resources relationship", as intended by the HTML specifications.
The problem (which you probably figured out already) is that human beings currently don't have their own URIs, so everyone using Author uses it to link to the author's e-mail address. Using the e-mail URI that way does create a derefencing problem, in that the URI now refers to two resources: the author and the author's e-mail address. Fortunately, it's a smaller problem than most indirect relationships, because e-mail addresses represent "dead ends" for HTML user agents -- the e-mail address has no metadata of its own, and most web browsers are programmed to "understand" that mailto URIs aren't normal resources.
The sad truth is that the confusion between a person and a person's e- mail address goes back at least as far as the creation of the "mailto" URI scheme (which was created by the authors of the Lynx web browser, mostly for use in LINK elements). Arguably the confusion goes back to the creation of the UNIX finger(1) and msg(1) commands, which used e-mail addresses to identify people for non-mail functions. This is probably a confusion we all have to tolerate until "URIs for humans" become common (Verisign is working on it, believe it or not.), or webmasters give up on the Author relationship completely due to fear of spam.
Also worth noting: There is no consensus on how to list multiple authors of a document using LINK elements. Using a separate LINK for each author is probably more logical, but some browsers only display the first such LINK.
References: Maloney/Quinn, Mozilla, iCab
Not Recommended: Reserved Word. This relationship was suggested a synonym for Prev, but Maloney and Quinn point out that a "Back" LINK button might be confused with the browser's "Back" button. Use Prev or Previous instead.
References: Maloney/Quinn, Mozilla
Not Recommended. The HTML 3.0 Draft suggested this a method for linking to an HTML document banner, but no browser ever supported it. Banners are best handled with a combination of HTML and style sheets.
References: HTML 3.0, Maloney/Quinn
Not Recommended. This relationship indicates that the current document is part of a linear series of documents, and that the target is the beginning of the series. Use First instead.
References: Maloney/Quinn, iCab
This relationship indicates that the target is a bibliographic entry. Whereas most anchor relationships describe the relationship between pages, this label describes the relationship between two pieces of pages. As such, this relationship is never used with the LINK element. On the other hand, the W3C uses it a lot for the A element.
If you want to link to the entire bibliography, use Appendix or Bibliography.
References: Maloney/Quinn
Recommended? The target document is a bibliography for the current document or collection. I'm conflicted about this relationship: I think bibliography is a useful label, but it has very little browser support. Until that changes, I recommend using Appendix with a title attribute to identify bibliographies:
<link rel="Appendix" title="Bibliography"
href="biblio.html">
References: Maloney/Quinn
This relationship indicates the target is a blogroll for the current document. (A blogroll, according to the bloggers responsible for the term, is a list of related links found on the homepage of most weblogs.) This relationship value was coined by Dave Winer in June 2002.
Reference: Radio UserLand : Links for Blogroll, RSS and Subscriptions
Not Recommended: Reserved Word. The HTML 4.01 Specification says the Bookmark relationship indicates a document that's "a key entry point within an extended document". This is the only value from HTML 4.01 that I don't recommend, and I have two reasons. First, nobody quite knows what "a key entry point within an extended document" is supposed to mean. (To my mind, it sounds a lot like the Chapter, Section, and Subsection relationships.) Secondly, many web browsers already use the term "Bookmark" for browser-specific functions, and encouraging browser to identify a web document with that term may confuse users.
References: HTML+, HTML 3.0, Maloney/Quinn, HTML 4.01, Mozilla, XHTML 2.0
Recommended. The Chapter relationship is used in "book-like" sites to indicate which documents are chapters (or possibly, the beginning of chapters, if the chapter has sections worth breaking into separate web documents).
References: HTML 3.2, HTML 4.01, Mozilla, XHTML 2.0
Not Recommended: Namespace Collision. The child relationship originally appeared in the Maloney/Quinn draft, designed to indicate that the current document and the targetted document have a hierarchical relationship, and that the target is the immediate child of the current document. Not used much, because genealogical hypertext metaphors confuse confuse some users. (The non-object-oriented ones.)
Child reappared in the XFN 1.0 specification as realtionship between people instead of hypertext objects -- it indicates that the person represented by the target URI is the biological and/or legal child of the person represented by the current URI.
This brings up an important point about "family relationships" in XFN: The XFN developers could have avoided the confusion by using son and daughter, but they chose to use non-gendered English kinship terms for all of their "family" labels. This may be a serious design flaw, because it limits the labels utility for defining cumulative relationships
For example, if I link to one page with rel="sibling" and that page links to third page using rel="child", the average Westerner would conclude that I'm the third person's "uncle". There are two problems here: The links don't clarify if I have a niece or a nephew, and they don't really say I'm "family" to that person, because you don't know if the sibling is male or female. There are many cultures that only trace descent through one side of the family -- in patrilineal cultures (which only trace descent through males), for instance, the children of my sister aren't necessarily "family" in the American sense of the word. It gets worse from there, but trust me on this: using non-gendered kinship terms prevents their use in the creation of accurate relationship maps.
References: Maloney/Quinn, XHTML Friends Network 1.0
Not Recommended. This relationship indicates that the target is a bibliographic citation. Whereas most anchor relationships describe the relationship between pages, this label describes the relationship between two pieces of pages. As such, this relationship is never used with the LINK element.
I don't like this relationship, because I think Maloney and Quinn gave a confusing explanation of it, and it's too much like Biblioentry.
References: Maloney/Quinn
Not Recommended: Indirect Relationship. An XFN relationship indicating that two people represented (by the current page and target page) are active in the same professional field.
References: XHTML Friends Network 1.0
Recommended. This relationship points to a document that serves as a table of contents for the current document (or more likely, the collection of documents that the current document is part of. For "book-like" sites (including print books transcribed to the Web), this relationship obviously refers to a traditional table of contents. For less book-like sites, Contents is probably best suited to identifying a site map.
References: HTML+, Maloney/Quinn, HTML 3.2, HTML 4.01, XHTML 1.0, iCab, Mozilla, XHTML 2.0
Recommended. A sign that lawyers have too much effect on standards, this relationship is used to identify a copyright statement for the current document.
References: HTML 3.0, Maloney/Quinn, HTML 3.2, HTML 4.01, iCab, Mozilla, XHTML 2.0
Not Recommended: Indirect Relationship. This XFN relationship indicates the person represented by the target URI lives "at the same street address" as the person represented by the current page.
References: XHTML Friends Network 1.0
Not Recommended: Indirect Relationship. States that the person represented by the target URI and the person represented by the current page work together. The XFN specification defines "work together" very loosely, in that the relationship could connect any two people who have the same employer. I will send five dollars to the first person who can prove they're a Microsoft employee, and that they've linked to Bill Gates as a co- worker.
References: XHTML Friends Network 1.0
Not Recommended: Indirect Relationship. An XFN label indicating that the person represented by the current URI has a crush on the person represented by the target URI. Sure to be a hit with celebrity stalkers.
References: XHTML Friends Network 1.0
Not Recommended: Indirect Relationship. Another goofy XFN label, date indicates that the people represented by the current and target URIs are dating on a regular basis, but not exclusively. (The XFN developers thought "mother" was too specific for a relationship label, but this made perfect sense to them. I don't get those guys at all.)
References: XHTML Friends Network 1.0
Although most commonly used as meta elements, some elements of the Dublin Core metadata scheme can be expressed as link elements, if and only if their referenced targets are URIs. Dublin Core link elements always begin with a "DC." or "DCTERMS." prefix. A strict reading of the DCMI recommendations suggests the "identifer", "relation", and "source" DC elements (as well as qualified DCTERMS elements derived from those elements) are best-suited for link elements, but elements not listed above might also appear as link elements.
Reference: Expressing Dublin Core in HTML/XHTML meta and link elements
Not Recommended. This relationship indicates that the target is a definition. Whereas most anchor relationships describe the relationship between pages, this label describes the relationship between two pieces of pages (the first piece is the word(s) being defined and the second pieces is the definition).
This relationship is seldom appropriate for use with the LINK element, although rev="definition" would work if you're one of those freaks who puts every definition on a separate page so you can display them in pop-up windows.
References: Maloney/Quinn
Not Recommended: Verb Problem. This relationship indicates "the target document was derived from the current document". A bit confusing, due to the verb problem. The Dublin Core values DC.source and DCTERMS.isVersionOf are acceptable (and better-defined) substitutes for this relationship.
References: Maloney/Quinn
Not Recommended. Indicates that the target document is a legal disclaimer for the current document or collection.
References: Maloney/Quinn
Recommended? Indicates that the target object represents the editor of the current document. As with Author, usually uses a "mailto" URI for the target. This element isn't in widespread use, but should be self-explanatory to most users. If a document has multiple editors, use multiple LINK elements differentiated with title attributes.
References: Maloney/Quinn
Used by sites implementing the Blogger API to point to an application/rsd+xml file used for creating and editing blog posts.
References: ?
Not Recommended. This relationship was proposed as a way to embed the targetted document in the current document. (It wasn't meant to be used with the LINK attribute.) Never implemented by any browsers, and likely to confuse users if it ever appeared on a menu. Embedding should be done with the HTML 4.0 object, img, and applet elements.
Not Recommended. This relationship indicates that the current document is part of a linear series of documents, and that the target is the last document of the series. Use Last instead (it's more widely supported).
References: Maloney/Quinn, XHTML 1.0, iCab
Not Recommended: Reserved Word. The iCab web browser uses Find as a synonym for Search. (Since iCab is only available for Macintosh, you're probably only going to see this relationship used on site by or for Mac users (like Apple.) I consider Find a poor choice of label because most web browsers already have a "Find" function. Use Index instead.
References: iCab
Recommended. This relationship indicates that the current document is part of a linear series of documents, and that the target is the beginning of the series. This relationship isn't in the HTML 4 relationship list, but it's supported by several browsers.
References: Maloney/Quinn, iCab, Mozilla
The fontdef relationship indicates that the target is a Portable Font Resource (PFR). PFR files are used by Netscape Navigator 4.x for displaying dynamic fonts, but aren't supported by any other browser (including later versions of Netscape Navigator).
References: http://www.truedoc.com/webpages/getstart/get_start3b.htm
Not Recommended. This relationship indicates that the target is a footnote. Whereas most anchor relationships describe the relationship between pages, this label describes the relationship between two pieces of pages.
This relationship is seldom appropriate for use with the LINK element, although link rev="footnote" would work if you're one of those freaks who puts every footnote on a separate page so you can display them in pop-up windows. I hate people like you.
References: Maloney/Quinn
Not Recommended: Reserved Word. Used by some as a synonym for Next, but can be confused with the browser's "Forward" button. Use Next instead.
References: Maloney/Quinn
Not Recommended: Indirect Relationship. Indicates that the person represented by the current page is a friend to the person represented by the target page. That may be incorrect syntax, depending on how you interpret "friend". If you think it means "someone who is friendly towards me", then the relationship is backwards -- it should be rev="friend". If you think "friend" means "someone I'm friendly towards", than the syntax is correct as written in the specification.
In either event, the relationship isn't necessarily reciprocal: You can be friendly towards someone who isn't friendly towards you. Although I don't know why you would bother putting that in a web page.
References: XHTML Friends Network 1.0
Recommended. Identifies the target as a glossary of terms for the current document. (If you ask me, more sites really should have glossaries. They're an important tool for sharing information.)
References: HTML 3.0, Maloney/Quinn, HTML 3.2, HTML 4.01, Mozilla, XHTML 2.0
Recommended. This relationship identifies the target as a "document offering help" for the current document. The defintion of "help" is pretty open-ended: Any document intended to assist users with site issues counts, so you could use Help to flag a FAQL, a search page, a feedback form, or any other form of help you can think of of.
(Technically, "Help" might be a reserved word (most browsers have their own help menu), but there's a shortage of good synonyms for this function. We have to live with the potential confusion.)
References: HTML+, HTML 3.0, HTML 3.2, HTML 4.01, XHTML 1.0, iCab, Mozilla, XHTML 2.0
Not Recommended: Reserved Word The History relationship indicates that the target document is a list of historical versions of the current document. Could be confused (by users) with the browser's normal "History" command.
The history relationship is a bit pie-in-the-sky anyway, since I don't know anyone who keeps all the old versions of their web pages online. I suppose it could be used to link to the Internet Archive, but that might be overkill.
References: HTML
Not Recommended: Reserved Word Several sources recommend this for identifying the "home page" of a site or document collection, but Maloney/Quinn rightly points out that most browsers already have a "Home" button, and providing users with a second button labeled "Home" would be confusing. Use Start or instead.
References: HTML 3.0, Maloney/Quinn, iCab
Not Recommended: Reserved Word According to Maloney and Quinn, the Hotlist relationship appeared in an early draft of the HTML 3.0 specification, but lacked an explanation of the relationship. Hotlist doesn't appear in the later version of HTML 3.0 that I have, so I have no idea if it was ever publically explained.
References: Maloney/Quinn
Recommended. This relationship always points to a graphical file, and indicates that the target is an icon that the browser may use for identifying the current document. The icon relationship was devised by Mozilla developers who weren't completely happy with how Microsoft used Shortcut Icon.
Given that neither icon nor shortcut icon are links to text files, they should include a type attribute indicating the Internet Media Type of the linked icons. The media type is usually "image/vnd.microsoft.icon".
References: http://bugzilla.mozilla.org/show_bug.cgi?id=32087
Recommended. The Index relationship indicates the target document is an index for the current document (and/or the current collection of documents). This is not the same thing as an index.html page. Rather, this Index refers to a URL that helps find information within the current document/collection, so it could be anything from a site map to a local search engine.
(The Web's creator, Tim Berners-Lee, made the connection between "index" and "search" explicit as far back as his 1990 design note, What is an Index, anyway?.)
HTML Snob recommends using Index to identify the search facility for the current collection of documents. Site maps are better identified using the Contents relationship.
References: HTML 3.0, Maloney/Quinn, HTML 3.2, HTML 4.01, XHTML 1.0, iCab, Mozilla, XHTML 2.0
Not Recommended. This relationship was proposed as a way to include (embed) the targetted document in the current document. (It wasn't meant to be used with the LINK attribute.) Never implemented by any browsers, and likely to confuse users if it ever appeared on a menu. Inclusions should be done with the HTML 4.0 object, img, and applet elements.
References: Maloney/Quinn
Not Recommended: Verb Problem and Indirect Relationship. This one's a doozy: The Includes relationship indicates that the group represented by the current document includes the object represented by the target document. For example, the home page of the state of Arizona could use this LINK to make sure everyone knows that Phoenix is part of Arizona:
<link rel="Includes" href="http://www.ci.phoenix.az.us/" title="Phoenix">
References: HTML
Not Recommended: Verb Problem. This relationship indicates that the person(s) represented by the current document are interested in the content of the target document. Besides suffering from the verb problem, this relationship was intended for use in server-based notification systems that nobody ever developed.
References: HTML
Recommended. This relationship indicates that the current document is part of a linear series of documents, and that the target is the last document of the series. This relationship isn't in the HTML 4 relationship list, but it's supported by several browsers.
References: Maloney/Quinn, iCab, Mozilla
Creative Commons uses this relationship to link to human-readable content usage licenses. CC also uses meta for linking to machine-readable RDF/XML license descriptions.
References: Creative Commons
Recommended. This relationship is used as a reversed relationship (i.e., rev="made"), pointing to a "mailto" URI, to indicate the author of a web document. Made suffers from the general confusion surrounding verbs as link relationships, but it's worth including because the Lynx web browser implements the reversed relationship for its "Send a Comment" function.
To support the Lynx "Send a comment" function, use rev="made" with a mailto URL for the href attribute, like this:
<link rev="made" rel="Author"
href="mailto:fredbloggs@example.com">
As you (hopefully) noticed, I also included an Author relationship, for the benefit of browsers that don't implement rev well.
Some versions of Lynx will use the content of a title attribute as the subject of the e-mail being sent, but that's not necessarily a good use of the attribute. Title is normally used to reveal the name of a target, in which case the name of the person being e-mailed is probably a more logical choice.
References: HTML, HTML+, Maloney/Quinn, iCab
Not Recommended: Indirect Relationship. Indicates that the person represented by the target and the person represented by the current page have physically met. Met is not necessarily the same as acquaintance, because you can use computers (and telephones, and letters, and messenger pigeons, and...) to become acquainted with people you've never physically met. Met is usually combined with one or more of the other XFN relationship values.
References: XHTML Friends Network 1.0
According to Maloney and Quinn, this relationship "identifies a hypertext link to a node which contains meta-information related to the current document". Most such meta information isn't really meant to be read by humans -- this relationship is more useful for auto-discovery: the locating of machine-readable metadata by software.
Three separate metadata projects currently encourage using meta to link to RDF/XML files: the Dublin Core Metadata Initiative, the Creative Commons, and the FOAF Project.
References: Maloney/Quinn, XHTML 2.0
Not Recommended: Indirect Relationship. Indicates that the person represented by the target URI is an inspiration to the person represented by the current URI. (I could use some inspiration right now. This list is killing me.)
References: XHTML Friends Network 1.0
Not Recommended: Reserved Word. This relationship labels the target as a "navigational aid" for the current collection of documents. The Navigator relationship was used in one old browser, but giving a LINK button the same name as a popular browser is a bad idea.
References: Maloney/Quinn
Not Recommended: Indirect Relationship. Indicates that the person represented by the target URI is physically living near the person represented by the current URI, but that the two people don't live together. (That would a co-resident relatonship.)
References: XHTML Friends Network 1.0
Recommended. The Next relationship indicates that the current and targetted documents have a linear relationship (should be read in specific order) and that the targetted document follows the current one. Logically, rel="Next" can be paired with rev="Prev", but that would excessive.
The Next has special meaning for some web browsers: later versions of Internet Explorer, Mozilla, and WebTV will "prefetch" a document identified as Next, in order to speed up reading through a collection of documents. These browser only prefetch one Next item for any given document, so Next can't (and shouldn't) be abused to force users to download entire sites.
References: TimBL, HTML+, HTML 3.0, Maloney/Quinn, HTML 3.2, HTML 4.01, XHTML 1.0, iCab, Mozilla, XHTML 2.0
Not Recommended. According to Dave Ragget, this relationship is "[u]sed in a node specifying a hypertext path to specify a node on that path". If you don't know what that means, don't feel bad about it; Dave's talking about a model of hypertext that the Web doesn't really follow, so this relationship is pretty much useless.
References: HTML+, Maloney/Quinn
Not Recommended: Verb Problem Indicates that "the target document is a later version of the current document". Like all the verb-based relationships, it suffers from the verb problem. Use DCTERMS.isReplacedBy from the Dublin Core instead.
References: Maloney/Quinn
Not Recommended. This relationship was suggested as a label for the "top" or "first" page in the hierarchy of the current collection. Use the Start relationship instead.
References: Maloney/Quinn
Not Recommended: Verb Problem This relationship indicates that the person(s) represented by the current document owns the target document. This relationship suffers from the verb problem.
References: HTML
Not Recommended: Namespace Collision. According to Maloney/Quinn, the Parent relationship indicates that the current document and the target document have a hierarchical relationship, and that the target is the immediate parent of the current document. XFN uses this relationship to indicate that the person represented by the target is the biological/legal parent of the person represented by the current page.
The XHTML 2.0 Working Draft apparently uses Parent as a synonym for Top.
References: HTML+, Maloney/Quinn, XHTML 2.0, XHTML Friends Network 1.0
Not Recommended. According to Dave Ragget, this relationship is "[u]sed in a node specifying a hypertext path to insert a path defined in another node". If you don't know what that means, don't feel bad about it; Dave's talking about a model of hypertext that the Web doesn't really follow, so this relationship is pretty much useless.
References: HTML+, Maloney/Quinn
Not Recommended. Indirect relationship. Used by some bloggers to point to the PGP public key of the blog's author. (I've long advocated distributing PGP keys on the web, but I don't like this relationship because the object of the relationship isn't the page, it's the page's author.)
Reference: http://philringnalda.com/blog/2004/02/links_rels_and_profiles.php
Not Recommended. Devised by Maloney and Quinn, who said "The pointer relationship identifies a hypertext pointer. That is, this is a way to do indirection in HTML." There are no browsers that support the Pointer relationship.
References: Maloney/Quinn
Not Recommended: Verb Problem The Precedes relationship indicates that the current and targetted documents have a linear relationship (should be read in specific order) and that the targetted document follows the current one. Suffers from the verb problem. Use Next instead.
References: HTML
Not Recommended. This relationship indicates that the target document must be presented to the user whenever the current document is, effectively ordering the user's browser to load the target page immediately. Obviously, the guys who created pop-up advertisements would love this relationship, which is why the rest of us must swear to never, ever use it.
References: HTML
Recommended. The Prev relationship indicates that the current and targetted documents have a linear relationship (should be read in specific order) and that the targetted document precedes the current one. Logically, rel="Prev" can be paired with rev="Next", but that would excessive.
References: HTML 4.01, iCab, XHTML 2.0
Not Recommended. The Previous relationship indicates that the current and targetted documents have a linear relationship (should be read in specific order) and that the targetted document precedes the current one. You should use Prev instead, if only because that's what HTML 4.01 recommends.
References: TimBL, HTML+, HTML 3.0, Maloney/Quinn, HTML 3.2, XHTML 1.0, iCab, Mozilla
Listed in the XHTML 2.0 Working Draft, but not actually defined.
References: XHTML 2.0
Recommended. This relationship is used by the Platform for Privacy Preferences 1.0 to indicate that the target is a machine-readable privacy policy for the current document.
References: http://www.w3.org/TR/P3P/#syntax_link, XHTML 2.0
Indicates that the target object represents a person or group responsible for publishing the current document.
References: Maloney/Quinn
Listed in the XHTML 2.0 Working Draft, as a replacement for meta http-equiv="refresh". (XHTML 2.0 is not going to have a http-equiv for the META element, so it needs to use LINK.)
References: XHTML 2.0
Not Recommended: Verb Problem This relationship indicates that one document makes arguments which refute the arguments made by another document, but the verb problem clouds the issue of which document is which.
References: HTML
Not Recommended. The Reply relationship indicates that the targetted document is a commentary on the current document. The concept of "commentary" is pretty vague, and can include documents reviewing, rebutting, or agreeing with the original document.
Reply should only be used when the target has "equal footing" (a similar scope and level of development) with the current document. Less-developed documents (or ones that only comment on part of the current document) should be identified with the Annotation relationship.
Listed in the XHTML 2.0 Working Draft, but not actually defined.
References: XHTML 2.0
This relationship indicates that the target is a "reference description" for the metadata scheme used by the current document. This relationship was originally devised as part of RFC 2731, "Encoding Dublin Core Metadata in HTML", and is only used by a two or three metadata schemas.
The identifier that appears after the dot in a Schema label associates it with metadata headers which begin with that identifier. For example, the two meta elements below are identified as using the metadata scheme described at the URL listed in the accompanying LINK:
<meta name="DC.Title" content="Welcome to Websnob">
<meta name="DC.Description" content="A hostile guide to web design.">
<link rel="schema.DC" content="http://purl.org/DC/elements/1.0/">
I only know of three metadata initiatives which encouraged this use of the LINK element: A-Core, The Dublin Core Metadata Initiative, and Vancouver Webpages. (The Mozilla web browsers will actually hide this link from users, because it often links to an RDF file that isn't particularly useful for normal users.)
References: http://www.ietf.org/rfc/rfc2731.txt
Not Recommended. Suggested by the XHTML 1.0 specification, in lieu of using the SCRIPT element. Not utilized by any browser that I know of.
References: XHTML 1.0
Not Recommended: Reserved Word. This relationship points to a document that provides search service for the current document. Use Index instead.
References: HTML, HTML 3.2, iCab, Mozilla
Recommended. This relationship indicates that the targetted document is a major section of the collection of documents containing the current document. Mostly useful for "book-like" web structures, but occasionally useful for other hierarchical web structures. For example, one might say that Websnob is a section of Bauser.com.
References: HTML 4.01, Mozilla, XHTML 2.0
Used by websites implementing the Atom API to point to a URI used for editing blog posts.
Reference: http://atomenabled.org/developers/api/atom-api-spec.php#Edit.Locating
Points to the location of an Atom syndication feed. (Many websites still use alternate, because that's what was recommended by earlier drafts of the Atom API.)
Reference: http://atomenabled.org/developers/api/atom-api-spec.php#Feed.Locating
Used by websites implementing the Atom API to point to a URI used for posting new blog entries.
Reference: http://atomenabled.org/developers/api/atom-api-spec.php#Post.Locating
Not Recommended: Questionable Syntax. The target of this relationship is an .ico file that is to be used for identifying the target document in a browser shortcut list. Depending on your point of view about whitespace in rel values, this attribute may or may not be illegal HTML.
References: http://msdn.microsoft.com/workshop/Author/dhtml/howto/ShortcutIcon.asp
Not Recommended: Namespace Collision. In the Malony/Quinn draft, the sibling relationship indicates that current document and the target document are part of a hierarchical structure, but hold equivilent positions in the hierarchy. In the XFN specification, sibling is used to indicate the the two persons represented by the current and target URIs share a human parent.
References: Maloney/Quinn, XHTML Friends Network 1.0
Not Recommended: Indirect Relationship. Used by XFN to indicate that person represented by the target page and the person represented by the current page are married. (There's no word yet on XFN's opinions of civil unions.)
References: XHTML Friends Network 1.0
Recommended. The Start relationship identifies the document that should be considered the "starting point" of a collection of documents. In other words, Start shows which page is the "home page" or "top page" of your site.
References: HTML 4.01, XHTML 1.0, iCab, XHTML 2.0
Recommended. The Stylesheet relationship of the LINK element is the preferred way of attaching a stylesheet to a document. In addition to being the only method that's compatible with HTML 2.0, it also makes maintaining the style sheet easier, since you only have to replace the stylesheet file to change the styles for an entire site.
In HTML 4.0/4.01 documents, links to stylesheets should also include the type attribute, since stylesheets aren't HTML. For example:
<link rel="Stylesheet" type="text/css"
href="default.css">
Using the type attribute isn't strictly necessary (assuming your web server identifies the content-type of stylesheets properly), but may save you some bandwith in the long run by preventing smart browsers from requesting style sheets they can't parse.
References: HTML+, HTML 3.0, Maloney/Quinn, HTML 4.01, XHTML 1.0, XHTML 2.0
Not Recommended: Indirect Relationship. Introduced at the same time blogroll was, this is one of those realtionships that doesn't specify the relationship between two web objects, but specifies the relationship between a web object and the person represented by another web object. In this case, the target URI is a list of weblogs (in OPML) subscribed to by the person represented by the current document.
Reference: Radio UserLand : Links for Blogroll, RSS and Subscriptions
Not Recommended. The Subdocument relationship indicates that the current document and the targetted document have a hierarchical relationship, and that the target is the immediate child of the current document.
In a post to the www-talk mailing list, Dave Raggett suggested that this relationship "can be used to propagate properties of the parent node to their children, e.g. Style Sheets and Contents 'pages". To the best of my knowledge, no browser implements the feature this way. Among other things, it would force browsers to retrieve the parent node whenever they retrieved the subdocument, even if the user doesn't intend to read the parent document.
Recommended. This relationship indicates that the targetted document is a signficant subsection of the collection of documents containing the current document. Mostly useful for "book-like" web structures, but occasionally useful for other hierarchical web structures. For example, one might say that HTML Snob is a subsection of Websnob, which is a section of Bauser.com.
References: Mozilla, XHTML 2.0
Not Recommended: Verb Problem. This relationship indicates that one document is a new version of another document, but the verb problem clouds the issue of which document is which. Dublin Core's DCTERMS.replaces is a more widely understood equivilent.
Not Recommended: Verb Problem. This relationship indicates that one document makes arguments supporting the arguments made by another document, but the verb problem clouds the issue of which document is which.
References: HTML
Not Recommended: Indirect Relationship. Sweetheart is the XFN label that fits somewhere between Date and Spouse -- the people represented by the current and target URIs are dating exclusively, but not married.
References: XHTML Friends Network 1.0
Not Recommended. Used in HTML 3.0 (and at least one no-longer-supported browser) to indicate "Table of Contents". The Contents relationship is better-recognized by users.
References: HTML 3.0, Maloney/Quinn, iCab
Recommended? This relationship is intended to label the targetted site as the "top" or "first" page in the hierarchy of the current collection. Hierarchical and spacial metaphors are overrated, so I want to tell you to use the Start relationship instead. However, the Top relationship has appeared on enough websites that I have to admit, it's going to stick around.
References: Maloney/Quinn, HTML 3.2, iCab, Mozilla
Not Recommended. Indicates the target document contains trademark information for current document.
References: Maloney/Quinn
Proposed for linking an XHTML document to an XSLT stylesheet which may be used to extract RDF statements from the XHTML document. This will probably supersede xslt2rdf.
References: http://www.w3.org/2004/01/rdxh/spec
Not Recommended. Indicates that the target document is a translated version of the current document. Use Alternate or DCTERMS.IsVersion (with an hreflang attribute) instead.
References: Maloney/Quinn
Recommended. The Up relationship indicates that the current document and the targetted document have a hierarchical relationship, and that the target is the immediate parent of the current document.
References: TimBL, HTML 3.0, iCab, Mozilla
Not Recommended: Verb Problem. This relationship indicates that "the target document contains revisions to current document". Suffers from the verb problem, so use Annotation instead.
References: Maloney/Quinn
Not Recommended. According to Dave Ragget, this relationship means the target is a Uniform Resource Catalog for the current document. Since Uniform Resource Catalogs don't actually exist, this is a useless relationship. (In fact, I've never even seen a definition of what a "uniform resource catalog" was supposed to be; it may have been an early version of the "uniform resource citation" and "uniform resource characteristics" used in some metadata systems.)
References: Maloney/Quinn
Not Recommended. Tim Berners-Lee suggested this link relationship for indicating a database that could be used for browser- driven glossary lookups concerning the current document. Several browsers (and browser plugins) now implement a feature very similar to what Berners-Lee proposed, but use their own choice of glossary database rather than one suggested by the document owner. Since there are no browsers supporting this relationship, you're better off creating a human-readable glossary and identifying it with the Glossary relationship.
References: TimBL, HTML, HTML+
Not Recommended. Similar to UseGlossary, Tim Berners-Lee suggested this link relationship for indicating a database that could for browser- driven searches of the current document (or document collection). Never implemented by any browser I know of, so you're better off creating your own interface to an index and identifying it with the Index relationship.
References: TimBL, HTML, HTML+
Proposed for linking an XHTML document to an XSLT stylesheet which may be used to extract RDF statements from the XHTML document. This will probably be superseded by Transformation.
References: http://www.w3.org/2003/11/rdf-in-xhtml-proposal
Many people (most of them smarter than me) have contributed to the discussions of link relationships. Here are some the key references, in chronological order of publication.
Tim Berners-Lee (who invented the Web, if you didn't know) discussed link relationships in his design note on link relationships. Although he never mentioned the rel or rev attributes, some of his labels later reappeared in other documents referenced here.
The HTML Internet Draft (the closest thing there is to an "HTML 1.0") lists some suggested link relationships in an appendix. Some of the relationships listed here only appear in a 1991 version of the HTML draft.
Dave Ragget's 1993 proposal for revamping HTML, HTML+ sneaks 16 recommendations for relationship values into the HTML+ DTD. Most of them are not recommended by HTML Snob, either because they use reserved words, or depend on users understanding definitions derived from hypertext theory.
The expired (and underimplemented) HTML 3.0 Draft included some recommended relationships in Section 5: The HEAD Element and Related Elements.
The HTML 2.0 Specification mentions link relationships (as part of the LINK element) in Section 5.2.4, but doesn't list make any recommendations for relationship values.
Murray Maloney and Liam Quinn produced a working draft on Hypertext links in HTML that discussed many relationship values seen "in the wild" and proposed many more. The Maloney/Quinn draft never passed working draft status.
The HTML 3.2 Reference Specification suggests ten relationship values in its section about The LINK element. With three exceptions, all the HTML 3.2 relationships are derived from the HTML 3.0 relationships.
The HTML 4.01 Specification lists some recommended relationships in Section 6.12: Link types.
The XHTML 1.0 Specificatoin reiterates some of the HTML 4.01 recommened links in the XHTML 1.0 Transitional DTD, and adds one I haven't seen anywhere else: script.
iCab is a commercial web browser for the Macintosh. iCab's FAQ lists which link relationships it supports when rendering the link element. iCab gets special attention here, because it supports at least one relationship (Find) that I haven't seen anywhere else.
The Mozilla web browser includes support for the link element in most builds since 0.95, but it's not turned on by default. Although Mozilla incorporates most author-defined links into its link menu, the link relationships listed on this page with Mozilla as a reference are the ones that appear on Mozilla's default link menu.
This version of XHTML is still in development, but it the development notes do include some suggested link relationships, including a few not seen in earlier versions of HTML or XHTML.
Returning to the nearly-abandoned idea of using link relationships to map the relationships between people represented by web pages (as opposed to mapping the relationship between the pages themselves), the GMPG Group proposed the XHTML Friends Network (or, XFN), a set of labels for mapping relationships between human beings.
The XFN specification is a tragically underwritten document, that doesn't include enough clear examples (it could use an explanation the difference between acquaintance and met, for instance). Where it does bother to go into detail (its discussion of family relationships), it reveals some ethnocentric assumptions about kinship structures that will limit its potential as an international standard. But the bloggers like it, so I have to list it here.
[an error occurred while processing this directive]