There's a lot to say about EDL since I attended the meeting of Working Group 3 (which concerns users) last week. I haven't the time right now, but I should note that (a) I was quite taken aback by the way that my arguments for an API ended up sending the whole meeting onto a different track, about which I felt a little guilty, and (b) I am now clearer that an API is the essential thing, but that a portal site really does have a place, and that an API can help ensure that its potential is realised by opening up the possibility that third parties can build widgets etc to work within it, or integrate their applications with the portal. But a lot of the talk was like juggling jelly: so many things are not firrnly established, or at least weren't clear in that context (like data structure, or the location of the content vs the catalogue metadata), and it makes it rather tricky to keep all these unknowns in the air and have a sensible conversation. But it keeps me coming back to the point that concentrating on the functionality, not the user interface to it, is where EDL should expend its efforts.
On a very related tip, Andy Powell on eFoundations today mentions the "repository as platform" idea (http://efoundations.typepad.com/efoundations/2007/10/repository-as-p.html), in respect of recent ePrints developments. I haven't read a digested this lot properly yet but it's pretty much where I think EDL needs to be at too.
Finally, Google's latest endeavour finds them offering as a standard an API model for social networks, OpenSocial. Along with OpenID, we may find that this takes us a good way to standardisation. The next thing is for maps, perhaps. At present you can use libraries to negotiate the different APIs for the various providers, but a standard API would be better. More sustainability for all!
