Re: [CODE4LIB] Free covers from Google

[Boheemen, Peter van]

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 Godmar and Tim
created.
When I go to Google books directly with my browser now, I get the same
message and get the request to enter a non machine readable
string and then I can go on. My API calls however, still fail.
This has probably got to do with the fact that anybody who is accessing
Google from the university campus exposes the same IP adress to Google.
This is probably a trigger for Google to respond with this error.
Does anybody have any ideas about what to do about this, before I try to
get in touch with Google?

Peter van Boheemen
Wageningen University and Research Library
The Netherlands

Re: [CODE4LIB] Free covers from Google

[Godmar Back]

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 University owns the 137.224/16 network, so I find it
doubtful that you're all sharing the same IP address. It's probably
just your desktop IP address (or, if you're behind a NAT device, the
address used by that device - but that's probably only a small group
of computers.)

That makes it even more concerning that Google's defenses could be
triggered by your development and testing activities. Do complain
about it to them. (I doubt they change their logic, but you can try.)

I've received the CAPTCHA from Google in the past a few times if I use
it as a calculator. Enter more than a dozen or so expressions, and it
thinks I'm a computer who needs help from Google to compute simple
things such as english-to-metric conversions.

I think that's a huge drawback, actually. How does Amazon's image
service work? Does it suffer from the same issue?

 - Godmar

On Mon, Mar 17, 2008 at 4:50 AM, Boheemen, Peter van
<[EMAIL PROTECTED]> wrote:
> 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 Godmar and Tim
>  created.
>  When I go to Google books directly with my browser now, I get the same
>  message and get the request to enter a non machine readable
>  string and then I can go on. My API calls however, still fail.
>  This has probably got to do with the fact that anybody who is accessing
>  Google from the university campus exposes the same IP adress to Google.
>  This is probably a trigger for Google to respond with this error.
>  Does anybody have any ideas about what to do about this, before I try to
>  get in touch with Google?
>

>  Peter van Boheemen
>
> Wageningen University and Research Library
>  The Netherlands
>

Re: [CODE4LIB] Free covers from Google

[Riesner, Giles]

Given this latest information, I'd be rather hesitant to even try using
Google's images as our
network traffic is all NAT'ed and  all student traffic from  a campus
goes out one ONE NAT address
and ALL staff traffic on another (in our case x.x.x.204 and x.x.x.205).

We currently use Amazon's images with a link back to them and have no
problem with this.


Giles W. Riesner Jr.
Library Tech Support & Library System Manager
Community College of Baltimore Co.- Catonsville
800 S. Rolling Road
Baltimore, MD 21228  USA
Phone: 1-410-455-4245
Email:  [EMAIL PROTECTED]




-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 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 University owns the 137.224/16 network, so I find it
doubtful that you're all sharing the same IP address. It's probably
just your desktop IP address (or, if you're behind a NAT device, the
address used by that device - but that's probably only a small group
of computers.)

That makes it even more concerning that Google's defenses could be
triggered by your development and testing activities. Do complain
about it to them. (I doubt they change their logic, but you can try.)

I've received the CAPTCHA from Google in the past a few times if I use
it as a calculator. Enter more than a dozen or so expressions, and it
thinks I'm a computer who needs help from Google to compute simple
things such as english-to-metric conversions.

I think that's a huge drawback, actually. How does Amazon's image
service work? Does it suffer from the same issue?

 - Godmar

On Mon, Mar 17, 2008 at 4:50 AM, Boheemen, Peter van
<[EMAIL PROTECTED]> wrote:
> 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 Godmar and Tim
>  created.
>  When I go to Google books directly with my browser now, I get the
same
>  message and get the request to enter a non machine readable
>  string and then I can go on. My API calls however, still fail.
>  This has probably got to do with the fact that anybody who is
accessing
>  Google from the university campus exposes the same IP adress to
Google.
>  This is probably a trigger for Google to respond with this error.
>  Does anybody have any ideas about what to do about this, before I try
to
>  get in touch with Google?
>

>  Peter van Boheemen
>
> Wageningen University and Research Library
>  The Netherlands
>


--
BEGIN-ANTISPAM-VOTING-LINKS
--

Teach CanIt if this mail (ID 35790824) is spam:
Spam:
https://ssl.ccbcmd.edu:7726/canit/b.php?i=35790824&m=293b60dcf36b&c=s
Not spam:
https://ssl.ccbcmd.edu:7726/canit/b.php?i=35790824&m=293b60dcf36b&c=n
Forget vote:
https://ssl.ccbcmd.edu:7726/canit/b.php?i=35790824&m=293b60dcf36b&c=f
--
END-ANTISPAM-VOTING-LINKS

Re: [CODE4LIB] Free covers from Google

[Tim Spalding]

>  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—covers from
Google—without the risk they'll shut you down over overuse.

