Comment Anywhere Annotation Protocol Proposal

Introduction

The basic building block of this annotation proposal is the queryable Atom feed. Each user has their own feed, through which they publish annotations. This proposal includes definitions of:

1. Extensions to Atom to support publishing of annotations
2. A protocol for query publishing feeds
3. Protocols for integrating with web pages

Atom Extensions

Atom is a protocol for notifying of content that has been published. The canonical use case for Atom is weblogs - each time a new entry is published in a weblog, a new entry is added to an Atom feed. Clients can then query the feed to find these newly published entries. Atom is defined in RFC 4287.

Comment Anywhere uses existing standards where possible.

Feeds URIs

While the concept of a feed URI is not explicit in the Atom standard, applications that retrieve feeds via HTTP must be aware of each feed's URI. Feed URIs are a useful means of identifying feeds, and are important for informal social networking: people recommend feed URIs to one another and they can trust that content on a feed URI comes from the owner of that URI.

Comment Anywhere defines a feed URI as a URI where a Comment Anywhere feed is published. A feed URI must not have a query or fragment part. The following are examples of valid feed URIs:

  http://www.undulating.com/weblogs/people/jon/feed.xml
  http://kittycart.net/atom
  http://www2-146.hal.com/feeds/main/

As described below, a feed URI can be queried.

Entry ID

As specified in [ section 4.1.2] According to section 4.1.2 of RFC 4287, each Atom entry has an ID. In standard Atom, this ID is a URI, but it is has no meaning other than to uniquely identify an entry. In Comment Anywhere, this ID not only identifies the entry, it also identifies the canonical location of the entry, which is the location where it was first published. A valid entry can always be retrieved from the canonical location specified by its ID.

The ID is based on the URI of the publishing feed that first published the entry, and is of the following form:

 feed-uri?entry=some-string

The following are both valid entry IDs:

  http://example.org/feed?entry=00001
  http://example2.org/user/rob?entry=2007-12-10-python-rocks

This format was chosen because it is simple to identify the original feed URI from a given entry URI.

Additional link rel types

An Atom link tag has a "rel" attribute that specifies the kind of relationship the link represents. Section 4.2.7.2 of RFC 4287 allows for arbitrary URI's to be used as values for the rel attribute. Comment Anywhere defines one additional link rel value.

base-uri/target

this link specifies the target or subject of the annotation.

The value of base-uri is arbitrary, and we propose http://laptop.org/commentanywhere.

Additional tags

Comment Anywhere defines one new tag for atom entries:

ca:available

an Atom timestamp that identifies when this entry became available for query on the current feed. This may differ from published date when an entry orginally published on one feed is served on another feed.

We propose http://laptop.org/commentanwhere to identify the XML namespace for Comment Anywhere tags, with "ca" being the customary prefix.

Restrictions on Atom Feeds

Not so many of these yet:

1. The tags "published", "title" and "content" are mandatory in Comment Anywhere entries.

Querying Publishing Feeds

Publishing feeds support a simple query protocol. It allows users and aggregators to retrieve entries in which they are interested without needing to retrieve every published entry.

Integrating with Web Pages

1. Trackbacks

What's Missing

Some areas that we haven't yet given a lot of thought to are:

1. identifying fragments of a page to which annotations apply.
2. how individuals publish annotations to their publishing feed.
3. the notion of work groups with a particular identity.
4. privacy - currently all annotations are public.

Background

Comment Anywhere grew out discussions between Alec Thomas and Alan Green about open and distributed social networks. We were pleasantly surprised by the amount of overlap between this proposal and the Original Annotation API Proposal.