APIs are hot. They have been for years. An API is basically a way for an organization to expose some of its data to a clever (or not so clever) programmer to use as she wishes. The programmer reuses this data, puts it somewhere else, mixes it with something else, creates artwork out of it, whatever she wants.
She steals it.
For private companies, the thinking is: “The ubiquity of our products is good for business.”
For public companies, the thinking is: “The ubiquity of our information is good for the public.”
If the CBC’s video player is dying, why not release these videos to the public to see what they come up with? Why not let anyone remix CBC news reports as they see fit? Why not let them stream CBC radio where they want? Why not open the rich CBC archives to all Canadians?
What does it take to make an API? A little programming. Some thought towards how much (or how little) to make available. Most importantly what’s needed is a culture of openness and transparency. These programmers might come up with things you never expected. If you’re lucky.
I wonder if anyone at the CBC has given the idea much thought?
4 Comments
I’m glad somebody has brought up the point of api. Now is the time for an CBC Api. People are always about “What about Canadian Content”, blah blah. The cbc and associated website have a ton of great Canadian content, however 3rd party developers have a pain in the ass time of getting access to this content.. The Application “Boxee” is starting to make some big inroads on the media-pc market. They have there eyes set on a set top box. However, there is almost no canadian content for it? Why? Media players like Cbc don’t provide the pieces to let us mashup their content so we can develop apps for such platforms? Personally, I see cbc as public asset. There should be a public mandate of having an open API for the cbc so that Canadian can get there content how they want, when they want it.. The iphone app is a great example of it..
From a technical standpoint, you could build a layer over all the competing systems (in Eng and Fr!) that understood all the systems, and could deliver content via an API.
First step would be to get the API to work internally, so that CBC producers could pull any asset they needed for whatever project they were working on (eg: Radio clips into a news story). Next step would be releasing it to the public, probably in a truncated form.
you could build a layer over all the competing systems (in Eng and Fr!) that understood all the systems, and could deliver content via an API
Report back to us in a couple of Mythical Man Months and let us know how far you got with that!
Seriously, you’re right in what you say and that’s what will hopefully get done.
Or better yet, there could be guidelines and frameworks for how to output API-friendly XML **FROM** your cbc application.
I just know from some who have done it that making one CBC app talk to another is not to be embarked upon lightly, or without some voodoo and elbow grease and heavy-duty detective work.
Think how much time and money it took for the ugly caterpillar that was the CBC intranet to morph into the beautiful butterfly called io!
Sure, it’s been thought about by many.
Quite a few technical problems exist, but some of the problems are ‘cultural’ and of course, all the bugaboos around rights and ownership apply as well.
Myth: There is one all-encompassing CBC ‘digital archive’
There isn’t really a standardized ‘long-tail’ repository of CBC content for either radio or TV that has a unified data (or cataloguing) structure behind it. Instead, there’s a dog’s breakfast of archiving and documenting systems developed by or in conjunction with IT.
CBC, if you’re gonna be a ‘content’ company now is the time to develop a set of simple, forward-thinking standards about how to catalogue and label your content.
Luckily, you have a great resource in the existing radio and TV archives staff. Let *THEM show the techies how to taxonomize and meta-organize content. A lot of these practices and systems exist, but it needs to be collated, evaluated, then re-engineered.
Use the established common-sense of library science to come up with the standards, then roll with it. **DO NOT hire Tod Maffin to cook up some bullshit manifesto, or treat this as ‘business’ project that gets mired in the biz-nob morass of CBC.ca. And for god’s sakes, don’t hand it to IT! That said, these departments do need to be involved from the ground up.
There needs to be a high level ‘content charter’ developed, by people who know how to organize content (in the 20th century we called them ‘librarians’) in conjunction with developers and IT people who know how to make a system that taps into the well-organized content. Get our legal and rights people on board from the ground up, too. This charter could provide a solid foundation for developing an API.
Instead the process will likely end up being a business / revenue driven exercise in frustration. Come on you dopes – don’t you realize that if you are going to ‘un-silo’ the media lines and become a single ‘content’ line that you’ll need to ‘un-silo’ the repositories of all that content. Duh!
The end result will be self preservation of middle managers who don’t give a shit about the logic, imagination and best practices of archivists, developers, or IT people. And the end product will be some lame-ass semi-open-source, limited repository of our content, that comes with a zillion terms and conditions attached.