T

Re: [CODE4LIB] Free covers from Google

[Godmar Back]

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 purely client javascript, without losing full integration with
>  SFX on par with other 'services' used by SFX.  We will see what happens.
>

Could you elaborate? Do you mean 'hard' or 'impossible'?

Meanwhile, I've extended the google book classes (libx.org/gbs ) to
provide more flexibility; it now supports these classes:

gbs-thumbnail Include an  embedding the thumbnail image
gbs-link-to-preview Wrap span in link to preview at GBS
gbs-link-to-info Wrap span in link to info page at GBS
gbs-link-to-thumbnail Wrap span in link to thumbnail at GBS
gbs-if-noview Keep this span only if GBS reports that book's
viewability is 'noview'
gbs-if-partial-or-full Keep this span only if GBS reports that book's
viewability is at least 'partial'
gbs-if-partial Keep this span only if GBS reports that book's
viewability is 'partial'
gbs-if-full Keep this span only if GBS reports that book's viewability is 'full'
gbs-remove-on-failure Remove this span if GBS doesn't return bookInfo
for this item

 - Godmar

Re: [CODE4LIB] Free covers from Google

[Godmar Back]

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? I see *no* reason to go
>  server-side on that. Browser-side gets you what you want—covers from
>  Google—without the risk they'll shut you down over overuse.
>

But Peter's experience says otherwise, no?
His computer was shut down during development - I don't see how Google
would tell his use from the use of someone doing research using a
library catalog. Especially if NAT is used with a substantial number
of users as in Giles's use case.

 - Godmar

Re: [CODE4LIB] Free covers from Google

[Jonathan Gorman]

 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 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—covers from
>Google—without the risk they'll shut you down over overuse.


I could see one reason to do cover images server-side.  Say a library has a 
"new titles" list.  These books (and hence the images) are going to be the same 
for quite a while.  It might make sense to try to optimize it by downloading 
said images once and caching it on a local server.  Otherwise every time 
someone hits the new titles list they'll have to wait for Google to respond.  
Not sure how much of an advantage it really would be to host it server side.

Jon Gorman

Re: [CODE4LIB] Free covers from Google

[Jonathan Rochkind]

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 think it's heuristic
software meant to stop exactly what we'd be trying to do, server-side
machine-based access.

When I emailed Google to ask about this, all I got back was a statement
that this is only supported for client side Javascript access.  I doubt
that users using software with this kind of in-browser Javascript access
enabled will run up against any problems with rate limiting. But I think
if we try to do it server side, we very well might.

Of course, there are many kinds of functions that are difficult or
impossible to do solely client side, especially integrating with
existing software.  So this is a concern.

Interestingly, the Ex Libris SFX software demoing integration with
Google Books---as far as I can tell makes the API calls server-side!
Someone from Ex Libris confirmed to me that they have no special deal or
communications with Google. I think they didn't neccesarily realize they
might run into Google rate limiting (or even terms of service
violation?) issues. It will be interesting to see if they do or not. The
architecture of SFX would make it hard to implement Google Books API
access as purely client javascript, without losing full integration with
SFX on par with other 'services' used by SFX.  We will see what happens.

Google's _stated_ (to me, in email; I got one reply, but couldn't get
them to reply to my followup) reason for only allowing client-side
access is that availability may depend on location, and they need to
know the end user's location (via IP address) to get accurate
availability for that particular end user. This could of course be
easily solved if the API URL format allowed the calling client to pass
on the end-user's IP address in the URL (&client_ip=x.x.x.x or what have
you).  But I don't believe the Google Books API currently supports this.
I suspect that Google may have other "business model" reasons. Not sure.

Jonathan

Sebastian Hammer wrote:

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 that only one per page is allowed. Aj
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.

 - Godmar

--- index.html:
!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">


http://libx.org/gbs/gbsclasses.js";
type="text/javascript"> 
Simple Demo for Google Book Classes



 
 
 

 
 
 
 



On Sat, Mar 15, 2008 at 2:04 AM, Tim Spalding <[EMAIL PROTECTED]>
wrote:


