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