First of all, Roger Sperberg wrote an excellent comment about the current OPDS draft:

With blogging, the Atom feed entry ought to include either a content child — containing the full blog post or a link to it (and the link relationship identified as ‘alternate’) — or a summary child whose content is an extract, abstract or short summary of one of the three types above.

If OPDS is a catalog of books, then there’s a mismatch between the blog model and the catalog model. The content in the catalog is material about a book, and the feed therefore ought to have the full material in content or a summary of it. A link child of contentshould take the feed’s consumer to that “full material.”

So maybe the catalog copy shouldn’t be likened to blog posts.

Then content could contain a link to the epub, and the catalog description would go into summary. Of course, the full descriptions in the catalog might be too long to use as intended in this type of feed.

In that case, just create a new type of relationship link, as was done in the examples for cover image and thumbnail, that describes whether this longer content is a synopsis, review or just longer description.

I agree with most of this comment. It makes more sense to use content for the EPUB file and summary for the description. We should also extend Atom rather than describe everything in XHTML: using DublinCore to describe the language, copyright status, publication date and other metadata.

Partial entry/Full entry

The current draft is full of new rel values, a design choice that we should avoid as much as possible (most of the time, a type and a rel value registered at the IANA link registry would be enough).

To support entries with longer content, as recommended by Roger Sperberg, we don’t need a new relationship link. In AtomPub:

Clients MUST NOT assume that an Atom Entry returned in the Feed is a full representation of an Entry Resource and SHOULD perform a GET on the URI of the Member Entry before editing it.

In the same RFC5023 for AtomPub, the “type” parameter was defined:

This specification defines a new “type” parameter for use with the “application/atom+xml” media type. The “type” parameter has a value of “entry” or “feed”.
Neither the parameter name nor its value are case sensitive.
The value “entry” indicates that the media type identifies an Atom Entry Document. The root element of the document MUST be atom:entry.
The value “feed” indicates that the media type identifies an Atom Feed Document. The root element of the document MUST be atom:feed.
If not specified, the type is assumed to be unspecified, requiring Atom processors to examine the root element to determine the type of Atom document.

Thanks to this type parameter, it’s fairly easy to point from a partial entry to a full entry using a link@rel="alternate"

<link rel="alternate" type="application/atom+xml;type=entry" href="..." />

For sources with a RDF document available (such as O’Reilly, and Feedbooks in the upcoming weeks), the same link@rel="alternate" could be used with application/rdf+xml.

Controlled vocabularies

The publication metadata required and allowed in OPF, should have the same status in OPDS.

Once the goals for OPDS are clearly defined (oops), we might extend this.

Any provider should be allowed to use additional extensions in their full entries.

Relationship to AtomPub

To allow such things as comments/reviews, OPDS could also support AtomPub.  With both the Atom Threading Extension and the current work on Collection Discovery, it should be fairly simple to support.

Tags: atom, AtomPub, opds

This entry was posted on Thursday, May 28th, 2009 at 1:55 pm and is filed under API. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.