(Redirected from reltag)
Contents
|
This specification is (C) 2004-2012 by the authors. However, the authors intend to submit this specification to a standards body with a liberal copyright/licensing policy such as the GMPG, IETF, and/or W3C. Anyone wishing to contribute should read their copyright principles, policies and licenses (e.g. the GMPG Principles) and agree to them, including licensing of all contributions under all required licenses (e.g. CC-by 1.0 and later), before contributing.
This specification is subject to a royalty free patent policy, e.g. per the W3C Patent Policy, and IETF RFC3667 & RFC3668.
Rel-Tag is one of several MicroFormats. By adding rel="tag"
to a hyperlink, a page indicates that the destination of that hyperlink is an author-designated "tag" (or keyword/subject) for the current page. Note that a tag may just refer to a major portion of the current page (i.e. a blog post). e.g. by placing this link on a page,
<a href="technorati.com/tag/tech" rel="tag">tech</a>
the author indicates that the page (or some portion of the page) has the tag "tech".
The linked page SHOULD exist, and it is the linked page, rather than the link text, that defines the tag. The last path component of the URL is the text of the tag, so
<a href="technorati.com/tag/tech" rel="tag">fish</a>
would indicate the tag "tech" rather than "fish".
rel="tag" is specifically designed for "tagging" content, typically web pages (or portions thereof, like blog posts).
rel="tag" is NOT designed for "tagging" arbitrary URLs or external content. There is demand for a general decentralized syntax for tagging URLs external to the current page, but this is not meant for that. See xFolk and hReview for ways to tag arbitrary URLs.
If you need to define tags as part of a more specialized format, rel="tag" is the recommended way to do so, and xFolk, hReview, hCard, hCalendar and hRecipe all do this.
See rel-tag-profile.
www.example.com/tags/foo
Thus, for the purposes of comparing two HTTP URIs as tags, the last segment of the path portion should be extracted and only that value (that value of the tag) should be compared.
Need more formal language about comparison and extraction process.
The destination of a rel="tag" hyperlink is required to be a tag space (a place that collates or defines tags), where the last segment of the path of the URL is the tag, e.g.
technorati.com/tag/tech
is a URL for the tag "tech".
Tags may only be placed in the URL path, and only in the last segment of the path. Tags may not be placed in query parameters or fragment identifiers. e.g.
technorati.com/tag/tech?tag=fish#emu
is still a URL for the tag "tech", not "fish" or "emu".
Since the only part of a tag space URL of which any structure is required is the last path segment, a tag space URL can be hosted at any domain. Authors may choose to link to a tag at a particular tag space in order to provide a specific meaning. E.g. a tag for technology could link to:
en.wikipedia.org/wiki/Technology
Trailing slashes in tag URLs are ignored, that is:
technorati.com/tag/Technology/
as a rel-tag URL is treated as:
technorati.com/tag/Technology
Spaces can be encoded either as +
or %20
. Unicode characters are encoded as specified in RFC 3986. For example:
<a href="technorati.com/tag/Sant%C3%A9+et+bien-%C3%AAtre" rel="tag">Santé et bien-être</a>
Note that if using Wikipedia as a tagspace, as discussed above, you should use %20
as they remap '+' to %2B
, causing a page with a plus sign in the title (which usually does not exist) to appear.
rel="tag"
hyperlinks are intended to be visible links on pages and posts. This is in stark contrast to meta keywords (which were invisible and typically never revealed to readers), and thus is at least somewhat more resilient to the problems which plagued meta keywords.
Making tag hyperlinks visible has the additional benefit of making it more obvious to readers if a page is abusing tag links, and thus providing more peer pressure for better behavior. It also makes it more obvious to authors, who may not always be aware what invisible metadata is being generated on their behalf.
As a result the invisible tag link syntax variant: <link rel="tag" class="..." />
SHOULD NOT be supported by implementations.
This section is informative. The number of rel-tag examples in the wild has expanded far beyond the capacity of being kept inline in this specification. They have been moved to a separate page.
See rel-tag Examples in the wild.
This section is informative.
The following implementations have been developed which either generate or parse rel-tag links. If you have a rel-tag implementation, please add it to the top of this list. Once the list grows too big, we'll make a separate wiki page like rel-tag-implementations.
This section is informative.
Articles about rel-tag, most recent first. When this section gets too big, we can move it to rel-tag-articles.
The rel-tag specification is a work in progress. As additional aspects are discussed, understood, and written, they will be added. These thoughts, issues, and questions are kept in separate pages.