I've been disappointed by event management/calendaring systems in general.
I think there are a number of common needs that libraries all share.
Calendar systems -- scheduling single instance or repeating instance events
seems to be the one thing you can find in a system. Basic
metadata/filtering parameters should (and usually do) include: date, time,
location, description. There's variation in how rich this metadata is; some
include permutations on address, campus information, mapping options, etc.;
some include html options for the description, such as allowing links or
images.
Event registration -- an added feature is the ability to allow users to
register for an event and for event organizers to process that data. You
don't want to have to maintain a separate registration system. Outside the
scope of LibraryThing's Event API, except possibly to replicate
registration links so users can sign up from within LT.
Syndication -- Jon Udell spent much of 2009 and 2010 documenting his
efforts to find and then build a calendaring system that would aggregate
existing sources of calendar data, the goal being reuse rather than
replication. [1] His specific objective was to create a shared community
calendar [2] and along the way, he explored the limitations of RSS and iCal
data. Once such data was captured by a calendar aggregator, it could then
be resyndicated, giving users a single source for the entire community.
(Udell has been less public since 2010, so I lost track of where this has
been going.)
[1] http://radar.oreilly.com/2010/08/lessons-learned-building-the-e.html
[2] http://elmcity.cloudapp.net/
Embedded calendar data -- Also related to syndication is the idea of
including calendar metadata in a format on a web page that can be indexed
by search engines and directly consumed by users via browser plugins and
the like. The hCalendar microformat [3] was an attempt to embed iCal
calendar data into event listings. When RDFa had its brief accendency a
couple of years ago, it looked like hCalendar might be merge into it or be
replaced my similar systems, such as Schema.org's Event property [4].
However, now it looks like HTML5 <time> attribute might edge out Schema.org
and hCalendar. Unfortunately, it seems to be impossible to encode hCalendar
microformats as HTML5 microdata.
[3] http://microformats.org/wiki/hcalendar
[4] http://schema.org/Event
[5] http://html5doctor.com/the-time-element/
Ongoing events -- much of library event data doesn't fit neatly into
regular calendar systems. Whereas calendaring systems only seem to be good
at scheduling events with a specified time and date of occurence, I'd also
like to see calendar system that can handle scheduling of events that are
ongoing -- e.g., exhibits, art shows, library week announcements, etc. A
defining feature of a good event system would the ability to schedule both
the publication and expiration dates of the event, along with a mechanism
to archive expired events. From the public's point of view, an ongoing
event would appear once on the calendar -- i.e., as a single event spanning
several days rather than as a series individual listings strung over the
course of several days or weeks. On a day calendar, it would show as an
all-day event or announcement. On a week or month calendar, it might be a
bar spanning the days or weeks for which it was in effect.
My observation has been that whenever libraries have to maintain separate
calendar and event systems, that the calendar system eventually begins to
be missed as new events are added, to the point where it becomes
unreliable. As Tim observed in his post, if a system is not reporting event
information, it becomes much less useful. I wouldn't be surprised if
something like what I've just described is not ultimately impacting how
well LibraryThing's Event API is able to pick up local event data. If a
library marginalizes their calendar (intentionally or otherwise), it simply
won't be available to LT.
Alright. Sort of meandering and beyond the scope of Tim's original email,
but I thought it was worthwhile getting a few more use cases out there.
Udell's aggregation approach, for instance, might be more effective for
capturing discrete event data.
My 2c
Tom
On Thu, Nov 29, 2012 at 12:23 PM, Tim Spalding <t...@librarything.com> wrote:
Dear Code4Lib-ers (and apologies for a semi-crosspost to Web4Lib):
## Request:
I'm trying to get a global view of library event systems—a part of library
technology I've never really looked at. I wonder if anyone here could give
me a leg up?
* Who are the top competitors?
* Are they local- or cloud-based?
* What sort of outputs to they present?
* Has anyone worked with this data—moving it to other calendar systems,
etc.?
Thanks for any help!
## Background:
LibraryThing has decided to expand our "LibraryThing Local" system (
http://www.librarything.com/local ), starting with our events coverage, by
scraping and other parsing. So far we're processing data from all of the
"Big Six" publishers, a bunch of smaller publishers, Barnes and Noble,
IndieBound, Waterstones, Powell's, etc. Members have also been adding
events—we've got more than 10,000 events coming up in the next few months.
This is the worst time of the year for events, so that's a lot.
But we're missing libraries, except what members have been adding. Many of
the big city libraries have fans adding all the events by hand, but it's a
drop in the bucket.
## Use your API skills for good?
If you're interested in adding your library's events to LibraryThing,
LibraryThing is giving money to charity for every event added, manually
through a new event-adding API.
See the blog post:
http://www.librarything.com/blogs/librarything/2012/11/add-events-to-librarything-local-and-give-books-to-needy-readers/
Best,
Tim Spalding
LibraryThing
--
Check out my library at http://www.librarything.com/profile/timspalding
