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.

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.
>>
>
>
>