(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 libraries pay. I'm thinking this is a big deal?

 We'll probably fancy it up a bit as an add-on to our LibraryThing for
 Libraries service, but the core idea can be implemented by anyone.

 I look forward to refinements.

 Tim

 --
 Check out my library at
http://www.librarything.com/profile/timspalding







--
Sebastian Hammer, Index Data
[EMAIL PROTECTED]   www.indexdata.com
Ph: (603) 209-6853 Fax: (866) 383-4485



--
Jonathan Rochkind
Digital Services Software Engineer
The Sheridan Libraries
Johns Hopkins University
410.516.8886
rochkind (at) jhu.edu

Re: [CODE4LIB] Free covers from Google

[Jonathan Rochkind]

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 suppress ILL links if there is digitized text (in
fact, you probably wouldn't in that particular case, but that gives you
the idea of what things you might want to do. At least my library
wouldn't, maybe others with especially small ILL budgets might).  Or
just give a pre-ILL warning message ("are you sure the Google text isn't
sufficient?), that might be more realistic.

Anyway, you obviously couldn't do this using the existing SFX display
logic feature if the Google Books info is only client side.
Now, "impossible?"  In the world of software development, few things are
actually impossible. You could try to duplicate that feature using only
client-side Javascript hiding and showing various DIVs.  The SFX HTML
currently isn't that clean, it woudl be hard. But you have the
capability to customize the SFX HTML however you want to. (And your
customizations will likely break with a future SFX release).   So
nothings impossible, but I wouldn't want to go down that road.

Jonathan

Godmar Back wrote:

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 purely client javascript, without losing full integration with
 SFX on par with other 'services' used by SFX.  We will see what happens.




Could you elaborate? Do you mean 'hard' or 'impossible'?

Meanwhile, I've extended the google book classes (libx.org/gbs ) to
provide more flexibility; it now supports these classes:

gbs-thumbnail Include an  embedding the thumbnail image
gbs-link-to-preview Wrap span in link to preview at GBS
gbs-link-to-info Wrap span in link to info page at GBS
gbs-link-to-thumbnail Wrap span in link to thumbnail at GBS
gbs-if-noview Keep this span only if GBS reports that book's
viewability is 'noview'
gbs-if-partial-or-full Keep this span only if GBS reports that book's
viewability is at least 'partial'
gbs-if-partial Keep this span only if GBS reports that book's
viewability is 'partial'
gbs-if-full Keep this span only if GBS reports that book's viewability is 'full'
gbs-remove-on-failure Remove this span if GBS doesn't return bookInfo
for this item

 - Godmar




--
Jonathan Rochkind
Digital Services Software Engineer
The Sheridan Libraries
Johns Hopkins University
410.516.8886
rochkind (at) jhu.edu

Re: [CODE4LIB] Free covers from Google

[Tim Spalding]

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 whether to fall back on another cover.

T

On 3/17/08, Jonathan Rochkind <[EMAIL PROTECTED]> wrote:
> 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 'service oriented' type architecture, where I have one
>  component of software that does all of these lookups, and then provides
>  the resulting data in a uniform format via a local web service for all
>  my other user-facing interfaces to use. Of course, doing that requires a
>  server-side lookup. But that overall architecture is much preferable
>  (from a code efficiency and maintenance perspective)  than having to
>  include customized AJAX for a variety of services (Google Scholar being
>  just one; Scopus is another content-provider that frustratingly provides
>  an Javascript-only API) in a variety of ever-changing user-facing
>  interfaces. DRY and all.
>
>
>  Jonathan
>
>
>  Tim Spalding 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? I see *no* reason to go
>  > server-side on that. Browser-side gets you what you want—covers from
>  > Google—without the risk they'll shut you down over overuse.
>  >
>  > T
>  >
>  >
>
>
> --
>  Jonathan Rochkind
>  Digital Services Software Engineer
>  The Sheridan Libraries
>  Johns Hopkins University
>  410.516.8886
>  rochkind (at) jhu.edu
>


--
Check out my library at http://www.librarything.com/profile/timspalding

[CODE4LIB] Fwd: MIT OpenCourseWare Executive Director

[Mark Matienzo]

The Massachusetts Institute of Technology seeks an Executive Director to
lead its highly successful and pioneering endeavor, OpenCourseWare, in
the next phase of its development.

Launched in the spring of 2001 with over $30 million of gifts and
foundation grants, OCW publishes the educational materials from all MIT
undergraduate and graduate courses on the Web for worldwide use, free
and open to anyone. Over the past six years, OpenCourseWare has become
one of MIT's most important global outreach activities, with over a
million visitors each month - more than two million if one includes the
affiliated sites around the world that host OCW mirrors and
translations.  Within MIT, OpenCourseWare is evolving to become a major
pillar of the university*s educational technology infrastructure,
providing students, faculty, and alumni with a shared, comprehensive
collection of the Institute's resources, together with services that
rely on this collection.  Beyond MIT, OpenCourseWare has become
emblematic of the burgeoning movement for Open Educational Resources,
which sees in modern communications technology and the Worldwide Web the
opportunity for the whole of humanity to share, use, and reuse
knowledge.

In November 2007, OCW met its initial goal to publish educational
materials representing all 1800 MIT subjects.  MIT is now seeking an
extraordinary leader to create even greater value and broader impact
through the OCW initiative.  Reporting to the Office of the Provost, and
with the assistance of a distinguished 18-member external advisory
committee, the Executive Director will guide the development of
programmatic initiatives, institutional partnerships, and external
support for OCW.

The successful candidate will be: a visionary leader who can realize
new internal and external opportunities for pre-eminent educational and
research institutions presented by the changing dynamics of the Web; a
seasoned technology manager, ready to run and advance a major
information technology project that has worldwide reach; a
service-oriented implementer able simultaneously to meet the demands of
a world-class faculty and student body and a global community of users;
an articulate and engaging representative for MIT on the world stage,
and the steward of one of MIT's major outreach initiatives; and a
creative developer of a sustainable OCW operation with understanding of
both web-based business models and academic resource development
activities.

Applications and nominations may be submitted in confidence to:

Vivian C. Brocard and Alan Wichlei
Isaacson, Miller
334 Boylston Street, Suite 500
Boston, MA 02116
Email: [EMAIL PROTECTED]

Electronic submission of material is strongly encouraged.


MIT is strongly and actively committed to diversity within its
community and particularly
encourages applications from qualified women and ethnic minority
candidates.


Mark A. Matienzo, MSI <[EMAIL PROTECTED]>
Assistant Archivist, Niels Bohr Library & Archives
American Institute of Physics
1 Physics Ellipse
College Park, MD 20740-3843 USA
tel. +1 301.209-3180 - fax +1 301.209-0882
--
Chair (2007-2008), Description Section
Web Liaison, Metadata and Digital Object Roundtable
Society of American Archivists
--
***Disclaimer***  Opinions in this message are mine alone and do not
represent those of the American Institute of Physics, the Society of
American Archivists or any other affilates, corporate or individual.

Re: [CODE4LIB] Free covers from Google

[Jonathan Rochkind]

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 'service oriented' type architecture, where I have one
component of software that does all of these lookups, and then provides
the resulting data in a uniform format via a local web service for all
my other user-facing interfaces to use. Of course, doing that requires a
server-side lookup. But that overall architecture is much preferable
(from a code efficiency and maintenance perspective)  than having to
include customized AJAX for a variety of services (Google Scholar being
just one; Scopus is another content-provider that frustratingly provides
an Javascript-only API) in a variety of ever-changing user-facing
interfaces. DRY and all.

Jonathan

Tim Spalding 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? I see *no* reason to go
server-side on that. Browser-side gets you what you want—covers from
Google—without the risk they'll shut you down over overuse.

T




--
Jonathan Rochkind
Digital Services Software Engineer
The Sheridan Libraries
Johns Hopkins University
410.516.8886
rochkind (at) jhu.edu

Re: [CODE4LIB] Free covers from Google

[Godmar Back]

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
>  "digitized text availability" from Google Books than just cover images.
>  You might want to suppress ILL links if there is digitized text (in
>  fact, you probably wouldn't in that particular case, but that gives you
>  the idea of what things you might want to do. At least my library
>  wouldn't, maybe others with especially small ILL budgets might).  Or
>  just give a pre-ILL warning message ("are you sure the Google text isn't
>  sufficient?), that might be more realistic.
>
>  Anyway, you obviously couldn't do this using the existing SFX display
>  logic feature if the Google Books info is only client side.
>  Now, "impossible?"  In the world of software development, few things are
>  actually impossible. You could try to duplicate that feature using only
>  client-side Javascript hiding and showing various DIVs.  The SFX HTML
>  currently isn't that clean, it woudl be hard. But you have the
>  capability to customize the SFX HTML however you want to. (And your
>  customizations will likely break with a future SFX release).   So
>  nothings impossible, but I wouldn't want to go down that road.
>

Your particular requirement (hide the ILL link if Google has text) is
easily implemented using the gbs classes: simply wrap the ILL link in
a ... and you're done. SFX will
likely preserve such  tags across releases since it doesn't know
what style you're applying.

If I were you, I'd probably look for a server-side solution first,
too, but let's discuss the architectural differences a bit more.

You mentioned modularity and maintainability - I'd say that a
client-side solution can be kept modular and maintainable as well - in
particular if you minimize the actual JavaScript code you embed in
your output page.

In addition, client-side has significant advantages in both latency
and scalability, in particular when mashing in data from a provider
with a distributed architecture that has a degree of redundancy, and
therefore availability, that is as high Google's.

 - Godmar

Re: [CODE4LIB] Free covers from Google

[Jonathan Rochkind]

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 sufficiently "2.0" (or "3.0"); I've
been a software developer for a long time, but doing client side
javascript stuff for less. Maybe I'm wrong. I dunno. To me, it looks
quite a bit more complex to try and provide these services with the same
level of control and customization in a "don't repeat yourself" modular
way accross all my various display systems that need this functionality,
using client side javascript services.  Other developers, do you think
I'm wrong?

Jonathan

Godmar Back wrote:

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
 "digitized text availability" from Google Books than just cover images.
 You might want to suppress ILL links if there is digitized text (in
 fact, you probably wouldn't in that particular case, but that gives you
 the idea of what things you might want to do. At least my library
 wouldn't, maybe others with especially small ILL budgets might).  Or
 just give a pre-ILL warning message ("are you sure the Google text isn't
 sufficient?), that might be more realistic.

 Anyway, you obviously couldn't do this using the existing SFX display
 logic feature if the Google Books info is only client side.
 Now, "impossible?"  In the world of software development, few things are
 actually impossible. You could try to duplicate that feature using only
 client-side Javascript hiding and showing various DIVs.  The SFX HTML
 currently isn't that clean, it woudl be hard. But you have the
 capability to customize the SFX HTML however you want to. (And your
 customizations will likely break with a future SFX release).   So
 nothings impossible, but I wouldn't want to go down that road.




Your particular requirement (hide the ILL link if Google has text) is
easily implemented using the gbs classes: simply wrap the ILL link in
a ... and you're done. SFX will
likely preserve such  tags across releases since it doesn't know
what style you're applying.

If I were you, I'd probably look for a server-side solution first,
too, but let's discuss the architectural differences a bit more.

You mentioned modularity and maintainability - I'd say that a
client-side solution can be kept modular and maintainable as well - in
particular if you minimize the actual JavaScript code you embed in
your output page.

In addition, client-side has significant advantages in both latency
and scalability, in particular when mashing in data from a provider
with a distributed architecture that has a degree of redundancy, and
therefore availability, that is as high Google's.

 - Godmar




--
Jonathan Rochkind
Digital Services Software Engineer
The Sheridan Libraries
Johns Hopkins University
410.516.8886
rochkind (at) jhu.edu

Re: [CODE4LIB] TWG drinks vs core team dinner

[Todd Grappone]

Katherine,

This email got munged. Can you please resend?

Thanks,

Todd


On Mar 17, 2008, at 8:44 AM, Katherine Kott 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
"digitized text availability" from Google Books than just cover
images.
You might want to suppress ILL links if there is digitized text (in
fact, you probably wouldn't in that particular case, but that gives
you
the idea of what things you might want to do. At least my library
wouldn't, maybe others with especially small ILL budgets might).  Or
just give a pre-ILL warning message ("are you sure the Google text
isn't
sufficient?), that might be more realistic.

Anyway, you obviously couldn't do this using the existing SFX display
logic feature if the Google Books info is only client side.
Now, "impossible?"  In the world of software development, few
things are
actually impossible. You could try to duplicate that feature using
only
client-side Javascript hiding and showing various DIVs.  The SFX HTML
currently isn't that clean, it woudl be hard. But you have the
capability to customize the SFX HTML however you want to. (And your
customizations will likely break with a future SFX release).   So
nothings impossible, but I wouldn't want to go down that road.

Jonathan

Godmar Back wrote:

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 purely client javascript, without losing full
integration with
 SFX on par with other 'services' used by SFX.  We will see what
happens.




Could you elaborate? Do you mean 'hard' or 'impossible'?

Meanwhile, I've extended the google book classes (libx.org/gbs ) to
provide more flexibility; it now supports these classes:

gbs-thumbnail Include an  embedding the thumbnail image
gbs-link-to-preview Wrap span in link to preview at GBS
gbs-link-to-info Wrap span in link to info page at GBS
gbs-link-to-thumbnail Wrap span in link to thumbnail at GBS
gbs-if-noview Keep this span only if GBS reports that book's
viewability is 'noview'
gbs-if-partial-or-full Keep this span only if GBS reports that book's
viewability is at least 'partial'
gbs-if-partial Keep this span only if GBS reports that book's
viewability is 'partial'
gbs-if-full Keep this span only if GBS reports that book's
viewability is 'full'
gbs-remove-on-failure Remove this span if GBS doesn't return bookInfo
for this item

 - Godmar




--
Jonathan Rochkind
Digital Services Software Engineer
The Sheridan Libraries
Johns Hopkins University
410.516.8886
rochkind (at) jhu.edu


---

Todd Grappone
Associate Executive Director
Information Development and Management
CIO University Libraries
The University of Southern California
p: (213) 740-1617
e: [EMAIL PROTECTED]

Re: [CODE4LIB] Free covers from Google

[Jonathan Rochkind]

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 those responses _back_ to my server code using an AJAX call,
which the server can then incorporate into it's server-generated HTML. I
already have a nice architecture for AJAX updating of 'background'
services--which was originally meant for background services generated
on the server side, but with the client doing it and then sending the
response back to the server via AJAX, it _could_ work. And still be nice
and clean and abstract. And I could use it both for Google and for other
client-request-required APIs like Scopus's "cited by" service.

It would be interesting to implement, actually, kind of fun.  I still
worry that this added complexity is just another place for bugs,
(cross-domain AJAX calls using the 

Re: [CODE4LIB] Free covers from Google

[Joe Hourcle]

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

But perhaps my perspective is not sufficiently "2.0" (or "3.0"); I've
been a software developer for a long time, but doing client side
javascript stuff for less. Maybe I'm wrong. I dunno. To me, it looks
quite a bit more complex to try and provide these services with the same
level of control and customization in a "don't repeat yourself" modular
way accross all my various display systems that need this functionality,
using client side javascript services.  Other developers, do you think
I'm wrong?


I agree, but mostly because I'm concerned with the differing ECMAScript
implementations out there (JavaScript, JScript, different versions, etc.),
and the lack of the ability to test for the existance of a function ...
you can test for what version the client thinks it can run, but that
doesn't given you fine control.  (and as try/catch wasn't included 'til
1.3, I had to go through elaborate hoops to try to verify that the code
would run cleanly)

... then there's the issue that I need to support Section 508
requirements, and our normal procedure is to make sure that whatever
features we have don't require client-side support -- they can be
_enhanced_ by client-side scripting, but even without scripting turned on,
the applications are at least usable.

I'm also not a fan of how '' is handled in web browsers.  Say
for instance, that I actually know which spec I'm coding to, and I have
some functionality that requires 1.0, and some that requires 1.3.  I'd
want the  to be directly tied to the 

Re: [CODE4LIB] Free covers from Google

[Jonathan Rochkind]

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 stuff, I _highly_
encourage you to take a look at some of the various Javascript client
libraries that are out there, like Prototype. Such libraries can
provides support for easy 'inheritance' in Javascript (implemented
through behind the scenes fakery), as well as ways to see what
versions/functions of javascript are supported in the browser.

But if you are trying to make things available without client javascript
at all... if a given API like Google _requires_ it, well, then there's
no way to have Google results used by the interface in a non-javascript
client. That's obviously just a syllogism. [It's interesting to know
though that, contrary to popular belief, recent versions of JAWS _do_
support javascript. But only some kinds of javascript done in certain
ways. Doing javascript that will work for JAWS is yet another layer of
complexity, yet another headache. Added headaches and layers of
complexity is why I try to minimize my javascript altogether. And JAWS
is just one kind of 'accessibilty'. And the rules you have to follow
whether you like it or not for 'accessibility' may or may not actually
be rationally related to actual accessible use cases, like it or not.]

Joe Hourcle wrote:

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

But perhaps my perspective is not sufficiently "2.0" (or "3.0"); I've
been a software developer for a long time, but doing client side
javascript stuff for less. Maybe I'm wrong. I dunno. To me, it looks
quite a bit more complex to try and provide these services with the same
level of control and customization in a "don't repeat yourself" modular
way accross all my various display systems that need this functionality,
using client side javascript services.  Other developers, do you think
I'm wrong?


I agree, but mostly because I'm concerned with the differing ECMAScript
implementations out there (JavaScript, JScript, different versions,
etc.),
and the lack of the ability to test for the existance of a function ...
you can test for what version the client thinks it can run, but that
doesn't given you fine control.  (and as try/catch wasn't included 'til
1.3, I had to go through elaborate hoops to try to verify that the code
would run cleanly)

... then there's the issue that I need to support Section 508
requirements, and our normal procedure is to make sure that whatever
features we have don't require client-side support -- they can be
_enhanced_ by client-side scripting, but even without scripting turned
on,
the applications are at least usable.

I'm also not a fan of how '' is handled in web browsers.  Say
for instance, that I actually know which spec I'm coding to, and I have
some functionality that requires 1.0, and some that requires 1.3.  I'd
want the  to be directly tied to the 

Re: [CODE4LIB] Free covers from Google

[Godmar Back]

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 solutions to a good subset of your concerns.

To give you another data point: using an appropriate environment
layer, we're able to run the same JavaScript in LibX in 4
environments:
- in a Firefox extension
- in a IE plugin
- in client-side JavaScript (FF, IE, Safari)
- in server-side JavaScript (via Rhino)

That said: for the largest AJAX application we've build so far (LibX
edition builder at libx.org/editionbuilder ) - we went with a fully
server-centric AJAX solution (ZK from www.zkoss.org ), so no
JavaScript coding here for us

 - Godmar

On Mon, Mar 17, 2008 at 2:44 PM, Joe Hourcle
<[EMAIL PROTECTED]> wrote:
> 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 environment.
>  >
>  > But perhaps my perspective is not sufficiently "2.0" (or "3.0"); I've
>  > been a software developer for a long time, but doing client side
>  > javascript stuff for less. Maybe I'm wrong. I dunno. To me, it looks
>  > quite a bit more complex to try and provide these services with the same
>  > level of control and customization in a "don't repeat yourself" modular
>  > way accross all my various display systems that need this functionality,
>  > using client side javascript services.  Other developers, do you think
>  > I'm wrong?
>
>  I agree, but mostly because I'm concerned with the differing ECMAScript
>  implementations out there (JavaScript, JScript, different versions, etc.),
>  and the lack of the ability to test for the existance of a function ...
>  you can test for what version the client thinks it can run, but that
>  doesn't given you fine control.  (and as try/catch wasn't included 'til
>  1.3, I had to go through elaborate hoops to try to verify that the code
>  would run cleanly)
>
>  ... then there's the issue that I need to support Section 508
>  requirements, and our normal procedure is to make sure that whatever
>  features we have don't require client-side support -- they can be
>  _enhanced_ by client-side scripting, but even without scripting turned on,
>  the applications are at least usable.
>
>  I'm also not a fan of how '' is handled in web browsers.  Say
>  for instance, that I actually know which spec I'm coding to, and I have
>  some functionality that requires 1.0, and some that requires 1.3.  I'd
>  want the  to be directly tied to the 

Re: [CODE4LIB] Free covers from Google

[Boheemen, Peter van]

Godmar,
It did not shut down during development, yesterday, when I developed it from 
home. It broke down today, when people started to use it. All university 
desktop computer have got dynamic 10.*.*.* adresses. The gateway does NAT so 
they are exposed to google with about three possible IP adresses. Or, if they 
use SFX, the IP adress of the Open URL resolver, or in the case of citrix, the 
IP adress of that machine. Anyway, all these approaches suffer from the same 
problem with Google's policy. 
Besides all that, I prefer a clean XML interface like Amazon provides above the 
JSON approach of Google. 
And I do prefer server side handling, since I got control over what the user is 
presented and I do not have problems with javascript support of the specific 
browser that the user is equiped with.
 
Peter
 
 
Drs. P.J.C. van Boheemen
Hoofd Applicatieontwikkeling en beheer - Bibliotheek Wageningen UR
Head of Application Development and Management - Wageningen University and 
Research Library
tel. +31 317 48 25 17   
 http://library.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 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? I see *no* reason to go
>  server-side on that. Browser-side gets you what you want-covers from
>  Google-without the risk they'll shut you down over overuse.
>

But Peter's experience says otherwise, no?
His computer was shut down during development - I don't see how Google
would tell his use from the use of someone doing research using a
library catalog. Especially if NAT is used with a substantial number
of users as in Giles's use case.

 - Godmar

Re: [CODE4LIB] JavaScript / 508 (was: Free covers from Google)

[Joe Hourcle]

On Mon, 17 Mar 2008, Jonathan Rochkind 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. :)


