USA 59717-3320
Ph: (406) 994-6429
[EMAIL PROTECTED]
-Original Message-
From: Code for Libraries [mailto:[EMAIL PROTECTED] On Behalf Of
Sebastian Hammer
Sent: Sunday, March 16, 2008 10:32 AM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] Free covers from Google
Is there any word on
Hooray for Google customer response !
It was not easy to find an appropriate response form on Google's web
site to complain about my problems using the Google Books API. I found a
form that was supposedly for authors and publishers wanting to advocate
their book on Google Books and used it. Google
08 12:57 PM
> To: CODE4LIB@LISTSERV.ND.EDU
> Subject: Re: [CODE4LIB] Free covers from Google
>
> > If you can find a public email address
> >anywhere or comment form, let us know.
>
> You can send a response to them here:
> http://www.google.com/support/librariancent
> If you can find a public email address
>anywhere or comment form, let us know.
You can send a response to them here:
http://www.google.com/support/librariancenter/bin/request.py
The form seems to be for librarians so maybe they'll understand the
issue and talk to people who may be able to make
lto:[EMAIL PROTECTED] On Behalf Of
Karen Coyle
Sent: dinsdag 18 maart 2008 1:16
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] Free covers from Google
I've seen this frequently in publisher data -- especially from small
publishers. Their metadata goes out with the same ISBN for every book
found on an incorrect isbn:0851992544
Peter
-Original Message-
From: Code for Libraries [mailto:[EMAIL PROTECTED] On Behalf Of
Karen Coyle
Sent: dinsdag 18 maart 2008 1:16
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] Free covers from Google
I've seen this frequently in publisher
I've seen this frequently in publisher data -- especially from small
publishers. Their metadata goes out with the same ISBN for every book
they publish. I don't know if this gets corrected later (I assume it
does to make the ordering process work). My guess is that they send out
the first metadata
At 02:55 PM 3/17/2008, you wrote:
My general philosophy is still always to put as _little_ Javascript as
possible. Thus my way-too-clever idea to have some javascript which
actually sends the Google (or similar) API response back to my server
via AJAX for _real_ processing. :)
But if you DO want
Hmm, just found an example where Google clearly does something wrong:
Look at: http://library.wur.nl/WebQuery/catalog/lang/948125
It shows a cover and links to the wrong book !!!
The look up is based on isbn 0851992544, but this book has got isbn 0851993575
and this is also clearly stated in the
er the environment before printing this e-mail
Van: Code for Libraries namens Jonathan Rochkind
Verzonden: ma 17-3-2008 21:05
Aan: CODE4LIB@LISTSERV.ND.EDU
Onderwerp: Re: [CODE4LIB] Free covers from Google
Interesting that these problems arise even when using the
ry.wur.nl/>
P Please consider the environment before printing this e-mail
Van: Code for Libraries namens Godmar Back
Verzonden: ma 17-3-2008 16:21
Aan: CODE4LIB@LISTSERV.ND.EDU
Onderwerp: Re: [CODE4LIB] Free covers from Google
On Mon, Mar 17, 2008 at 11:13
environment before printing this e-mail
Van: Code for Libraries namens Godmar Back
Verzonden: ma 17-3-2008 16:21
Aan: CODE4LIB@LISTSERV.ND.EDU
Onderwerp: Re: [CODE4LIB] Free covers from Google
On Mon, Mar 17, 2008 at 11:13 AM, Tim Spalding <[EMAIL PRO
JavaScript as a language has a number of severe limitations regarding
name spaces, dependencies, etc., but well-written, object-oriented
JavaScript as that you'd produce when you build an application using a
library such as prototype actually isn't too bad and (I believe)
provides reasonably good s
My general philosophy is still always to put as _little_ Javascript as
possible. Thus my way-too-clever idea to have some javascript which
actually sends the Google (or similar) API response back to my server
via AJAX for _real_ processing. :)
But if you DO want or need to do javascript-heavy stu
On Mon, 17 Mar 2008, Jonathan Rochkind wrote:
Of course, all these things _can_ be done with only client-side
javascript API. To my perspective, it is quite a bit more complex to do
it that way. And complexity is the enemy of maintainability, especially
in my limited staff resources library envi
Actually, thinking about this more, I just came up with a way too clever
method to get my availability checking component (which is actually
Umlaut) to deal with client-side-required APIs. Involving a (re-useable)
hidden div that makes the js API calls, gets the responses back, and
then sends thos
Of course, all these things _can_ be done with only client-side
javascript API. To my perspective, it is quite a bit more complex to do
it that way. And complexity is the enemy of maintainability, especially
in my limited staff resources library environment.
But perhaps my perspective is not suff
On Mon, Mar 17, 2008 at 10:41 AM, Jonathan Rochkind <[EMAIL PROTECTED]> wrote:
> Well, the SFX architecture has a feature called "display logic" that
> let's you on the server side determine how the menu will display based
> on what services are available. This is more obviously relevant to
> "d
You can, of course, mix the two approaches—get once browser-side, tell
your servers what it said and store that for a while. We do something
like that with Amazon covers. We don't store the covers, but we store
*whether* Amazon has the cover. That way, it can know whether to try
Amazon or not, and
Well, the SFX architecture has a feature called "display logic" that
let's you on the server side determine how the menu will display based
on what services are available. This is more obviously relevant to
"digitized text availability" from Google Books than just cover images.
You might want to s
I was thinking of both covers and 'digitized text availability'.
But the reason I want to in fact do both server side is because of the
architecture I am trying to create here. We have a variety of systems
that should use both these services. We, like many people, are trying to
move to a more 'se
Original message
>Date: Mon, 17 Mar 2008 11:13:58 -0400
>From: Tim Spalding <[EMAIL PROTECTED]>
>Subject: Re: [CODE4LIB] Free covers from Google
>To: CODE4LIB@LISTSERV.ND.EDU
>
>> limits. I don't think it's a strict hits-per-day, I think it's he
On Mon, Mar 17, 2008 at 11:13 AM, Tim Spalding <[EMAIL PROTECTED]> wrote:
> > limits. I don't think it's a strict hits-per-day, I think it's heuristic
> > software meant to stop exactly what we'd be trying to do, server-side
> > machine-based access.
>
> Aren't we still talking about covers?
Although I completely agree that server-side queryability is something
we should ask from Google, I'd like to follow up on:
On Mon, Mar 17, 2008 at 11:06 AM, Jonathan Rochkind <[EMAIL PROTECTED]> wrote:
> The
> architecture of SFX would make it hard to implement Google Books API
> access as pure
> limits. I don't think it's a strict hits-per-day, I think it's heuristic
> software meant to stop exactly what we'd be trying to do, server-side
> machine-based access.
Aren't we still talking about covers? I see *no* reason to go
server-side on that. Browser-side gets you what you want—cover
This is what I'm worried about too.
The API is _intended_ to be used as a client-side javascript.
_Technically_ it's of course possible to use it on the server side too.
But I am worried that this will run up against un-advertised Google rate
limits. I don't think it's a strict hits-per-day, I th
-Original Message-
From: Code for Libraries [mailto:[EMAIL PROTECTED] On Behalf Of
Godmar Back
Sent: Monday, March 17, 2008 9:09 AM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] Free covers from Google
FWIW, realize that this is client-side mashup. Google will see
individual req
FWIW, realize that this is client-side mashup. Google will see
individual requests from individual IP addresses from everybody
viewing your page. For each IP address from which it sees requests
it'll decide whether to block or not. It'll block if it thinks you're
harvesting their data.
Wageningen
As i wrote earlier, I have implemented a link using the Google API in
our library catalog.
It worked . for a while :)
What we notice now is, that Google responds with an error message. It
thinks that it has detected spyware or some virus.
i see the same effect now when I click on the examples
http://library.wur.nl
P Please consider the environment before printing this e-mail
-Oorspronkelijk bericht-
Van: Code for Libraries namens Tim Spalding
Verzonden: za 15-3-2008 7:04
Aan: CODE4LIB@LISTSERV.ND.EDU
Onderwerp: [CODE4LIB] Free covers from Google
(Apologies for cross
Is there any word on a limit to the number of hits per day on the Google
API? I missed it in the docs if it's there, only saw an ominous warning
that you might see the service temporarily disabled if you generated an
'unusually high number of hits' during development.
--Seb
Joe Atzberger wrote:
Impressive! As luck would have it, I'm working on the question of book
images in Koha this week...
--joe atzberger
On Sat, Mar 15, 2008 at 3:14 AM, Godmar Back <[EMAIL PROTECTED]> wrote:
> Hi Tim,
>
> I think this proposal suffers from the same shortcoming as
> LibraryThing's widgets, which is t
Oh yes, you're right. My point was to illustrate the point with a
small piece of code, not to write the perfect implementation. Multiple
covers is one improvement you'd want.
I think the main problem is getting the identifiers off of the OPAC
and putting them back in the page where they're useful.
Hi Tim,
I think this proposal suffers from the same shortcoming as
LibraryThing's widgets, which is that only one per page is allowed. A
better way may be to use spans and classes and keep the JavaScript in
a library.
I've attached the resulting HTML below; see http://libx.org/gbs/ for a demo.
-
(Apologies for cross-posting)
I just posted a simple way to get free book covers into your OPAC. It
uses the new Google Book Search API.
http://www.librarything.com/thingology/2008/03/free-covers-for-your-library-from.php
I think Google has as much cover coverage as anyone. The API is free.
Most
35 matches
Mail list logo
