There exists a need for the ability to express semantics for links used in web communication. Many ideas and resources are shared between content providers and users on web sites, web-logs, forums, mailing lists, newsgroups and wikis, etc; and many of these provide, or are built around, the ability to receive and publish content from a variety of sources including user contribution. Additionally, it is becoming increasingly important to keep track of these ideas and resources, and how they spread among the web community.
The basic mechanism used to share these ideas and resources is through the use of hyperlinks; yet, until now, the ability to express semantic relationships has been limited to the Link Types defined in HTML 4.01 ([HTML4], section 6.12) and, more recently, those defined by the Global Multimedia Protocols Group such as the XHTML Friends Network [XFN11].
Beyond that, however, there has been no way to express relationships between content providers (or publishers), users and their contributions; identification of useful resources; nor the communication paths and attribution between publishers. Additionally publishers are requesting the ability to express levels of endorsement for remote resources.
This document is the first public Working Draft of this proposal. It should in no way be considered stable, and should not be normatively referenced for any purposes whatsoever. Comments are welcome and may be e-mailed to me.
This is a draft document and may be updated, replaced or made obsolete by other documents at any time. It is inappropriate to cite this document as other than "work in progress."
Web communication involves the sharing of ideas and resources across the web through publicly accessible documents. Over the years, many facilities have been set up and maintained for the purposes of such communication including web sites, web-logs, forums, mailing lists, newsgroups and wikis. Many of these provide, or are built around, the ability to receive and publish content from a variety of sources including user contribution; which is often archived and and made publicly available as an historical record.
The basic mechanism used to share ideas and resources is through the use of hyperlinks; yet, until now, the ability to express semantic relationships has been limited to the Link Types defined in HTML 4.01 ([HTML4], section 6.12) designed to express relationships within a single collection of documents; and, more recently, those defined by the Global Multimedia Protocols Group such as the XHTML Friends Network 1.1 [XFN11] to represent human relationships.
The scope of this is to define link relationships that will facilitate web communication through increased linking semantics. This proposal will not define relationships designed for the purpose of providing rating systems to be used specifically for ranking purposes, such as that used by search engines; however, this does not prevent user agents from increasing or decreasing the value of a link based on the semantics defined for these relationships, where appropriate.
This proposal defines a profile intended to extend and complement the existing link types with new relationships designed to facilitate web communication by expressing semantics relationships between content providers (or publishers), users and their contributions; identifying useful resources and the communication paths and attribution between publishers. This will also address the ability to express levels of endorsement and recommendation for resources. This proposal attempts to meet these requirements in a way that will facilitate communication on the web while, at the same time, preventing, or at least limiting, the possibility of any detrimental effects that may be caused by unethical practices exercised by some content providers.
In WCLR, a number of design aims and criteria have been used.
By providing increased semantics for link relationships, rather than defining purely functional relationships, user agents are free to make use of these in whatever way is deemed appropriate for the user.
This proposal does not include any definition for the namespace of these relationships; however it is expected that, due to the increasing number of link relationships being defined and used by various organisations, namespaces will become necessary in the near future. If, and when, a mechanism to define namespaces for relationships is standardised, this proposal may be updated to reflect that.
These link relationships are divided into categories, each with a defined scope designed to address a specific requirement. These categories include User Contribution, Resource Tracking, Communication Tracking and Endorsement
These relationships are designed for the purpose of identifying resources contributed by users. Depending on the facility, users may contribute in a variety of ways including writing comments to web logs or forum threads, posting to public mailing lists or newsgroups; using an automatic referral mechanism such as Pingback [PINGBACK] and/or trackback [TRACKBACK]; or editing a wiki page.
referralrelationship, as defined in the Pingback 1.0 [PINGBACK].
referralrelationship using the Trackback mechanism [TRACKBACK].
A user's contribution may, for example, include information such as their
name, home page URI and
comment containing links to other potentially useful resources. A web
communication system may make use of these relationships to identify
the different kinds of links provided. The
should be used to indicate a resource identifying the user, such as the
user's home page URI. Links
provided by the user within the contribution may be assigned the
may be used in conjunction with the
(described more in 3.2.1. Permanent Links: The
to provide a permanent link to the user's comment.
<div id="c1" class="comment"> <p><a href="#c1" rel="contribution permalink">Comment</a> by <a href="http://example.com/adent/" rel="user">Arthur Dent</a> on 2005-01-25T13:40Z</p> <blockquote> <p>I find your ideas about life quite intriguing and thought provoking. I read a similar article recently about <a href="http://example.org/articles/universe" rel="contribution"> the Universe</a> which I thought you might be interested in.</p> </blockquote> </div>
Users may refer to their contributions from their own documents and
may do so using the reverse
linking to their contribution. The
used with the
rev attribute indicates that the remote resource
was contributed by the author/owner of the local resource.
<a href="http://blog.example.com/article/comment#c1" rev="user">my comment</a>
Automated referral mechanisms may be used by some web communication systems.
Currently, two known referral mechanisms exist including Pingback 1.0 [PINGBACK]
and Trackback [TRACKBACK]. The
may be used to indicate, depending on the use of the
a URI for a user to submit
the referral ("ping") or a URI of
the referring resource, respectively. The
trackback relationships may be
used in the same way to indicate the applicable mechanism.
Authors may use the
together with the
however, if the
referral relationship is omitted, user agents may
imply it by the presence of either
<p><a href="http://example.org/2005/02/13/article" title="Article Title" rev="referral pingback">Pingback</a> by <a href="http://example.com/fprefect/" rel="user">Ford Prefect</a></p>
Some referral mechanisms allow for automatic discovery – the process of determining the URI of the resource known as the "target URI" – for the purpose of contributing the referral, called "pinging".
When using the
for autodiscovery, authors should comply with the the constraints
set forth for the link element in Pingback 1.0 ([PINGBACK],
section 2.2). The
was not defined in the Trackback specification [TRACKBACK],
but it is included here for symmetry with
be used like the above example; and for possible inclusion in a later version,
that may be used for autodiscovery. However, it should be noted, that Trackback
defines an alternative method of autodiscovery using RDF.
<link rel="pingback" href="http://blog.example.com/pingback">
feedto designate a syndication format resource for comments.
Permanent links provide a persistent URI for
a resource that may be referenced or bookmarked with some assurance that
the content will remain stable. The
permalink relationship designates
such a URI and may be used
with the anchor
element in HTML 4.01 ([HTML4], section 12.2) to indicate a permanent link
for some, or all, content within the document.
<a href="http://blog.example.com/2005/01/25/article" rel="permalink">Article Title</a> <a href="http://blog.example.com/2005/01/25/article" rel="permalink" title="Article Title">Permalink</a>
Note: Authors should avoid including the
for links where the main content of the remote resource is not wholly, or
partly, contained within the local resource. For example, including the relationship
within a list of recent entries where those entries are not contained in
whole, or in part, within the current document. Even though the URI may
refer to the permanent link for the resource, the relationship is intended
to make a semantic relationship between the local resource content and the
permalink relationship may also be used with the link
element in HTML
4.01 ([HTML4], section 12.3) to designate
the permanent URI for
the current document. This will be useful for documents that may be accessed
via an alias URI (for
example, to retrieve the latest version).
A weather site may, for example, provide a URI as an alias for the most recent forecast.
Because the content of the resource at that URI will
be changing regularly, the
permalink relationship may be used
to indicate the permanent URI for
the day's weather forecast.
<link rel="permalink" href="http://weather.example.com/2005/01/25/forecast">
Note: When used within the
in this way, the main content of the resource indicated should be identical
to that of the current document. Dynamic content, such as that often included
within page headers and/or sidebars, may differ.
The comments for a local resource, which may be contained locally or within
a remote resource, may be identified using the
<a href="/article/comments" rel="comments">Comments</a>
If the comments are contained within a separate resource from the related article, the reverse relationship may be used to identify that this resource contains those comments.
<link rev="comments" href="/article/" title="Finnish Tradition">
Most web communication systems provide some kind of index of archived entries.
These archives, which are often indexed by the date and time of the entries,
may be indicated by the
<ol> <li><a href="/2005/01/" rel="archive">January 2005</a></li> <li><a href="/2004/12/" rel="archive">December 2004</a></li> <li><a href="/2004/11/" rel="archive">November 2004</a></li> ... </ol>
Publishers often provide one or more syndicated versions of their content,
known as "feeds", and may be identified using the
User agents may make use of this relationship to allow users to "subscribe"
to these feeds using an application known as a "feed reader".
<link rel="feed" href="/feed" type="application/atom+xml" title="Web Log Atom Feed">
Previously content providers have made use of the
as defined in the HTML 4.01 Link
Types ([HTML4], section 6.12),
for such purposes. However, the
alternate relationship is defined
as designating a substitute version for the document in which the link occurs.
This definition is unsuitable for syndication feeds because the a syndication
feed usually contains the latest entries; however, when the link appears
in any document, other than the main index page, the content of the feed
will differ significantly.
The relationships within this category are designed to assert communication paths between resources. When an author finds an interesting resource and refers to it from a document, it is common to give attribution to the source where the resource was found. These are often called "via" links, "hat tips" or "head nods". Additionally some authors also like to present related resources often called a "related" link.
It is possible to express these paths, or arcs, using the following XLink construct to indicate that resources "B" and "C" are related to resource "A", which has been located via resource "D". The element names used in the following example are borrowed from the non-normative examples provided within the XLink specification [XLink] and do not represent any particular XML markup language.
<extendedlink xlink:type="extended"> <loc xlink:type="locator" xlink:href="..." xlink:label="resource" xlink:title="A" /> <loc xlink:type="locator" xlink:href="..." xlink:label="related" xlink:title="B" /> <loc xlink:type="locator" xlink:href="..." xlink:label="related" xlink:title="C" /> <loc xlink:type="locator" xlink:href="..." xlink:label="via" xlink:title="D" /> <go xlink:type="arc" xlink:from="related" xlink:to="resource" /> <go xlink:type="arc" xlink:from="via" xlink:to="resource" /> ... </extendedlink>
Because XLink cannot be used within HTML documents, it currently not feasible to express these relationships on the web. This category is included for the possibility that it may be feasible to express these communication paths as relationships to implicitly link the resources to each other. For this purpose, the following relationships are included.
Using these relationships, it is intended that the above XLink example may be implicitly expressed in the following way:
<p> <a href="..." rel="resource">A</a> was an interesting article. (Related to <a href="..." rel="related">B</a> and <a href="..." rel="related">C</a>, via <a href="..." rel="via">D</a>) </p>
Note: This specification does not place any
limit on the number of resources identified with either of the
via relationships that may be associated with a resource; but
each related and via link may only be associated with the single most recent
resource identified by the
resource relationship within
the document hierarchy.
Note: If it is found that defining these relationships is not feasible using this or any other suggested method, this category may be dropped.
Note: To avoid abuse of these relationships
through unethical practices exercised by some content providers, non-interactive
user agents that apply ranking to a resource based on the links referring
to it, such as a search engine, should not apply an above normal rating
for links with the
endorsed relationship, and must not apply a
negative rating for
unendorsed (though, the rating may be reduced
in that case).
sponsor relationship may be used to identify an entity that provides
sponsorship for the local resource.
<p>This site is sponsored by: <a rel="sponsor" href="http://business.example.com/">Example Business Pty. Ltd.</a></p>
Using the reverse relationship, this may also be used to identify resources that are sponsored by the local resource.
<p>All proceeds received will be donated to <a rev="sponsor" href="http://charity.example.org/">Example Charity</a>.</p>
endorsed relationship may be used to recommend a resource to users.
<p>I recommend <a href="http://food.example.com/dutch-cheese" rel="endorsed">Dutch Cheese</a>.</p>
Interactive user agents may highlight or present these links in a way that informs the user that the resource is recommended. Non-interactive user agents designed to rank resources based on the links referring to them should not apply an increased rating for these links.
unendorsed relationship may be used to identify resources that may be
relevant, but are not recommended or not approved by the author/owner
of the local resource.
<p>I recently discovered that <a href="http://bad-co.example.com/" rel="unendorsed">Bad Co. Inc.</a>, provide a service that I do not consider appropriate.</p>
This relationship may also be used in conjunction with the
to identify un-moderated user contributions.
... <p>I find your ideas about life quite intriguing and thought provoking. I read a similar article recently about <a href="http://example.org/articles/universe" rel="contribution unendorsed">the Universe</a> which I thought you might be interested in.</p> ...
Note: Content providers should not unconditionally apply this relationship and leave it applied to all links, including those from user contributions. If this relationship is applied at all under those conditions, it should be removed as soon as possible after moderation.
Interactive user agents may highlight or present these links in a way that informs the user that the resource is not recommended. Non-interactive user agents designed to rank resources based on the links referring to them may apply a reduced, or no, rating for these links, but must not apply a negative rating.