LISTSERV mailing list manager LISTSERV 16.5

Help for CODE4LIB Archives


CODE4LIB Archives

CODE4LIB Archives


CODE4LIB@LISTS.CLIR.ORG


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Monospaced Font

LISTSERV Archives

LISTSERV Archives

CODE4LIB Home

CODE4LIB Home

CODE4LIB  December 2012

CODE4LIB December 2012

Subject:

Re: Library event systems and using your API talents for good

From:

Jonathan Rochkind <[log in to unmask]>

Reply-To:

Code for Libraries <[log in to unmask]>

Date:

Mon, 3 Dec 2012 11:18:55 -0500

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (155 lines)

On this thread in general, people may be interested in a previous
Code4Lib Journal article on using Google Calendars via it's API to embed
library "open hours" information on a website. (Sorry if this has
already been mentioned in this thread!)

http://journal.code4lib.org/articles/46

It occurs to me that such could also potentially be used for library
events, I'm thinking? You'd be essentially using Google Calendar for
it's UI for entering and managing events (and perhaps taking advantage
of it's iCal feed for end-users that want such?), while building your
own actual display UI, built on the Google Calendars API. It's be free,
would be one advantage.



On 12/2/2012 10:51 AM, Michael Schofield wrote:
> This will be brief and full of typos (on my phone during breakfast). I've only been with my current library for the last year, but they/we have been using an event calendar called Helios. It is cheap and working with it is similar to Wordpress. Since I've been here, we purchased Program Registration (an iii product). Our public and reference staff really didn't like using it (can't blame them), so we hacked-up Helios to be the front-end for our program registration backend (which only really matters IF an event requires actual registration).
>
> Anyway, just a simple plug for Helios if only because we found it to be super malleable. Also, the support from the main guy has been super. I think the URL is refreshmy.com, but I'm on my phone and that's from memory.
>
>
> Sent from my iPhone
>
> On Dec 2, 2012, at 10:35 AM, Tom Keays <[log in to unmask]> wrote:
>
>> 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
>>>
>
>

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

March 2024
February 2024
January 2024
December 2023
November 2023
October 2023
September 2023
August 2023
July 2023
June 2023
May 2023
April 2023
March 2023
February 2023
January 2023
December 2022
November 2022
October 2022
September 2022
August 2022
July 2022
June 2022
May 2022
April 2022
March 2022
February 2022
January 2022
December 2021
November 2021
October 2021
September 2021
August 2021
July 2021
June 2021
May 2021
April 2021
March 2021
February 2021
January 2021
December 2020
November 2020
October 2020
September 2020
August 2020
July 2020
June 2020
May 2020
April 2020
March 2020
February 2020
January 2020
December 2019
November 2019
October 2019
September 2019
August 2019
July 2019
June 2019
May 2019
April 2019
March 2019
February 2019
January 2019
December 2018
November 2018
October 2018
September 2018
August 2018
July 2018
June 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
October 2017
September 2017
August 2017
July 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
November 2016
October 2016
September 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
July 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
October 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
August 2011
July 2011
June 2011
May 2011
April 2011
March 2011
February 2011
January 2011
December 2010
November 2010
October 2010
September 2010
August 2010
July 2010
June 2010
May 2010
April 2010
March 2010
February 2010
January 2010
December 2009
November 2009
October 2009
September 2009
August 2009
July 2009
June 2009
May 2009
April 2009
March 2009
February 2009
January 2009
December 2008
November 2008
October 2008
September 2008
August 2008
July 2008
June 2008
May 2008
April 2008
March 2008
February 2008
January 2008
December 2007
November 2007
October 2007
September 2007
August 2007
July 2007
June 2007
May 2007
April 2007
March 2007
February 2007
January 2007
December 2006
November 2006
October 2006
September 2006
August 2006
July 2006
June 2006
May 2006
April 2006
March 2006
February 2006
January 2006
December 2005
November 2005
October 2005
September 2005
August 2005
July 2005
June 2005
May 2005
April 2005
March 2005
February 2005
January 2005
December 2004
November 2004
October 2004
September 2004
August 2004
July 2004
June 2004
May 2004
April 2004
March 2004
February 2004
January 2004
December 2003
November 2003

ATOM RSS1 RSS2



LISTS.CLIR.ORG

CataList Email List Search Powered by the LISTSERV Email List Manager