An information mapping puzzle

One of the core values of the elmcity project is respect for authoritative sources. Every event that syndicates into the system should have an URL that points back to that authoritative source.

Often, when the source is an iCalendar feed, some or all of the events leave the URL field empty. That’s why I encourage curators to provide a default URL for the whole calendar. For example, the newest city to join the hub is Falls Church, VA. One of the feeds that curator Dave Witzel created (using FuseCal) is for the Dogfish Head Ale House. As you can see in Dave’s metadata catalog, the bookmark he created for its calendar points to the URL of a FuseCal-created iCalendar feed. And one of the tags on that bookmark is:

url=http://www.dogfishalehouse.com/component/option,com_jcalpro/Itemid,70/

The url=http://… tag is how a curator tells the elmcity aggregator: “This is the default URL I want you to use, for any events in this feed that do not individually specify a URL.”

In this example, Dave has pointed the url= tag at the events page at the ale house, which is also the URL that he fed to FuseCal in order to get it to produce the iCalendar feed.

Let’s look at another example: the Thomas Jefferson Public School. Here, Google Calendar is the source of the iCalendar feed. And Dave has bookmarked the web page in which the school has embedded that calendar.

One place this default URL shows up is in the reference HTML view of the Falls Church calendar. On June 3, we see:

Wed 09:15 AM
7th Gr. Jazz Band Concert at TJ
(Thomas Jefferson Public School Calendar)

The link points back to the source. So far, so good.

Now, these source URLs should also propagate to any downstream services that syndicate from the hub. And in each of the outbound formats — XML, JSON, and ICS — they do. Here’s how that originally worked:

<event>
<title>7th Gr. Jazz Band Concert at TJ</title>
<url>http://www.fccps.org/calendar/tj.htm</url>
<source>Thomas Jefferson Public School Calendar</source>
<dtstart>2009-06-03T09:15:00</dtstart>
</event>

{
"title":"7th Gr. Jazz Band Concert at TJ",
"url":"http://www.fccps.org/calendar/tj.htm",
"source":"Thomas Jefferson Public School Calendar",
"dtstart":"\/Date(1244020500000+0000)\/"
}

BEGIN:VEVENT
DESCRIPTION:For more information regarding this or any other event please
 contact the MEH Main Office at 703-720-5700.
DTSTART:20090603T091500
URL:http://www.fccps.org/calendar/tj.htm
SUMMARY:7th Gr. Jazz Band Concert at TJ
UID:633778966573833700@elmcity.cloudapp.net
END:VEVENT

But this perfectly sensible mapping fails for iCalendar. It turns out that many popular calendar programs don’t surface the URL field in an iCalendar VEVENT. Apple’s iCal does, but Outlook, Google Calendar, and Live Calendar don’t.

What to do? Until somebody helps me find a better solution, here’s mine:

BEGIN:VEVENT
DESCRIPTION:For more information regarding this or any other event please
 contact the MEH Main Office at 703-720-5700.
DTSTART:20090603T091500
URL:http://www.fccps.org/calendar/tj.htm
LOCATION:http://www.fccps.org/calendar/tj.htm
SUMMARY:7th Gr. Jazz Band Concert at TJ
UID:633778966573833700@elmcity.cloudapp.net
END:VEVENT

In other words I’ve added a LOCATION field, which in this case was (not atypically) empty in the source calendar, and I’ve filled it with the same value that’s in the URL field.

The RFC2445 spec defines LOCATION like so:

Property Name: LOCATION

Purpose: The property defines the intended venue for the activity
defined by a calendar component.

And it gives this example:

LOCATION:Conference Room - F123, Bldg. 002

I’m stretching LOCATION to mean “virtual location of the source of information about the event” instead of “physical location of the venue for the event.”

Given that mapping, here’s how the 7th Gr. Jazz Band Concert shows up in various apps:

Notice how iCal renders both URLs — the one in the LOCATION field, and the one in the URL field — as clickable links. I wish the other programs also made an URL in the LOCATION field clickable. Reporting the source URL is better than not doing so. But the extra friction involved in copying the URL and pasting it into a browser will tend to prevent that from happening.

Given all this, I’d love to hear suggestions for a better approach. One thing to keep in mind is that I’m trying to strike a balance between two conflicting goals. I want to make the downstream syndication formats useful. But not too useful, because I also want to build a connected ecosystem that helps all the upstream sources — including Eventful, Upcoming, and growing populations of iCalendar feeds — thrive. The elmcity service doesn’t aim to be a container of other people’s stuff. It aims to be a router, or actually a whole bunch of routers, each of which helps bootstrap a connected ecosystem in which people become the authoritatives sources of their own information, and in which they learn to syndicate that information to one another.