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 types

As allowed by section 4.2.7.2 of RFC4287, Comment Anywhere defines the following values for the atom:link tag’s rel attribute:

1. rel=”http://www.corp.google.com/~aat/commentanywhere/target”. Specifies the target of the entry. For a comment about a web page, this will be the URI of the web page. Each comment must have exactly one target.
2. rel=”http://www.corp.google.com/~aat/commentanywhere/reply-parent”. If comment B is made in reply to comment A, then comment B will have a reply-parent link to comment A. Maximum one per entry.
3. rel=”http://www.corp.google.com/~aat/commentanywhere/reply-child”. If comment B is made in reply to comment A, then comment A may have a reply-child link to comment B. Zero or more reply-child links are allowed.

It is expected that the final Comment Anywhere protocol will allow FIXptr style references to particular parts of web pages when specifying a target. However, this will not be part of the initial proof of concept prototype.

Other tags

1. All text type tags must contain plain text only. Likewise, Content tags may contain plain text only.
2. Each entry must have the following tags: “published”, “author”, “title”, and “content”.
3. Aggregated entries must include a timestamp tag named “ca:available”. It is of the same format as “published” and “updated”, and indicates when the entry became available for query on the server. For a local entry, it likely has the same time as the “published” timestamp.

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.