Web Communication Link Relationships (WCLR) Proposal

Working Draft 25 January 2005

This Version:
http://lachy.id.au/dev/markup/specs/2005/WD-wclr-20050125/
Latest Version:
http://lachy.id.au/dev/markup/specs/wclr/
Authors:
Lachlan Hunt
Contributors:
Charl van Niekerk

Abstract

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.

Status of This Document

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."

Table of Contents

  1. 1. Introduction
    1. 1.1. What is Web Communication?
    2. 1.2. Link Relationships
    3. 1.3. Scope of this Proposal
    4. 1.4. Design Aims
    5. 1.5. Relationship Namespaces
  2. 2. Terms and Definitions
  3. 3. Relationship Definitions
    1. 3.1. User Contribution
      1. 3.1.1. Making a Contribution: The user and contribution Relationships
      2. 3.1.2. Automated Referral Mechanisms: The referral, pingback and trackback Relationships
    2. 3.2. Resource Tracking
      1. 3.2.1. Permanent Links: The permalink Relationship
      2. 3.2.2. Comments: The comment Relationship
      3. 3.2.3. Archive Indexes: The archive Relationship
      4. 3.2.4. Content Syndication: The feed Relationship
    3. 3.3. Communication Tracking
    4. 3.4. Endorsement
      1. 3.4.1. Sponsorship: The sponsor Relationship
      2. 3.4.2. Endorsed Resources: The endorsed Relationship
      3. 3.4.3. Unendorsed Resources: The unendorsed Relationship
    4. References

1. Introduction

1.1. What is Web Communication?

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.

1.3. Scope of this Proposal

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.

1.4. Design Aims

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.

1.5. Relationship Namespaces

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.

2. Terms and Definitions

User
Refers to an entity that participates in the communication process that may or may not make a contribution.
Contribution
Content that has been either created or referenced by a user and submitted to a web communication system.
Web Communication System
An online resource used for the purpose of public communication which may allow the ability for user contributions. Such systems include content management systems (CMS) for web sites, mailing list archives, forums, newsgroups and wikis, etc.
Resource
As discussed in RFC 2396 [RFC 2396], a resource is any addressable unit of information or service.
Remote Resource
Any resource or resource portion that participates in a link by virtue of being addressed with a URI reference.
Local Resource
A resource that participates in a link by virtue of having as its parent, or being itself, a linking element.

3. Relationship Definitions

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

3.1. User Contribution

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.

user
Designates a resource used to identify a user that has contributed to a web communication system, such as the user's home page or e-mail address.
referral
Refers to resource has been provided through an automated link referral mechanism, or provides an generic location for referrals to be sent. Links with this kind of relationship are often mutual between resources.
pingback
Mechanism specific referral relationship, as defined in the Pingback 1.0 [PINGBACK].
trackback
Mechanism specific referral relationship using the Trackback mechanism [TRACKBACK].
contribution
Refer's to a user's contribution.

3.1.1. Making a Contribution: The user and contribution Relationships

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 user relationship 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 contribution relationship. Additionally the contribution relationship may be used in conjunction with the permalink relationship (described more in 3.2.1. Permanent Links: The permalink Relationship) to provide a permanent link to the user's comment.

Example
<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 user relationship linking to their contribution. The user relationship used with the rev attribute indicates that the remote resource was contributed by the author/owner of the local resource.

Example
<a href="http://blog.example.com/article/comment#c1" rev="user">my comment</a>

3.1.2. Automated Referral Mechanisms: The referral, pingback and trackback Relationships

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 referral relationship may be used to indicate, depending on the use of the rel or rev attribute, a URI for a user to submit the referral ("ping") or a URI of the referring resource, respectively. The pingback and trackback relationships may be used in the same way to indicate the applicable mechanism. Authors may use the referral relationship together with the pingback and/or trackback relationships, however, if the referral relationship is omitted, user agents may imply it by the presence of either pingback or trackback.

Example
<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 pingback relationship for autodiscovery, authors should comply with the the constraints set forth for the link element in Pingback 1.0 ([PINGBACK], section 2.2). The trackback relationship was not defined in the Trackback specification [TRACKBACK], but it is included here for symmetry with pingback to 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.

Example
<link rel="pingback" href="http://blog.example.com/pingback">

3.2. Resource Tracking