I've had the same philosophy -- even in the case where I have javascript
tree-like menus, the server renders them as fully opened, and then
javascript collapses them to leave the appropriate portions
expanded:

   
http://sdac.virtualsolar.org/cgi/search?provider=1&instrument=mdi&version=current&build=1

(I'd be happier if the HTML were a series of unordered lists, but I'm far
enough behind with my


But if you DO want or need to do javascript-heavy stuff, I _highly_
encourage you to take a look at some of the various Javascript client
libraries that are out there, like Prototype. Such libraries can
provides support for easy 'inheritance' in Javascript (implemented
through behind the scenes fakery), as well as ways to see what
versions/functions of javascript are supported in the browser.


Don't worry -- I have no intentions of recreating the wheel.  I've been
using Prototype for about two years now, and for this recode (displaying
large tables of data, but giving the user the ability to rearrange / sort
on the various fields), we're going with ExtJS.

Unfortunately, although the functionality all works well with scripting
on, it generates some horrible DOM (every row it its own table, and
multiple DIVs down ... I assume to deal with the IE box model issue)



But if you are trying to make things available without client javascript
at all... if a given API like Google _requires_ it, well, then there's
no way to have Google results used by the interface in a non-javascript
client. That's obviously just a syllogism. [It's interesting to know
though that, contrary to popular belief, recent versions of JAWS _do_
support javascript. But only some kinds of javascript done in certain
ways. Doing javascript that will work for JAWS is yet another layer of
complexity, yet another headache. Added headaches and layers of
complexity is why I try to minimize my javascript altogether. And JAWS
is just one kind of 'accessibilty'. And the rules you have to follow
whether you like it or not for 'accessibility' may or may not actually
be rationally related to actual accessible use cases, like it or not.]


