Comment Anywhere Annotation Protocol Proposal: Difference between revisions
m (→Feeds URIs) |
|||
Line 42: | Line 42: | ||
This format was chosen because it is simple to identify the original feed URI from a given entry URI. |
This format was chosen because it is simple to identify the original feed URI from a given entry URI. |
||
=== Additional link types === |
=== Additional link rel types === |
||
An Atom link tag has a "rel" attribute that specifies the kind of relationship the link represents. [http://tools.ietf.org/html/rfc4287#section-4.2.7.2 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. |
|||
As allowed by section 4.2.7.2 of RFC4287, Comment Anywhere defines the following values for the atom:link tag’s rel attribute: |
|||
; <tt><i>base-uri</i>/target</tt>: this link specifies the target or subject of the annotation. |
|||
# 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. |
|||
# 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. |
|||
The value of base-uri is arbitrary, and we propose <tt><nowiki>http://laptop.org/commentanywhere</nowiki></tt>. |
|||
# 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 === |
=== Other tags === |
Revision as of 03:49, 15 August 2007
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:
- Extensions to Atom to support publishing of annotations
- A protocol for query publishing feeds
- 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.
Other tags
- All text type tags must contain plain text only. Likewise, Content tags may contain plain text only.
- Each entry must have the following tags: “published”, “author”, “title”, and “content”.
- 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
- Trackbacks
What's Missing
Some areas that we haven't yet given a lot of thought to are:
- identifying fragments of a page to which annotations apply.
- how individuals publish annotations to their publishing feed.
- the notion of work groups with a particular identity.
- 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.