 |
 |
Quoting Jonathan Rochkind <[log in to unmask]>: > I think the vast majority of libraries can make javascript-only > changes to their OPAC interfaces, which is all Dan's approach > requires. Even III libraries do that. So maybe what is needed is a very clear, step-by-step set of instructions on how to do this? And, of course, how to un-do it. Question: what happens when the script fails, e.g. when the OL API does not respond? How graceful is that failure? kc > > IF they have any programming staff at all with a bit of time and are > willing to do such hacks. That might be an 'if' that's not met. But > it's not a huge technical challenge. > > So that leaves the answers being: > a) get libraries to change their attitudes and realize that being a > library in the 21st century means having a bit of programming staff, > just like being a library in the 20th meant having a bit of > cataloging staff. > > OR > > b) Get vendors to include an IA/OL integration feature out of the > box. (Which only meets IA/OL and not the next thing you're going to > want to integrate too, of course). > > > Which of these is harder/less-likely to happen, left as a judgement > to the reader. > > If I were a vendor, I too would have that reluctance KAren mentions, > to rely on an external service that may not be stable (both in sense > of uptime and in sense of the API not changing without warning in > the future), from a third-party service I have no agreement with. > Perhaps if IA would sign service level contracts with vendors (with > or withotu payment from the vendor), that would make things > smoother. Where they promise not to change their API without X > amount of notice, and/or commit to certain uptime. Not sure that's > really feasible for IA though. > > Jonathan > > On 6/16/2011 11:44 AM, Karen Coyle wrote: >> Yes, I know about this, and I think this is great ... for Evergreen >> users. My concern is how we get it out there to the majority of >> libraries who aren't on an OS platform and/or cannot make changes >> to their UI. As I think your post demonstrates, what we need is to >> get through to the system vendors and get them to implement this >> kind of linking. I intend to chat up vendors in the exhibits at ALA >> to find out what this means to them. I suspect they are reluctant >> to rely on a system or feature that may not be stable or persistent >> (a reasonable reluctance when you have thousands of installations), >> so then the question becomes: how can this be made to work? >> >> kc >> >> Quoting Dan Scott <[log in to unmask]>: >> >>> (Apologies in advance if this looks like crap, I hate trying to >>> reply in context in GroupWise) >>> >>>>>> On Wed, Jun 15, 2011 at 10:55 AM, Karen Coyle <[log in to unmask]> wrote: >>>> Quoting Eric Hellman <[log in to unmask]>: >>>> >>>> >>>>> What are the reasons that this sort of integration not more >>>>> widespread? Are they technical or institutional? What can be done by >>>>> producers of open access content to make this work better and >>>>> easier? Are "unified" approaches being touted by vendors delivering >>>>> something really different? >>>> >>>> I've been struggling with this around the Open Library digital texts: >>>> how can we make them available to libraries through their catalogs? >>> >>> You're aware of the recent addition of the OpenLibrary Read API, >>> which is meant to simplify exactly this problem, right? >>> >>> The official announcement was at >>> http://blog.openlibrary.org/2011/06/03/announcing-a-new-read-api/ >>> ; http://ur1.ca/4g5bd describes how I integrated it into Evergreen >>> with a few hours' effort (mostly helping to debug the new >>> service); the official documentation is at >>> http://openlibrary.org/dev/docs/api/read and I augment those docs >>> in the latter half of the presentation I gave last week (available >>> in plain text, html, and epub formats at >>> http://bzr.coffeecode.net/2011_olita/ ). >>> >>>> When I look at the install documentation for Umlaut [1](I was actually >>>> hoping to find a "technical requirements" list), it's obvious that it >>>> takes developer chops. We're not going to find that in a small, >>>> medium, or often even a large public library. It seems to me that this >>>> kind of feature will not be widely available until it is included in >>>> ILS software, since that's what most libraries have. >>> >>> The OpenLibrary digital editions enhancement approach I took in >>> Evergreen was about 100 lines of JavaScript (around here: >>> http://ur1.ca/4g5cm ), most of which could probably be cloned >>> (under the GPL v2 or later) to any other library system from which >>> you can scrape ISBNs or other identifiers (LCCN, OCLC, or >>> OpenLibrary IDs). >>> >>> Note that the Evergreen-OpenLibrary integration hasn't been merged >>> yet, but the branch is there and will hopefully make its way into >>> core Evergreen soon. >>> >> >> >> > -- Karen Coyle [log in to unmask] http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet