Why Facebook isn't the best home for your public events

Facebook may not be great for event listings, but it could be a useful conduit.

In an earlier
of this series I discussed how Facebook events can flow through elmcity hubs by way of
Facebook’s search API. Last week I added another, and more direct,
method. Now you can use a Facebook iCalendar URL (the export
link at the bottom of Facebook’s Events page) to route your public
events through an elmcity hub.

The benefit, of course, is convenience. If you’re promoting a public
community event, Facebook is a great way to get the word out and keep
track of who’s coming. Ideally you should only have to write down the event
data once. If you can enter the data in Facebook and then syndicate it
elsewhere, that seems like a win.

In Syndicating
Facebook events
I explain how this can work. But I also
suggest that your Facebook account might not be the best
authoritative home for your public event data. Let’s consider why not.

Here’s a public event that I’m promoting:

Facebook public event

Here’s how it looks in a rendering of the Keene elmcity hub:

Rendering of the Keene elmcity hub

And here’s the link to the End of the world (again) event:


Did you click it? If so, one of two things happened. If you were
logged into Facebook you saw the event. If not you saw this:

Facebook login page

Is this a public event or not? It depends on what you mean by public.
In this case the event is public within Facebook but not available on the
open web. The restriction is problematic. Elmcity hubs are transparent
conduits, they reveal their sources, curators do their work out in the
open, and communities served by elmcity hubs can see how those hubs
are constituted. Quasi-public URLs like this one aren’t in the spirit
of the project.

My end-of-the-world event is obviously an illustrative joke. But
consider two other organizations whose events appear in that elmcity
screenshot: the Gilsum Church and the City of Keene. These
organizations are currently using Google Calendar to manage their
public events. They use Google Calendar’s widget to display events on
their websites, and they route Google Calendar’s iCalendar feeds
through the elmcity hub.

Now that elmcity can receive iCalendar feeds from Facebook, the church
and the city could use their Facebook accounts, instead of Google
Calendar, to manage their public events. Should they? I think not.
Public information should be really public, not just quasi-public.

What’s more, organizations should strive to own and control their
online identities (and associated data) to the extent they can. From
that perspective, using services like Google Calendar or Hotmail
Calendar are also problematic. But you have choices.
While it’s convenient to use the free services of Google Calendar or
Hotmail Calendar, and I recommend both, I regard them as training
wheels. An organization that cares about owning its identity and data,
as all ultimately should, can use any standard calendar system to
publish a feed to a URL served by a host that it pays and trusts,
using an Internet domain name that it paid for and owns.

Either way, how could an organization manage its public event stream
using standard calendar software while still tapping into Facebook’s
excellent social dynamics? Here’s what I’d like to see:

Example Facebook login page

It’s great that Facebook offers outbound iCalendar feeds. I’d also
like to see it accept inbound feeds. And that should work everywhere,
by the way, not just for Facebook and not just for calendar events.
Consider photos. I should be able to pay a service to archive and
manage my complete photo stream. If I choose to share some of those
photos on Facebook and others on Flickr, both should syndicate the
photos from my online archive using a standard feed protocol — say
Atom, or if richer type information is needed, OData.

The elmcity project is, above all, an invitation to explore what it
means to be
the authoritative source of your own data
. Among other
things, it means that we should expect services to be able to use our data
without owning our data. And that services should be able to acquire
our data not only by capturing our keystrokes, but also by syndicating
from URLs that we claim as our authoritative sources.

OSCON Data 2011, being held July 25-27 in Portland, Ore., is a gathering for developers who are hands-on, doing the systems work and evolving architectures and tools to manage data. (This event is co-located with OSCON.)

Save 20% on registration with the code OS11RAD


tags: , ,