A Standard REST API for Public Broadcasting?

I am intrigured by Andy Carvin’s suggestion of forming an Election 2.0 Task Force where:

we must promote open standards for aggregating content – consistent tagging protocols at the station level, heavy use of RSS to pull content together, distributed content modules that can exist simultaneously on local and national websites, etc – to allow all us to mix and mashup these resources so they can surface at the local and national level.

Additionally, Craig Rosa‘s comment about microformats had me thinking… how does the taxononomy/lexicon for describing objects using microformats inform how we might structure a database of web resources? While I know PBCore is noble and vast and everything, it’s primary goal is to be used for digital asset management – not for web sites (please let me know if I am wrong in my thinking about this). Are there content management systems out there which use microformats as a naming standard for metadata right out of the box? And how would this help facilitate a consistent “tagging protocol?” Also, in looking for how we might do this, I wonder if RSS is only the tip of the iceberg. Does this also mean a standard API for searching (and retrieving) RSS… if so, does this imply a standard REST protocol for querying a station web site and getting information back? I did a quick search for “common api standard REST” and came up with this modest proposal: Atom Will Change the World which contains a sprinkling of all the best buzzwords: Atom, GeoRSS, Dublin Core, etc. etc. But what it also says is that Atom is not only a syndication format, it’s also a publishing protocol:

In case you are not familiar with Atom, the syndication format provides a standard format for saving blog content in XML and the publishing protocol provides a standard API for clients to read, create or update Atom documents stored on servers.

This article goes on to say:

By combining a simple data model, a standard data exchange format, easy extensibility and a common API and simple specifications, Atom offers a great foundation for building web services.

and that Atom

provides a foundation on which anyone can build. Its much easier to build a Web service by adding some custom content to an Atom feed than it is to create a new XML exchange format and API from scratch. Thus, I believe Atom will become the de facto way of building web services. The first place to look is to Web 2.0 sites. Many currently expose their data via proprietary web service APIs – I’ll wager over the coming year most will move to Atom.

Shoot! Should I, as a webmaster at a public radio station, be implementing Atom feeds and moving towards an ideal of a standard API? And is the API already out there? Should I be learning about the Atom publishing protocol?

Tags: , , , , , ,

  • From Jack Brighton at WILL – http://www.will.uiuc.edu/

    On your pondering of Atom, it seems like RSS on steroids to me, and
    could be very useful for sharing content in a structured, cohesive way.
    (I think you’re right about PBCore being better for digital asset
    management, especially as Content Depot and NGIS come on line, and with
    the MXF file format…)

    Seems like there are several or many ways to expose content and
    metadata, including RSS, Atom, etc. So the question might be: What are
    we trying to do or enable with content-sharing? If we can answer that,
    we might find it easier to zero in on the best solution.

    I’m not sure I know what everybody else in the public media system wants
    to do, so I’m trying to prepare WILL to participate in whatever solution
    eventually emerges. We’re trying to master the exposure of content and
    expression of metadata in whatever format might be useful. We can now
    produce full PBCore records, RSS, and Atom feeds direct from the content
    management system. We can express in any XML format desired, so if
    there’s a media microformat that emerges, we could probably speak that
    language pretty quickly. What you’re suggesting makes a great deal of
    sense to me, and I want to think about it some more.