Quoting Jonathan Rochkind <[email protected]>:
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 <[email protected]>:
(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 <[email protected]> wrote:
Quoting Eric Hellman <[email protected]>:
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
[email protected] http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet
