Raw

Dave Winer provides a scenario, he calls it the calendar feature to kill for :

I'm on Expedia, booking a trip. I add a car and a hotel. I click OK and it's all paid for. Now I go to my intinerary, and next to the link that emails me a copy is a button that adds all the relevant details to my calendar on Yahoo (or where ever).

This sounds in the first instance like a great use case for Live Clipboard, but also suggests a lot more. There is however one key point to get past, Dave adds :

Someday it will work like this but it will take a lot of cooperation to get there.

There's cooperation and there's cooperation. For want of a better way of putting it, the Web 1.0 way of doing this would be for Expedia and Yahoo to provide some wiring between their services. Cooperating directly with each other. The Web 2.0 way is for any individual company that wishes to maximise their benefit from the Web to add facilities to provide access to your data in an open fashion, following shared standards.

The immediate Live Clipboard application here would be for Expedia to provide a Copy to Clipboard icon, which the user of the service would click. On navigating to their Yahoo calendar, they'd click Paste from Clipboard at the appropriate point. At which point Yahoo could just eat the immediate data, and place it in the user's calendar. This would provide Dave's killer functionality, but there are more useful things that could be done in this scenario.

The least-effort extra would be for Yahoo to establish a reference back to a data source at Expedia. To put it in familiar terms, Yahoo would subscribe to Dave's calendar feed at Expedia.

But I think this is still special-casing unnecessarily. The data generated at Expedia when Dave books his trip could be useful with a whole bunch of other applications. If it's a place Dave hasn't visited before then maps might be useful, or restaurant reviews, or even other event calendars. If the data somehow stayed on Dave's clipboard until he next visited such sites it could provide him with further relevant info as an on-the-fly mashup.

In the easy Live Clipboard application, the information provided by Expedia would just be about places and times. But there's another hugely important aspect - the personal information. It's Dave doing the travelling. There's an actor involved. By pasting the data from the clipboard into his Yahoo calendar, Dave's effectively asserting I'm travelling. But that information could have been captured at source, in the Expedia booking. The significance is that with this information available, Dave won't have to explicitly tell all the 3rd party services about what he's doing, any such sites with which he's granted permission to use his data could potentially get the full picture.

Most of this kind of implementation scenario assume that the data would be only really be persisted at Expedia and Yahoo. This is fine, as long as the information is easily available later it's just an implementation detail. But I think it's helpful conceptually to imagine that all this data follows Dave around, it's in his personal knowledgebase. As it happens that's almost certainly advantageous in implementation terms, we do have running appllications that could carry this kind of information, the best example off the shelf right now probably being PiggyBank, and XmlArmyKnife is on its way.

These are RDF-based applications, which is almost a prerequisite for integrating the diverse kinds of data on the web with which we deal on a daily basis. But this most certainly isn't a prerequisite for Expedia and Yahoo in the scenario above. The current Live Clipboard approach of representing the data in XHTML (in this particular case you'd probably see hCalendar and hCard) is perfectly adequate, the source format is irrelevant as long as it's unambiguous. When it comes to combining stuff like this and building apps off it, RDF toolkits are no harder than any other technology (Elias is already mashing up their SPARQL Calendar demo with Google Calendar through hCalendar with the aid of Greasemonkey scripts).

In the short term, scenarios like the one Dave describes are absolutely doable. It's also possible for other people to work with the same standards as Expedia and Yahoo would be using in a Live Clipboard implementation to extend the functionality of the web. A little practical example here might be for the restaurant reviews brought up based on the Expedia to take into account Dave's dietary preferences. The datetime and location data could be used to gather a raw list of eating places (as appearing on the web using hReview), then info in Dave's FOAF profile could be used to filter it down to e.g. vegetarian-only.

Regarding the Big Picture, although this is talking about the Semantic Web, it should be noted that there's no ocean boiling here. Expedia make their data available in a good machine-readable format, Yahoo (or a third-party) provide facilities for reading the stuff into calendars. Completely unrelated developers can build apps to manipulate and/or integrate the data as RDF and/or persist it. All loosely-coupled, the overall development path being incremental.

Heh, I didn't comment on the bit in Dave's scenario where he mentions the email button at Expedia. But I just spotted an apposite quote (from Scott Dietzen of Zimbra) :

" ... cutting down the time users must spend on e-mail will be part of Web 2.0...".

PS. Rich Campoamor reminds me that he suggested pretty much the same things a few weeks ago in Give Me Back my Data. Worth suggesting again though ;-)

@en