Shared calendar syndication

The world is full of calendar publication systems. upcoming.org, evnt.org itself, evdb.com , [greg's thing]. Each of these sites becomes more useful the more it contains. While unable to share content, they 'compete', and this has negative consequences for users.

I was talking to douglas benford, the organiser of SPRAWL, (who has a sideline as the brilliant audio act si-cut{db}), about this. He belongs to several different music-events-news-syndication sites. Each time he puts on a new SPRAWL, he has to visit, and do the same data entry in, several different event sites. His reaction to EVNT was a sighing, "oh great, now i have *another* one i can't ignore".

What are the alternatives and the fixes? Here we can learn a bit by contemplating the Great Social Networking Fad of 2003.

First, there was Friendster. As it grew in popularity, some kind of scaling constraints led it to become unusably slow. Seeing the combination of popularity, targeting and the kind of 'stickiness' that comprise what i assume are advertisers' wet dreams, a horde rushed in to fulfil its purpose, or expanded their original remit to try to compete with it: Myspace, Tribe.net, Orkut, the business-focused precursors LinkedIn and Ecademy; and a lot of 'social-network-powered' sites offering specialist services, many of which died when the fad broke.

Around when Orkut started, was when i started hearing a lot of duplication complaints; "Now i have to go to yet another of these sites, and 'friend' everybody, and what is the point of it?"

The newer and smaller sites desperately wanted to provide ways to make it easy for their users to get their personal data out of one YASN and into another. A lot of them became very interested in FOAF - an RDF vocabulary which could express 'social network' information of the X-knows-Y,click-to-approve kind - and which could offer an easy transfer format, with actively-developed tools, between social network sites.

YASN criticisms. Privacy + exchange. Ultimate catch-22. It would be easy for any of the YASNs to *import* a FOAF profile - either a direct 'import the contents of this file', or an indirect 'import my profile from orkut'. But no-one was pioneering the even simpler *export* of userdata into FOAF profiles. Tribe got a long way on contemplating both, but never did. Any YASN that's trying to support itself commercially, would be foolish to go *first* in data openness, especially as faster or more interesting competitor software was always appearing, and at the next 'wave', their user base would just export their own data, and move on.

And added to the privacy concerns were now concerns about social network forwarding services. Sites appeared which, in return for your username and password on each site, would re-post a message to all your friends in each YASN. As this sort of service became more common, the privacy concerns for the YASN providers became even more pressing, provided even more negative impetus around open data -increasing the likelihood that FOAF-published userdata would be 'stolen' in bulk by third parties.

FOAF wasn't designed to solve these problems (bear with me, i'm getting back to the event calendaring bit.) FOAF was for 'machine-readable homepages', primarily; and a stress-testing ground for principles of larger scale semantic web based systems, secondarily. FOAF was useful for describing any properties of people and organisations in any context, as a mix-in vocabulary in a document using, say, Dublin Core or geo vocabularies.

Libby + Dan emphasising "own your own data". For the early adopters, that usually meant copying Edd Dumbill's FOAF file and hacking it up by hand, or generating one with Leigh Dodds' foafamatic, and putting it on one's own webserver. For the next generation, in involved having a FOAF file generated automatically as a byproduct of having an account on LiveJournal, or Ecademy, or Deanspace.

The failure of the YASNs to pursue a mutually-beneficial open data policy wasn't FOAF's fault, but FOAF did accrue some negative commentary for 'not solving security problems' and 'not providing reliable identity solutions'. But a lot of these problems *arose* because the YASNs wanted to be treated like islands. Without the need to centralise and therefore protect data in one place, these problems wouldn't have been so relevant and pressing.

HCal isn't solving these problems either, but it has two massive advantages: * it's a straight translation of a corporate standard that is fairly well accepted * users of shared calendar services want to share data, by definition * owners of shared calendar services are outputting at least some of 'their' data in RSS, by default So how does this long, rambly reflection help us consider, or solve, douglas's problem? Potential solutions:

• Leave things as they are. Event organisers will just have to visit six, or twelve or twenty different calendar syndication sites, and do the same data entry on each one.
• Build a reposting service like the YASN ones, where an individual organiser fills in their account details on loads of calendaring sites, and the service re-posts the event to all of them. Event organisers are busy people who value their time highly, and a trickle-charge of a dollar a pop to do this would probably get paid.
• Build aggregation services that collect data from a lot of different shared calendars and republish them.
  • either by export from Outlook, etc onto a webserver that they or their company own by export from plugins for existing blogging software ("calendars are the new blogs," i heard from one rather overexcited Foo Camp attendee.)
  • by going to a listings site and specifically adding an event there.

In theory an event site could exist purely as an aggregator, without even a HTML based interface; it would collect RSS (or whatever) feeds of HCal (or whatever) documents, and people, or bots would subscribe to its feeds, based on a spatial bounding box, or keywords, or a list of related people and organisations. But this presents problems in terms of people not being able to see the input interface, to contribute straight away.

People wanting to 'publish a document on the web' straight away. Wanting to get in into the search engines; wanting to advertise it to other people.

Let's steel ourselves and briefly contemplate the history FTP clients were quite easy for anyone with an MSOffice level of computer literacy to understand and use. Geocities did browser-based-upload of files you'd marked up yourself. The earlier 'blogging' software just helped you automatically mark up and style flat files, which you then FTP'd or rsync'd to your own website. Then blogging as-we-know-it took the whole thing to a 'hosted service' level, with all the potential for financial gain that service dependency incurs.

cAlendaring isn't the new blogging, it's the new thing that is built because blogging is built; no-one's arguing over the space any more. the skirmishes over syndication formats go on, partly *because* there's nothing better to skirmish about, only extensions and how best to implement them. Calendaring is the very-low-hanging fruit of that argument, and a viable standard (one that's very biased towards corporate/academic types of events, and can't express complex relationships, but that's what RDF is for)

i can't see the future; but i can attempt to make a decent extrapolation of it from the patterns of the past.