I still wish that there were a good free alternative to JAWS  ... I mean,
they've decided to add CSS support, but not the 'aural' media type, if I
understand their website correctly :

   http://www.freedomscientific.com/fs_support/BulletinView.cfm?QC=1165

They also think that passing validation is a viable test for
accessibility:

   https://www.freedomscientific.com/fs_support/BulletinView.cfm?QC=488

I would love to test some of my sites in JAWS (okay, and the sites I'm
forced to use at work that I'm pretty sure aren't compliant and those
where I have to forge my user agent string so it doesn't complain that I'm
not using IE), but I'm in a Windows-less environment.

I also haven't been following the WCAG2 efforts ... other than Joe Clark's
complaints about what was wrong with the process:

   http://www.alistapart.com/articles/tohellwithwcag2


-Joe

Re: [CODE4LIB] Free covers from Google

[Jonathan Rochkind]

Interesting that these problems arise even when using the API as Google
intends on the client side.

I would encourage people to tell Google about this. If only we knew a
way to tell Google about it. If you can find a public email address
anywhere or comment form, let us know. And if you are having problems in
production even when using the API client side as intended, let Google
know. Maybe there will be a miracle and they'll care. Chances are higher
here, because it seems like they created this feature in large part for
libraries. If libraries are finding it does not work in production...

