Pubcasting infrastructure chatter
Thursday, July 6, 2006
Tim Olson pulled me into an interesting exchange with the cellar rat and standards wizard Alan Baker, apropos of the digital distribution conversations:
From: Alan Baker
Subject: Re: pubcasting 2.0 infrastructure
Date: July 4, 2006 8:31:34 PM EDT
To: Jake Shapiro jake@prx.org
Yes it does seem that the time is right to get all the pieces spread out on the workbench to see which might plug together.
Several of these things I’m trying to do under the umbrella of existing projects. It might be stretching the boundaries of the original charter for those projects but ultimately they are funded to be successful, and the world is changing faster than you can get agreement to adjust scope.
Specifically as part of of the PBCore project, I’m charged with generating a working prototype of what was called a markup tool for PBCore records. My angle on this is that with the appropriate side effort we can roll RSS generation into the tool base, and thus provide a PBCore-compliant publishing mechanism for anyone who wants to use the free markup tool. (done right it might solve the batch ingest problem for PRSS, and thus can become a tool to help stations deliver content to the Depot, or, of course, PRX. It will assist these publishers most if they are publishing to multiple channels/partners.)
Good luck, I’ll try to keep up with the DDC work via the wiki. And I’m glad to weigh in as time allows. I think my flurry of holiday emailing will come back to bite me yet this week. And I should probably get started on the Friday podcast…
Alan
From: Jake Shapiro
Date: July 4, 2006 7:39:46 PM EDT
To: Alan Baker
CC: Tim Olson
Subject: Re: pubcasting 2.0 infrastructureThanks Alan, this is hugely helpful and comes at the right time.
Just yesterday I was quizzing Matt and Steve at PRX for their take on pushing the pbcore/psd/’public media forge’ work forward, given the limitations of efforts to date and the opportunity at hand with the Digital Distribution Consortium.
Our method so far with DDC is to take on the business level requirements, map out some fairly ambitious services that an ‘entity’ could provide, and then evaluate existing infrastructure and organizational capacity in the system to see where the gaps and opportunities lie. We’ll then make recommendations for next steps, operations, investments, etc.
So there’s clearly an opportunity for the path you propose here to sync up, in a way approaching the same problem from two sides.
In fact this could address one of the common pitfalls, where standards are created in a vacuum and don’t get applied, at the same time others develop applications without waiting around for standards, i.e. pbcore and podcasting.
Cheers,
Jake
From: Alan Baker
Date: July 4, 2006 3:42:17 PM EDT
To: “Tim Olson”, “Jake Shapiro”
Subject: RE: pubcasting 2.0 infrastructure
This is all rough draft, and wide open for edit/add.
I think a functional spec is a bigger project unless we tackle this right out of the gate as an initiative that will be charged with actually building something. But maybe you’re talking a higher level investigation than I’m thinking a functional spec might indicate. We could lay out our ideal production chain with a pretty good level of detail.
I was expecting this to be more of a survey of what tools are available, with gap analysis on how they fit into the content production delivery chain. We’d also define what we feel we need to provide the functionality we wish to provide for producers, and ultimately just what/how we deliver to the audience.
Project parts:
- Pull together a team which had the chops to evaluate existing tools with a definite bias towards open-source technology. This group would evaluate production tools, sharing mechanisms, content and asset management systems, various publishing methods/tools, and the standards that are behind them.
- Match that technical/functional analysis against desired current/future functionality
- Develop scenarios, including specific development to be done to tie best available tool sets together to solve the most pressing problems for producers, distribution partners and broadcasters.
Out of this project I would hope to fund some actual development with a consortium approach that would have some clout with vendors to encourage the production tool integration of our standards, and then build/modify some of these tools to be used by pubcasters.
Part of the problem with the standards development funded recently is that there is a definite end-date to the development, and each “standard” is then frozen with no real entity to shepherd it forward. I was thinking that we might even make a case that this is an appropriate structure to act as a steward for the various emerging standards that we hope to lean on to take us into the future.
Of course to do this right, we’d be trying to build something that give us pubcasters a definite advantage over the commercial outlets but the open source development, and drive to get the standards supported by vendors, might mean that we have to be drastically open, which some orgs might not agree to easily.
ab
