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.

This proposal reuses existing standards where possible.

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.

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