Designates a permanent link for a resource contained within the current document. It may designate the permanent link for the entire local resource or for a single entry within.
comments
Designates a resource containing user contributed comments. May be used in conjunction with feed to designate a syndication format resource for comments.
archive
Designates a resource used as an archival index of resources.
feed
Designates a resource used as a syndication format.

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.

Example
<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 permalink relationship 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 remote resource.

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.

Example
http://weather.example.com/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.

Example
<link rel="permalink" href="http://weather.example.com/2005/01/25/forecast">

Note: When used within the link element 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.

3.2.2. Comments: The comments Relationship

The comments for a local resource, which may be contained locally or within a remote resource, may be identified using the comments relationship.

Example
<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.

Example
<link rev="comments" href="/article/" title="Finnish Tradition">

3.2.3. Archive Indexes: The archive Relationship

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 archive relationship.

Example
<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>

3.2.4. Content Syndication: The feed Relationship

Publishers often provide one or more syndicated versions of their content, known as "feeds", and may be identified using the feed relationship. User agents may make use of this relationship to allow users to "subscribe" to these feeds using an application known as a "feed reader".

Example
<link rel="feed" href="/feed" type="application/atom+xml"
      title="Web Log Atom Feed">

Previously content providers have made use of the alternate relationship, 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.

3.3. Communication Tracking

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.

Example

<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.

resource
Identifies a resource and is used to semantically associate with any succeeding links with the related and/or via relationships.
Refers to a resource that is related to the previous remote resource within the document designated by the resource relationship.
via
Identifies a communication path to indicate where the author located the previous remote resource within the document designated by the resource relationship.

Using these relationships, it is intended that the above XLink example may be implicitly expressed in the following way:

Example

<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 related or 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.

3.4. Endorsement

sponsor
Identifies a sponsor. This indicates that there is an agreement, often financial, between parties, either directly or indirectly via an agency, for the link to be included.
endorsed
Refers to a resource that the author explicitly approves of, and may be regarded as a recommendation from the author for users to access the resource.
unendorsed
Refers to a resource that may be related to the linking document, but is not recommended or not approved by the author/owner of the local resource.

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).

3.4.1. Sponsorship: The sponsor Relationship

The sponsor relationship may be used to identify an entity that provides sponsorship for the local resource.

Example

<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.

Example

<p>All proceeds received will be donated to
<a rev="sponsor" href="http://charity.example.org/">Example Charity</a>.</p>

3.4.2. Endorsed Resources: The endorsed Relationship

The endorsed relationship may be used to recommend a resource to users.

Example
<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.

3.4.3. Unendorsed Resources: The unendorsed Relationship

The 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.

Example
<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 contribution relationship to identify un-moderated user contributions.

Example
...
<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.

4. References

[HTML4]
HTML 4.01 Specification, D. Raggett, A. Le Hors, and I. Jacobs, Editors. World Wide Web Consortium, 17 December 1997, revised 24 December 1999. This version of the HTML 4.01 Recommendation is http://www.w3.org/TR/1998/REC-html40-19980424. The latest version of HTML 4 is available at http://www.w3.org/TR/html4/.
[PINGBACK]
Pingback 1.0 Specification, S. Langridge, and I. Hickson, Editors. 2002. This version of the Pingback 1.0 Specification is http://www.hixie.ch/specs/pingback/pingback-1.0. The latest version of Pingback is available at http://www.hixie.ch/specs/pingback/pingback.
[RFC 2396]
Uniform Resource Identifiers (URI): Generic Syntax, T. Berners-Lee, R. Fielding, L. Masinter. IETF, August 1998. RFC 2396 is available at http://ietf.org/rfc/rfc2396
[TRACKBACK]
Trackback Technical Specification, B. Trott, and M. Trott, Editors. MovableType,10 October 2002. This latest version of the Trackback Specification is http://www.movabletype.org/docs/mttrackback.html
[XFN11]
XHTML Friends Network 1.1, T. Çelik, M. Mullenweg, and E. Meyer, Editors. Global Multimedia Protocols Group, August 2004. This version of the XFN Profile is http://gmpg.org/xfn/11. The latest version of XFN is available from http://gmpg.org/xfn/.
[XLink]
XML Linking Language Version 1.0, S. DeRose, E. Malar, and D. Orchard, Editors. World Wide Web Consortium, 27 June 2001. This version of the XLink 1.0 Recommendation is http://www.w3.org/TR/2001/REC-xlink-20010627/. The latest version of XLink is available at http://www.w3.org/TR/xlink/.