Jonathan

Boheemen, Peter van wrote:

Godmar,
It did not shut down during development, yesterday, when I developed it from 
home. It broke down today, when people started to use it. All university 
desktop computer have got dynamic 10.*.*.* adresses. The gateway does NAT so 
they are exposed to google with about three possible IP adresses. Or, if they 
use SFX, the IP adress of the Open URL resolver, or in the case of citrix, the 
IP adress of that machine. Anyway, all these approaches suffer from the same 
problem with Google's policy.
Besides all that, I prefer a clean XML interface like Amazon provides above the 
JSON approach of Google.
And I do prefer server side handling, since I got control over what the user is 
presented and I do not have problems with javascript support of the specific 
browser that the user is equiped with.

Peter


Drs. P.J.C. van Boheemen
Hoofd Applicatieontwikkeling en beheer - Bibliotheek Wageningen UR
Head of Application Development and Management - Wageningen University and 
Research Library
tel. +31 317 48 25 17 
   http://library.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 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? I see *no* reason to go
 server-side on that. Browser-side gets you what you want-covers from
 Google-without the risk they'll shut you down over overuse.




But Peter's experience says otherwise, no?
His computer was shut down during development - I don't see how Google
would tell his use from the use of someone doing research using a
library catalog. Especially if NAT is used with a substantial number
of users as in Giles's use case.

 - Godmar




