Most of the interesting work in this area is actually coming from the top-down, that is the enterprise, since they are pushing forth real requirements to integrate disparate data sources.

On the workflow side of it is the BEPL standard which provides much of the orchestration and resolution of interoperable components. BEPL process engines are emerging as heavy new pieces of middleware (I've used the Collaxa Server)

But thats the backend side. The front-end, content driven side has adopted the terminology (and metaphor) of aggregating "portlets" into a larger Portal solution. The WSRP standard specifies how to provide presentation-oriented web services not just functional APIs.

The part about making data portable misses the point. The location of the actual data should be opaque. When you talk about moving data (e.g. photos) from one place to another (e.g. buzznet to flickr) you're really talking about changing your interface not the photos. In this sense, Flickr is an interface provider (e.g. make album, show album) and of rules about how it interoperates with other systems. If you have the right methods then you should be able to do this

Working towards stability with a popular site can be fun and educational.

It can also feel a bit like getting tomatoes thrown at you, while on stage, in the middle of a song, with the knowledge that one hundred trucks of free tomatoes just pulled up behind the crowd.

Oh, and you're chained to the stage.

it's not just about the ability to move your data to a better service, it is about the ability to distribute your data of a series of different services ~ each with varying strengths and weaknesses.

so even if flickr is, say, a BAZILLION times better {overall} than any other service, it will still be useful to have the ability to export all of one's images ~ for a slew of different reasons.