georss

You are currently browsing articles tagged georss.

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: , , , , , ,

« Older entries