--
Jonathan Rochkind
Digital Services Software Engineer
The Sheridan Libraries
Johns Hopkins University
410.516.8886
rochkind (at) jhu.edu

[CODE4LIB] jquery plugin to grab book covers from Google and link to Google books

[Bess Sadler]

Matt Mitchell here at UVa just wrote a jquery plugin to access google
book covers and link to google books. I wrote up how to use it here:
http://www.ibiblio.org/bess/?p=107

We’re using it as part of Blacklight, and we’re making it
available through the Blacklight source code repository under an
Apache 2.0 license.

First, grab the plugin here: http://blacklight.rubyforge.org/svn/
javascript/gbsv-jquery.js, and download jquery here: http://
code.google.com/p/jqueryjs/downloads/detail?name=jquery-1.2.3.min.js.

Now make yourself some HTML that looks like this:

  



$(function(){
$.GBSV.init();
});

  
  




  
  

Now load your page and you should see something like this: http://
blacklight.rubyforge.org/gbsv.html

If you link to a non-existent ISBN it will be silently ignored.

Give it a shot and give us some feedback!

Bess


Elizabeth (Bess) Sadler
Research and Development Librarian
Digital Scholarship Services
Box 400129
Alderman Library
University of Virginia
Charlottesville, VA 22904

[EMAIL PROTECTED]
(434) 243-2305

Re: [CODE4LIB] jquery plugin to grab book covers from Google and link to Google books

[Godmar Back]

Good, but why limit it to 1 class per span?

My proposal separates different functionality in multiple classes,
allowing the user to mix and match. If you limit yourself to 1 class,
you have to provide classes for all possible combinations a user might
want, such as: "gbsv-link-to-preview-with-thumbnail".

 - Godmar

On Mon, Mar 17, 2008 at 4:30 PM, Bess Sadler <[EMAIL PROTECTED]> wrote:
> Matt Mitchell here at UVa just wrote a jquery plugin to access google
>  book covers and link to google books. I wrote up how to use it here:
>  http://www.ibiblio.org/bess/?p=107
>
>  We're using it as part of Blacklight, and we're making it
>  available through the Blacklight source code repository under an
>  Apache 2.0 license.
>
>  First, grab the plugin here: http://blacklight.rubyforge.org/svn/
>  javascript/gbsv-jquery.js, and download jquery here: http://
>  code.google.com/p/jqueryjs/downloads/detail?name=jquery-1.2.3.min.js.
>
>  Now make yourself some HTML that looks like this:
>  
>
>src="jquery-1.2.3.min.js">
>    script>
>