 |
 |
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 <[log in to unmask]> 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 >