The elmcity project thinks like the web, and invites users to do the same. Direct users of the elmcity service (hereafter just elmcity) are curators who run calendar syndication hubs. Indirect users are people who contribute calendar feeds that flow through the hubs. Everyone involved in this dance practices key principles of web thinking. Here are some ways:
| the principle | how it’s practiced by curators | how it’s practiced by contributors | |
|---|---|---|---|
| 1. | Be the authoritative source for your own data | Curators tell elmcity to get their hubs’ settings from an account on another service — the curator’s Delicious account. | Contributors use online calendars that they designate (Google Calendar, Hotmail Calendar, many others) to manage their events and send them to hubs. |
| 2. | Pass by reference not by value | Curators send hub settings and feed lists to elmcity by referring to Delicious URLs. | Contributors send feed data to elmcity by referring to feed URLs. |
| 3. | Know the difference between data that’s structured and information that isn’t. |
Curators use apps and services that support iCalendar, the structured Internet-standard data format for exchanging calendar information. Curators tweak hub settings by bookmarking a Delicious URL and adding structured (name=value) tags. |
Contributors also use apps and services that support the structured format iCalendar. Contributors also use structured tags — in their case, to send event metadata to elmcity. |
| 4. | Create and adopt shared naming conventions. | Curators can work with contributors to build tag vocabularies for classifying and grouping feeds and events. | Contributors, not coicidentally, can work with curators on the classifying and grouping. |
| 5. | Push your data to the widest appropriate scope. | Curators run community information systems, the world is a community now, so the appropriate scope is global. The merged calendar data is world-public by default. | Contributors to community information systems also use a world-public policy for the feeds they contribute to hubs. |
| 6. | Play in pub/sub networks as both a publisher and a subscriber. | Curators publish various flavors of data feeds from their hubs. They can also subscribe to feeds about their hubs: project news, development status, support forum discussion, | Contributors publish calendar feeds. They can also subscribe to a variety of calendar feeds published by family members, by work associates, and by community groups. |
| 7. | Reuse existing services. | Curators use Delicious for hub settings and feed lists, friendfeed for project collaboration, and many services to acquire event data (Eventful, Upcoming, Eventbrite, Facebook, various iCalendar apps/services). | Contributors choose from a variety of iCalendar apps and services. |
In these scenarios the elmcity service partners with a number of other services, most notably Delicious. During last December’s Delicious-is-going-away scare I compiled a list of essays I’ve written since 2004 about how and why Delicious is far more useful than the tagline “social bookmarking” might suggest. Here’s the gist: Delicious, more than any other online service I know, encourages and rewards the practice of web thinking. That makes it a natural partner of elmcity, a service that invites communities to think like the web.
There are, of course, other ways to manage hub settings and feed registries. Various social bookmarking services can do what Delicious does. More conventionally, the elmcity service could manage this data directly. I’ve always been prepared to swap out Delicious for something else, and when it looked like Delicious might go away I reviewed my options.
Then came news that Delicious had been acquired by YouTube’s founders and would continue as part of a new company called AVOS. The transition promises to be seamless. In order to continue using their existing accounts and data after July 2011, Delicious users need only opt in to the AVOS terms of service.
For typical users it’s all straightforward, though you’ll want to note that AVOS declines responsibility for backing up your contributed data. I’m glad to see that in writing. Too many people assume, wrongly, that the data they send to free cloud services, in order to socialize with other people and other people’s data, will be backed up. It’s the cloud, right? The cloud can back up your stuff, right? Yes it can, but don’t expect that to happen unless you’re paying for it.
The elmcity service isn’t a typical user of Delicious, though. It accesses Delicious programmatically, scanning curators’ bookmarks several times a day in order to check for updates to their hub settings and feed registries. That may not square with this item from the list of Things Not To Do in the AVOS terms of service:
Attempt to access or search the Service or Service Content or download Service Content from the Service through the use of any engine, software, tool, agent, device or mechanism (including spiders, robots, crawlers, data mining tools or the like) other than the software and/or search agents provided by AVOS or other generally available third party web browsers.
That’s quite a change from the comparable paragraph in the existing terms of service:
Delicious provides access to portions of Delicious via RSS feeds and an API; for the purposes of these Delicious Terms, such access constitutes use of Delicious. Delicious asks that you use these features respectfully, as outlined in the documentation.
Elmcity actually makes very little use of the Delicious API. But it relies heavily on the fact that for every HTML page that Delicious presents, there is a corresponding RSS feed. For example, curators add iCalendar feeds to their hub registries by bookmarking the URLs of those feeds, and tagging them in a certain way. As curator of the hub for Keene, NH, I review my hub’s registry using this Delicious query:
http://delicious.com/elmcity/trusted+ics+feed
When the elmcity service checks for updates to my registry, it uses the corresponding RSS feed:
http://feeds.delicious.com/v2/elmcity/trusted+ics+feed
That same feed serves another purpose. The elmcity support forum and project collaboration space is on FriendFeed. One of FriendFeed’s endearing features is ad-hoc RSS aggregation for groups. The elmcity group on FriendFeed compiles project status from a variety of RSS feeds, including Delicious feeds of the form shown above. What that means is that when any curator discovers a new iCalendar feed and adds it to his or her hub, everyone in the FriendFeed space is notified. It’s a wonderful example of how pub/sub networks can enable ambient awareness.
I hope that AVOS wants to celebrate, not forbid, this kind of emergent capability. But it does require accessing the service with tools and services other than “generally available third party web browsers.” I have always done this kind of access respectfully, and would like to continue on that basis. But if that won’t be acceptable I’ll make other arrangements. Either way I want to thank Delicious for many years of stalwart service and creative stimulation, and to thank AVOS for carrying on. I’m sending the Delicious/AVOS support team a link to this post, and I’ll use comments here to report what I find out.
I look forward to hearing their response, Jon. One would hope that the boilerplate in their ToS was some lawyer-speak that might even be updated based on your request for clarification. Fingers crossed!
Jon – I’d look into one of several services that draw lots of inspiration from delicious, but that aren’t delicious, and see if they would fit the technical and the TOS requirements. Some ex-Delicious people referred me to pinboard.in for instance which is a faithful reinvention of the wheel.