Re: [CODE4LIB] coverage of google book viewability API

[Bob Duncan]

At 06:52 PM 05/08/2008, Tim wrote:

So, I took a long slow look at ten of the examples from Godmar's file.
Nothing I saw disabused me of my opinion: "No preview" pages on Google
Book Search are very weak tea.

Are they worthless? Not always. But they usually are. And,
unfortunately, you generally need to read the various references pages
carefully before you know you were wasting your time.

Some examples:

Risks in Chemical Units
(http://books.google.com/books?id=7ctpCAAJ) has one glancing,
un-annotated reference in the footnotes of another, apparently
different book.

How Trouble Made the Monkey Eat Pepper
(http://books.google.com/books?id=wLnGCAAJ) sports three
references from other books, two in snippet view and one with no view.
Two are bare-bones bibliographic mentions in an index of Canadian
children's books and an index of Canadian chidren's illustrators. The
third is another bare-bones mention in a book in Sinhalese.



I don't think anyone's saying there aren't some pretty useless
entries in GBS, but these two examples strike me as illustrating only
one point:  if you go shopping for weak tea you can usually find
it.  The post-"here's the code" discussion was focused on the
usefulness (or not) of "scanless" GBS records to users of an academic
library catalog.  A fairly obscure book held by 9 OCLC-participating
academic libraries of the unofficial Carnegie class "we have the
money so let's buy almost everything" and a 28-page children's story
published in 1977 (held by 7 US academics and 11 Canadian academics)
are hardly representative of what might be found in most academic
library catalogs.  While they are perfectly valid illustrations of
bad GBS data, they are not valid illustrations of the worthlessness
of links to "scanless" GBS records in academic library catalogs.

Note that I'm not looking for valid illustrations (and I'm sure some
are out there), because a handful of incredibly intelligent real live
academic reference librarian educators down the hall from me have
already done extensive playing around with this and have determined
there's enough useful data in GBS to offer our users links even when
there's no preview or full text available.

Bob Duncan


~!~!~!~!~!~!~!~!~!~!~!~!~
Robert E. Duncan
Systems Librarian
Editor of IT Communications
Lafayette College
Easton, PA  18042
[EMAIL PROTECTED]
http://www.library.lafayette.edu/

Re: [CODE4LIB] coverage of google book viewability API

[Tim Spalding]

> I agree that showing the user evaluative resources that are not any good
> is not a service to the user. When there are no good evaluative
> resources available, we should not show bad ones to the user.

I think we actually agree on what should happen. We disagree on the
theory behind that :)

> [And in most library contexts I am familiar with, that is NOT accurately
> descirbed as "right over there". Perhaps you are familiar with other
> sorts of libraries then I. In a large urban public library system or
> just about ANY academic library, this is just as likely to be: "in the
> library, but you are sitting at home right now, which could be a mile
> away or could be two states away", "in another building [which may be
> miles away]", "checked out to a user, but you can recall it if you
> like", "in this building three floors and 200 meters away", or "not in
> our system at all right now but you can ILL it."

I hear you. This is very situation-dependent, but real. Not all books
are easy to hand. I am depressed by many libraries' willingness to
ship their books to holding facilities. While the rest of the
information world is getting easier, finding your own library's books
is often getting harder. Often these offloaded books are the ones you
can't find out about from any other source, so you're screwed both
physically and digitally.

That said, a lot of talk about the difficulty of getting a book seems
like whining. It's a teenager staring into the fridge and yelling
"Mom, is there anything to eat!" Colleges are places of serious
intellectual work. College work requires a lot of effort *after* you
get the resource. Difficult intellectual work isn't a bug, it's a
feature. It's why you go to college. Research itself often teaches
you. So expecting students to put up with some effort to get better
results is not, as the teenager would say, "the end of the world."

> I certainly agree that making it easier to find a book on the shelves is
> another enhancement we should be looking at. I think it was David Walker
> who had a nice OPAC feature that actually gave you a map, with hilighted
> path, from your computer terminal (if you were sitting in the library,
> which again is probably a _minority_ of our opac use), to the book on
> the shelves. That's awfully cool.

I completely agree. I know David Pattern did something like that. I've
been thinking about how to offer that sort of mapping as a commodity
service.

> But you started out, to my reading, suggesting that Table of Contents, 
> reviews,
> and links to other editions could not possibly be useful, and I still take 
> exception to that.

No. TOCs and reviews are usually pretty useful. Other editions are
useful if there's data there. And the most important cross-edition
link should be in your *catalog*, something almost no library does.

Best,
Tim

Re: [CODE4LIB] coverage of google book viewability API

[Custer, Mark]

Isn't the whole point of this to get the user to the book?  Knowledge
about the book should/will come from research and reading, not bad
metadata...  or even hastily automated extraneous info...  and in fact,
I'd say that most MARC metadata is only there to get a user to the book,
not to describe it to the user (aside from subjects), but mainly to
describe it to the library.

That said, I showed an example
(http://books.google.com/books?id=kdiYGQAACAAJ) in which a Google Books
"no view" gets a user to a "full view", completely electronically!
(though, my goodness, in the state it's in now it does require
experimentation and two extra mouse clicks)

What's more, Google already has a link for every book to Worldcat, which
helps the user get to a "full view", completely physically.  Ideally,
researchers will begin to have more and more opportunities to research
texts side-by-side with a physical and an electronic copy.  That is, of
course, once they have more options to download different formats rather
than just the rather large PDFs currently available at Google.

Right now, yes, most "no view" options offer far less information to a
user who can read a MARC record...  but I'd presume that as more texts
go online, the more value and richness will be added, even to those "no
view" cases.

Mark Custer


-Original Message-
From: Code for Libraries [mailto:[EMAIL PROTECTED] On Behalf Of
Tim Spalding
Sent: Friday, May 09, 2008 11:44 AM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] coverage of google book viewability API

> Most of our users will start out in an electronic environment whether
we like it or not
> (most of us on THIS list like it)---and will decide,  based on what
they
> find there, on their own, without us making the decision for
> them---whether to obtain (or attempt to obtain) a copy of the physical
> book or not. Whether we like it or not.

>But if you think the options are between US deciding whether the user
should consult a physical book or not---then we're not even playing the
same game.

What I dislike here is your abnegation of the responsibility to care
about the choices students make. If you're not considering the value
of all resources-including the book-you're not playing the library
game, the educator game or the Google game. You're just throwing stuff
on screens because you can.

"Whether you like it or not" you're pointing students in some
directions and not others. You're giving these resources different
amounts of emphasis in your UI. You're including some and not
others-the others includes all other web pages and all other offline
resources. You aren't making choices for the user, but you're not
stepping back and washing your hands of the responsibility to help the
student.

In a physical-book context, the book is one of the resources. It
deserves to weighted and evaluated within this larger set of choices.
It's your responsibility to consider it within the mix of options. If
the book is excellent and the online resources poor, helping the user
means communicating this. So, sometimes the OPAC should basically say
"there's nothing good online about this book; but it's on the shelf
right over there."

*Certainly in Classics that's still true-the online world is a very
impoverished window into the discipline.

Re: [CODE4LIB] coverage of google book viewability API

[Larry Campbell]

What I dislike here is your assumption that you know better than your
users what's "good" for them/what they want/what they OUGHT to want/what
they need/etc. Providing them with available information in a reasonably
accessible way, and then trusting them -- whether they're undergrads,
grad students, lecturers, profs, researchers, community users, etc -- to
make their own decisions about what to do with that based upon their
particular, individual, and personal circumstances, locations, contexts,
etc., isn't "abnegating" your responsibility -- it IS your responsibility.

Larry Campbell
UBC Library

Tim Spalding wrote:


Most of our users will start out in an electronic environment whether we like 
it or not
(most of us on THIS list like it)---and will decide,  based on what they
find there, on their own, without us making the decision for
them---whether to obtain (or attempt to obtain) a copy of the physical
book or not. Whether we like it or not.







But if you think the options are between US deciding whether the user should 
consult a physical book or not---then we're not even playing the same game.




What I dislike here is your abnegation of the responsibility to care
about the choices students make. If you're not considering the value
of all resources—including the book—you're not playing the library
game, the educator game or the Google game. You're just throwing stuff
on screens because you can.

"Whether you like it or not" you're pointing students in some
directions and not others. You're giving these resources different
amounts of emphasis in your UI. You're including some and not
others—the others includes all other web pages and all other offline
resources. You aren't making choices for the user, but you're not
stepping back and washing your hands of the responsibility to help the
student.

In a physical-book context, the book is one of the resources. It
deserves to weighted and evaluated within this larger set of choices.
It's your responsibility to consider it within the mix of options. If
the book is excellent and the online resources poor, helping the user
means communicating this. So, sometimes the OPAC should basically say
"there's nothing good online about this book; but it's on the shelf
right over there."

*Certainly in Classics that's still true—the online world is a very
impoverished window into the discipline.

Re: [CODE4LIB] coverage of google book viewability API

[Jonathan Rochkind]

I agree that showing the user evaluative resources that are not any good
is not a service to the user. When there are no good evaluative
resources available, we should not show bad ones to the user.

In either case though, with or without evaluative resources, we tell the
user where the book is located on the shelves.

[And in most library contexts I am familiar with, that is NOT accurately
descirbed as "right over there". Perhaps you are familiar with other
sorts of libraries then I. In a large urban public library system or
just about ANY academic library, this is just as likely to be: "in the
library, but you are sitting at home right now, which could be a mile
away or could be two states away", "in another building [which may be
miles away]", "checked out to a user, but you can recall it if you
like", "in this building three floors and 200 meters away", or "not in
our system at all right now but you can ILL it."  So I'm having problems
with your continued assertions that the book is "right over there" for a
user consulting the OPAC.  Not neccesarily in a majority of the cases
for my users, or the users of most other libraries I am familiar with.]

I certainly agree that making it easier to find a book on the shelves is
another enhancement we should be looking at. I think it was David Walker
who had a nice OPAC feature that actually gave you a map, with hilighted
path, from your computer terminal (if you were sitting in the library,
which again is probably a _minority_ of our opac use), to the book on
the shelves. That's awfully cool.

And in either case, with or without extra evaluative metadata, with or
without an interactive map showing you were the book is---in the end
it's the user's choice of whether to obtain the book or not. Our job is,
indeed, giving them good and useful and accurate evaluative information
to aid in this selection process. If you suggest that Google metadata is
NOT good and useful and accurate metadata, that's legitimate.  But you
started out, to my reading, suggesting that Table of Contents, reviews,
and links to other editions could not possibly be useful, and I still
take exception to that.

Jonathan

Tim Spalding wrote:

Most of our users will start out in an electronic environment whether we like 
it or not
(most of us on THIS list like it)---and will decide,  based on what they
find there, on their own, without us making the decision for
them---whether to obtain (or attempt to obtain) a copy of the physical
book or not. Whether we like it or not.





But if you think the options are between US deciding whether the user should 
consult a physical book or not---then we're not even playing the same game.



What I dislike here is your abnegation of the responsibility to care
about the choices students make. If you're not considering the value
of all resources—including the book—you're not playing the library
game, the educator game or the Google game. You're just throwing stuff
on screens because you can.

"Whether you like it or not" you're pointing students in some
directions and not others. You're giving these resources different
amounts of emphasis in your UI. You're including some and not
others—the others includes all other web pages and all other offline
resources. You aren't making choices for the user, but you're not
stepping back and washing your hands of the responsibility to help the
student.

In a physical-book context, the book is one of the resources. It
deserves to weighted and evaluated within this larger set of choices.
It's your responsibility to consider it within the mix of options. If
the book is excellent and the online resources poor, helping the user
means communicating this. So, sometimes the OPAC should basically say
"there's nothing good online about this book; but it's on the shelf
right over there."

*Certainly in Classics that's still true—the online world is a very
impoverished window into the discipline.




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

Re: [CODE4LIB] coverage of google book viewability API

[Tim Spalding]

> Most of our users will start out in an electronic environment whether we like 
> it or not
> (most of us on THIS list like it)---and will decide,  based on what they
> find there, on their own, without us making the decision for
> them---whether to obtain (or attempt to obtain) a copy of the physical
> book or not. Whether we like it or not.

>But if you think the options are between US deciding whether the user should 
>consult a physical book or not---then we're not even playing the same game.

What I dislike here is your abnegation of the responsibility to care
about the choices students make. If you're not considering the value
of all resources—including the book—you're not playing the library
game, the educator game or the Google game. You're just throwing stuff
on screens because you can.

"Whether you like it or not" you're pointing students in some
directions and not others. You're giving these resources different
amounts of emphasis in your UI. You're including some and not
others—the others includes all other web pages and all other offline
resources. You aren't making choices for the user, but you're not
stepping back and washing your hands of the responsibility to help the
student.

In a physical-book context, the book is one of the resources. It
deserves to weighted and evaluated within this larger set of choices.
It's your responsibility to consider it within the mix of options. If
the book is excellent and the online resources poor, helping the user
means communicating this. So, sometimes the OPAC should basically say
"there's nothing good online about this book; but it's on the shelf
right over there."

*Certainly in Classics that's still true—the online world is a very
impoverished window into the discipline.

Re: [CODE4LIB] coverage of google book viewability API

[Jonathan Rochkind]

And indeed, that is exactly how I plan to make use of the Google
metadata link, and have been suggesting is the best way to make use of
it since I entered this conversation:  As part of a set of links to
'additional information' about a resource, with no special prominence
given to the Google link.

Other "additional information" links I either have already or plan to
have soon include:
Amazon.com
isbndb.com (a good aggregator of online prices for purchase, which has a
nice api)
Ulrich's (for serials)
Books in Print
OCLC Worldcat
OCLC Identities (for the author of the resource)

Of course, there is definitely a danger here of information overload. If
these "additonal information" links are layed out on the page they
shouldn't interfere with the use of hte page by people who want to
ignore them entirely. But too _many_ links in the "additional
information" section may make people ignore it entirely, where a smaller
list limited to the most useful links would get more use.  But at the
moment, we're not really sure which are the 'most useful' links, so I
think I'll err on the side of inclusion, up to a maximum of 6 or 7 links.

Jonathan

Tim Spalding wrote:

If the Google link were part of a much larger set of unstressed links,
I'd be more inclined to favor it. Lots of linking is a good thing. But
a single no-info Google link from a low-information OPAC page seems to
compound the deficiencies of one paradigm with that of another.

On the subject of "lazy" students, I do think there is a legitimate
distinction between what students will do and what they ought to do.
Being pro-Web 2.0 doesn't require us to be information relativists.
Certainly there is a lot of ignorant criticism about Wikipedia.
Wikipedia is a remarkable resource, and an inspiration to us all.
Students will and probably should use it when they're starting out on
a topic.

That some students will use it long after that, in the place of better
resources online and off, because it's the "path of least resistance"
isn't just a fact of life we must all bow before. It is a problem we
must confront. Not infrequently the right answer is "get off your butt
and read a book."

Tim

On Fri, May 9, 2008 at 8:44 AM, Custer, Mark <[EMAIL PROTECTED]> wrote:


For the most part, I completely agree.  That said, it's a very tangled
web out there, and on occasion those "no preview" views can still lead a
user to a "full view" that's offered elsewhere.  Here's just one
example:

http://books.google.com/books?id=kdiYGQAACAAJ
(from there, a user can click on the first link to be taken to another
metadata page that has access to a "full view")

Unfortunately, there's no indication that either of these links will get
you to a full-text digitized copy of the book in question (the links
always, of course, appear under the header of "References from web
pages", which Google has nicely added), and there's also no way to know
that a "no preview" book has any such "references from web pages" until
you access the item, but it's something, at least, however unintended.

It'd be nice, perhaps, if you could put some sort of standard in the
metadata header of the webpage (DC or otherwise) to indicate to a
harvester (in this case, a crawler) the specific format of the
retrieval.  Then these links could be labeled as "digitized copies
available elsewhere", rather than simply "references from web pages"
(which, of course, is all that they are right now), and could also be
added to the API callback.  That is, of course, if Google doesn't
eventually put up these and other localized resources as well (and I'm
sure they'll cover most of these, with the collections that they do
have)...  but until or if they do, it would go a longer way to
fulfilling their mission.

Mark Custer



-Original Message-
From: Code for Libraries [mailto:[EMAIL PROTECTED] On Behalf Of
Tim Spalding
Sent: Thursday, May 08, 2008 6:52 PM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] coverage of google book viewability API

So, I took a long slow look at ten of the examples from Godmar's file.
Nothing I saw disabused me of my opinion: "No preview" pages on Google
Book Search are very weak tea.

Are they worthless? Not always. But they usually are. And,
unfortunately, you generally need to read the various references pages
carefully before you know you were wasting your time.

Some examples:

Risks in Chemical Units
(http://books.google.com/books?id=7ctpCAAJ) has one glancing,
un-annotated reference in the footnotes of another, apparently
different book.

How Trouble Made the Monkey Eat Pepper
(http://books.google.com/books?id=wLnGCAAJ) sports three
references from other books, two in snippet view and one with no v

Re: [CODE4LIB] coverage of google book viewability API

[Jonathan Rochkind]

Ah, but in our actual world we _don't_ have two choices, to send the
user to the physical book or to an electronic metadata surrogate. We
_don't_ get to force the user to look at the book. Most of our users
will start out in an electronic environment whether we like it or not
(most of us on THIS list like it)---and will decide,  based on what they
find there, on their own, without us making the decision for
them---whether to obtain (or attempt to obtain) a copy of the physical
book or not. Whether we like it or not. But again, most of us on THIS
list like it, and like the challenge of giving the user useful
information in the electronic surrogate environment to make up their own
mind about whether to obtain the physical book or not.

So we can disagree about whether Google metadata is a valuable aid to
the user in selection task or not, sure.

But if you think the options are between US deciding whether the user
should consult a physical book or not---then we're not even playing the
same game.

Jonathan

Tim Spalding wrote:

So, I took a long slow look at ten of the examples from Godmar's file.
Nothing I saw disabused me of my opinion: "No preview" pages on Google
Book Search are very weak tea.

Are they worthless? Not always. But they usually are. And,
unfortunately, you generally need to read the various references pages
carefully before you know you were wasting your time.

Some examples:

Risks in Chemical Units
(http://books.google.com/books?id=7ctpCAAJ) has one glancing,
un-annotated reference in the footnotes of another, apparently
different book.

How Trouble Made the Monkey Eat Pepper
(http://books.google.com/books?id=wLnGCAAJ) sports three
references from other books, two in snippet view and one with no view.
Two are bare-bones bibliographic mentions in an index of Canadian
children's books and an index of Canadian chidren's illustrators. The
third is another bare-bones mention in a book in Sinhalese.



 If the patron is sitting on  a computer (which, given this discussion, they 
obviously are), the
 path of least resistance dictates that a journal article will be used before a 
book.



An excellent example. Let's imagine you were doing reference-desk work
and a student were to come up to you with a question about a topic.
You have two sources you can send them to—the book itself in all its
glory, and another source. The other source is the Croatian-language
MySpace page of someone whose boyfriend read a chapter of the book
once, five years ago. You're not sure if the blog mentions the book,
but it might.

That something provides the path of least resistance isn't an argument
for something. It depends on where the path goes.




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

Re: [CODE4LIB] coverage of google book viewability API

[Tim Spalding]

If the Google link were part of a much larger set of unstressed links,
I'd be more inclined to favor it. Lots of linking is a good thing. But
a single no-info Google link from a low-information OPAC page seems to
compound the deficiencies of one paradigm with that of another.

On the subject of "lazy" students, I do think there is a legitimate
distinction between what students will do and what they ought to do.
Being pro-Web 2.0 doesn't require us to be information relativists.
Certainly there is a lot of ignorant criticism about Wikipedia.
Wikipedia is a remarkable resource, and an inspiration to us all.
Students will and probably should use it when they're starting out on
a topic.

That some students will use it long after that, in the place of better
resources online and off, because it's the "path of least resistance"
isn't just a fact of life we must all bow before. It is a problem we
must confront. Not infrequently the right answer is "get off your butt
and read a book."

Tim

On Fri, May 9, 2008 at 8:44 AM, Custer, Mark <[EMAIL PROTECTED]> wrote:
> For the most part, I completely agree.  That said, it's a very tangled
> web out there, and on occasion those "no preview" views can still lead a
> user to a "full view" that's offered elsewhere.  Here's just one
> example:
>
> http://books.google.com/books?id=kdiYGQAACAAJ
> (from there, a user can click on the first link to be taken to another
> metadata page that has access to a "full view")
>
> Unfortunately, there's no indication that either of these links will get
> you to a full-text digitized copy of the book in question (the links
> always, of course, appear under the header of "References from web
> pages", which Google has nicely added), and there's also no way to know
> that a "no preview" book has any such "references from web pages" until
> you access the item, but it's something, at least, however unintended.
>
> It'd be nice, perhaps, if you could put some sort of standard in the
> metadata header of the webpage (DC or otherwise) to indicate to a
> harvester (in this case, a crawler) the specific format of the
> retrieval.  Then these links could be labeled as "digitized copies
> available elsewhere", rather than simply "references from web pages"
> (which, of course, is all that they are right now), and could also be
> added to the API callback.  That is, of course, if Google doesn't
> eventually put up these and other localized resources as well (and I'm
> sure they'll cover most of these, with the collections that they do
> have)...  but until or if they do, it would go a longer way to
> fulfilling their mission.
>
> Mark Custer
>
>
>
> -Original Message-
> From: Code for Libraries [mailto:[EMAIL PROTECTED] On Behalf Of
> Tim Spalding
> Sent: Thursday, May 08, 2008 6:52 PM
> To: CODE4LIB@LISTSERV.ND.EDU
> Subject: Re: [CODE4LIB] coverage of google book viewability API
>
> So, I took a long slow look at ten of the examples from Godmar's file.
> Nothing I saw disabused me of my opinion: "No preview" pages on Google
> Book Search are very weak tea.
>
> Are they worthless? Not always. But they usually are. And,
> unfortunately, you generally need to read the various references pages
> carefully before you know you were wasting your time.
>
> Some examples:
>
> Risks in Chemical Units
> (http://books.google.com/books?id=7ctpCAAJ) has one glancing,
> un-annotated reference in the footnotes of another, apparently
> different book.
>
> How Trouble Made the Monkey Eat Pepper
> (http://books.google.com/books?id=wLnGCAAJ) sports three
> references from other books, two in snippet view and one with no view.
> Two are bare-bones bibliographic mentions in an index of Canadian
> children's books and an index of Canadian chidren's illustrators. The
> third is another bare-bones mention in a book in Sinhalese.
>
>>  If the patron is sitting on  a computer (which, given this
> discussion, they obviously are), the
>>  path of least resistance dictates that a journal article will be used
> before a book.
>
> An excellent example. Let's imagine you were doing reference-desk work
> and a student were to come up to you with a question about a topic.
> You have two sources you can send them to-the book itself in all its
> glory, and another source. The other source is the Croatian-language
> MySpace page of someone whose boyfriend read a chapter of the book
> once, five years ago. You're not sure if the blog mentions the book,
> but it might.
>
> That something provides the path of least resistance isn't an argument
> for something. It depends on where the path goes.
>



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

Re: [CODE4LIB] coverage of google book viewability API

[Custer, Mark]

For the most part, I completely agree.  That said, it's a very tangled
web out there, and on occasion those "no preview" views can still lead a
user to a "full view" that's offered elsewhere.  Here's just one
example:

http://books.google.com/books?id=kdiYGQAACAAJ
(from there, a user can click on the first link to be taken to another
metadata page that has access to a "full view")

Unfortunately, there's no indication that either of these links will get
you to a full-text digitized copy of the book in question (the links
always, of course, appear under the header of "References from web
pages", which Google has nicely added), and there's also no way to know
that a "no preview" book has any such "references from web pages" until
you access the item, but it's something, at least, however unintended.

It'd be nice, perhaps, if you could put some sort of standard in the
metadata header of the webpage (DC or otherwise) to indicate to a
harvester (in this case, a crawler) the specific format of the
retrieval.  Then these links could be labeled as "digitized copies
available elsewhere", rather than simply "references from web pages"
(which, of course, is all that they are right now), and could also be
added to the API callback.  That is, of course, if Google doesn't
eventually put up these and other localized resources as well (and I'm
sure they'll cover most of these, with the collections that they do
have)...  but until or if they do, it would go a longer way to
fulfilling their mission.

Mark Custer



-Original Message-
From: Code for Libraries [mailto:[EMAIL PROTECTED] On Behalf Of
Tim Spalding
Sent: Thursday, May 08, 2008 6:52 PM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] coverage of google book viewability API

So, I took a long slow look at ten of the examples from Godmar's file.
Nothing I saw disabused me of my opinion: "No preview" pages on Google
Book Search are very weak tea.

Are they worthless? Not always. But they usually are. And,
unfortunately, you generally need to read the various references pages
carefully before you know you were wasting your time.

Some examples:

Risks in Chemical Units
(http://books.google.com/books?id=7ctpCAAJ) has one glancing,
un-annotated reference in the footnotes of another, apparently
different book.

How Trouble Made the Monkey Eat Pepper
(http://books.google.com/books?id=wLnGCAAJ) sports three
references from other books, two in snippet view and one with no view.
Two are bare-bones bibliographic mentions in an index of Canadian
children's books and an index of Canadian chidren's illustrators. The
third is another bare-bones mention in a book in Sinhalese.

>  If the patron is sitting on  a computer (which, given this
discussion, they obviously are), the
>  path of least resistance dictates that a journal article will be used
before a book.

An excellent example. Let's imagine you were doing reference-desk work
and a student were to come up to you with a question about a topic.
You have two sources you can send them to-the book itself in all its
glory, and another source. The other source is the Croatian-language
MySpace page of someone whose boyfriend read a chapter of the book
once, five years ago. You're not sure if the blog mentions the book,
but it might.

That something provides the path of least resistance isn't an argument
for something. It depends on where the path goes.

Re: [CODE4LIB] coverage of google book viewability API

[Tim Spalding]

So, I took a long slow look at ten of the examples from Godmar's file.
Nothing I saw disabused me of my opinion: "No preview" pages on Google
Book Search are very weak tea.

Are they worthless? Not always. But they usually are. And,
unfortunately, you generally need to read the various references pages
carefully before you know you were wasting your time.

Some examples:

Risks in Chemical Units
(http://books.google.com/books?id=7ctpCAAJ) has one glancing,
un-annotated reference in the footnotes of another, apparently
different book.

How Trouble Made the Monkey Eat Pepper
(http://books.google.com/books?id=wLnGCAAJ) sports three
references from other books, two in snippet view and one with no view.
Two are bare-bones bibliographic mentions in an index of Canadian
children's books and an index of Canadian chidren's illustrators. The
third is another bare-bones mention in a book in Sinhalese.

>  If the patron is sitting on  a computer (which, given this discussion, they 
> obviously are), the
>  path of least resistance dictates that a journal article will be used before 
> a book.

An excellent example. Let's imagine you were doing reference-desk work
and a student were to come up to you with a question about a topic.
You have two sources you can send them to—the book itself in all its
glory, and another source. The other source is the Croatian-language
MySpace page of someone whose boyfriend read a chapter of the book
once, five years ago. You're not sure if the blog mentions the book,
but it might.

That something provides the path of least resistance isn't an argument
for something. It depends on where the path goes.

Re: [CODE4LIB] coverage of google book viewability API

[Ross Singer]

On Wed, May 7, 2008 at 4:55 PM, Tim Spalding <[EMAIL PROTECTED]> wrote:
> As for the idea that getting a book off the shelf is a non-trivial
> hassle, while I admit that it can get hard if your library is split
> between locations, at most colleges, getting a book from a library is
> a trivial effort. And anyway, you're a student for pete's sake!
> Learning is your full-time job. If gets books off shelves bums you
> out, what are you doing in college?
>

What about distance learners?

What about books that aren't in your library that you're considering
an ILL request for?

What if you're trying to decide, from home, if this book is worth the
30+ minute drive to the library to use for your paper due (oh, I don't
know) tomorrow?

In the modern world, it's a very small fraction of the student body
that lives in the dorms.

Also, it doesn't matter how "trivial" it is to get the book from the
library, the laws of physics still apply.  If the patron is sitting on
a computer (which, given this discussion, they obviously are), the
path of least resistance dictates that a journal article will be used
before a book.

-Ross.

Re: [CODE4LIB] coverage of google book viewability API

[Bob Duncan]

At 04:55 PM 05/07/2008, Tim wrote:

. . .
Whether scannless GBS is bad enough, I leave to you. I think it is,
but there's an argument, certainly. I don't think we can argue that
there is *some* lower threshold of quality beneath which data should
be left off the OPAC. I note, for example, that most "empty" books in
GBS do not show up high on Google's searches for that book name. They
don't show up because, absent a scan, GBS books are pretty weak tea.

As for the idea that getting a book off the shelf is a non-trivial
hassle, while I admit that it can get hard if your library is split
between locations, at most colleges, getting a book from a library is
a trivial effort. And anyway, you're a student for pete's sake!
Learning is your full-time job. If gets books off shelves bums you
out, what are you doing in college?



A few comments:

(1)  I've only been working in an academic library for 12 years, but
getting a book from the library shelf passed from the skills we teach
a while back.  These days the learning objectives in most academic
libraries with which I'm acquainted involve things like learning how
to evaluate information for its usefulness and appropriateness at
several points in the research process.  An undergraduate student
writing a 10 page paper faced with 50 results from a library catalog
search needs to make some quick judgements about what might be useful
and what might not be useful before heading off to the stacks.  If a
"scanless" GBS record with summary and/or ToC and/or reviews can help
winnow the list down to a manageable number so the student can spend
his/her time evaluating and processing the actual information so they
can write an informed paper, then why not offer it?

(2)  Part of why we have books in the library is so users can check
them out.  The existence of a record for a book in a library catalog
doesn't mean the book is on the shelf.  If a scanless GBS record with
summary and/or ToC and/or reviews can help a student make an initial
determination about the appropriateness of a book that can't be
consulted because the book's not on the shelf, it suddenly becomes
pretty useful.  Most academic libraries now belong to consortia that
allow requesting of items from other libraries when the local copy is
checked out.  Scanless GBS info might aid in determining whether or
not the book should be requested.

(3)  Scanless GBS records can augment the catalog record and/or the
book itself.  I was just looking at the scanless GBS record for a
colleague's recent work, and while it lacked a ToC or summary in the
GBS record, the "References from web pages" offered links to:
-  an NPR interview with the author (from a popular perspective);
-  a Chronicle piece on the book;
-  the University Press page for the book, that did have a summary;
-  a page for the book at Blackwell, that did have the ToC;
-  a podcast of a half hour interview with the author (from a
scholarly perspective).


The weak tea scanless record for this book has the potential to (a)
help users make an initial evaluation of the appropriateness and
usefulness of the book;  (b) conserve library resources by informing
the decision to request from another library; (c) offer supporting
information not available in the book, regardless of format.

Bob Duncan


~!~!~!~!~!~!~!~!~!~!~!~!~
Robert E. Duncan
Systems Librarian
Editor of IT Communications
Lafayette College
Easton, PA  18042
[EMAIL PROTECTED]
http://www.library.lafayette.edu/

Re: [CODE4LIB] coverage of google book viewability API

[Jonathan Rochkind]

So are you opposed to the long-standing practice of adding table of
contents to catalog records on the same grounds?

Table of contents is one thing that Google metadata can provide.

Certainly if Google's metadata were bad enough, it should not be
included. I'm confused as to why you're arguing that "scan-less" GBS
information is automatically bad.  Obviously, in the case of a scan-less
GBS record, it's the _other_ metadata contained there that is of
interest. Even if GBS somehow had NO scanned text, that other metadata
might still be of interest and of quality.  You seem to keep ignoring
the fact that the GBS api response _tells you_ if full text is available
or not--your client software is not reduced to presenting "scan-less"
GBS links _as if_ they were full text. That would indeed be a problem.

I am still very confused as to where your opposition comes from.  I
don't think most people maintaining library systems share an opposition
to providing users with tables of contents, publisher information, and
other information GBS metadata can provide.

As an entirely separate issue, some GBS records do not allow full
viewing, but DO allow "search inside the book" (with excerpts in your
hits), which is another useful service. And yes, the GBS api tells you
specifically if that's the access level. Not sure if Tim's opposition
extends to these too. Search inside the book seems like an obviously
useful value-added service to me.

Jonathan

Tim Spalding wrote:

Two thought experiments:

*Let's add SparkNotes to the catalog. After all, SparkNotes has
information about books. Therefore, since all information is good
information, let's add it to the catalog.
*If SparkNotes, let's add free-essay-mill essays into the catalog.
*If that works, let's add snippets from the Google results to the
catalog. Not the first result, but the 100th. Since all information is
good information, the 100th result should be better than nothing.

At some point, information is bad enough or far enough away from the
goals of education that while a student might conceivably use it, they
would be foolish to do so. For example, if LibraryThing for Libraries
recommendations uniformly terrible, nobody should add them to their
catalogs. This is doubly true when the bad information is juxtaposed
with good information sitting on a shelf.

Whether scannless GBS is bad enough, I leave to you. I think it is,
but there's an argument, certainly. I don't think we can argue that
there is *some* lower threshold of quality beneath which data should
be left off the OPAC. I note, for example, that most "empty" books in
GBS do not show up high on Google's searches for that book name. They
don't show up because, absent a scan, GBS books are pretty weak tea.

As for the idea that getting a book off the shelf is a non-trivial
hassle, while I admit that it can get hard if your library is split
between locations, at most colleges, getting a book from a library is
a trivial effort. And anyway, you're a student for pete's sake!
Learning is your full-time job. If gets books off shelves bums you
out, what are you doing in college?

Best,
Tim




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

Re: [CODE4LIB] coverage of google book viewability API

[Tim Spalding]

Two thought experiments:

*Let's add SparkNotes to the catalog. After all, SparkNotes has
information about books. Therefore, since all information is good
information, let's add it to the catalog.
*If SparkNotes, let's add free-essay-mill essays into the catalog.
*If that works, let's add snippets from the Google results to the
catalog. Not the first result, but the 100th. Since all information is
good information, the 100th result should be better than nothing.

At some point, information is bad enough or far enough away from the
goals of education that while a student might conceivably use it, they
would be foolish to do so. For example, if LibraryThing for Libraries
recommendations uniformly terrible, nobody should add them to their
catalogs. This is doubly true when the bad information is juxtaposed
with good information sitting on a shelf.

Whether scannless GBS is bad enough, I leave to you. I think it is,
but there's an argument, certainly. I don't think we can argue that
there is *some* lower threshold of quality beneath which data should
be left off the OPAC. I note, for example, that most "empty" books in
GBS do not show up high on Google's searches for that book name. They
don't show up because, absent a scan, GBS books are pretty weak tea.

As for the idea that getting a book off the shelf is a non-trivial
hassle, while I admit that it can get hard if your library is split
between locations, at most colleges, getting a book from a library is
a trivial effort. And anyway, you're a student for pete's sake!
Learning is your full-time job. If gets books off shelves bums you
out, what are you doing in college?

Best,
Tim

Re: [CODE4LIB] coverage of google book viewability API

[Jonathan Rochkind]

I don't see what's harmful about letting users examine Google metadata
about a book before deciding whether to get it off the shelves.  There
is a non-trivial amount of time involved in going to the library and
finding the book in the stacks.(And maybe if you want it you in fact
need to 'recall' it and wait a few days for it to come back, or ILL it).
For a large research project, there are lots of books you might
potentially be interested in. The more our catalog tells you about the
book to help aid the user in deciding if the book is of interest to
them---the better.  Is this not one of the functions of the catalog,
even one defined in the age-old IFLA principles/objectives? To aid the
user  "to *select *a bibliographic resource that is appropriate to the
user’s needs".

Is this not in fact one of the functions of, for instance, oh, the
LibraryThing  catalog enhancements?

I'd like to give the user as much  "evaluative" information to aid in
their selection as possible. Google is just as good a source of this as
anything else.  It is important to allow the user to easily distinguish
extra evaluative information from electronic (or other) access routes,
and to keep the extra evaluative information from overwhelming the user
or making the interface more confusing. This is a question of interface
design.

I don't understand Tim's opposition.

Jonathan

Tim Spalding wrote:

The general consensus around here seems to be even the minimal


records tend to have useful information, more so than if Google was
just repeating the catalog entry.

What bothers me here is that this isn't a "good enough" situation.
This isn't so-so information in an information poor environment. The
library has the book in all its glory, right there on the shelf ready
for the deepest, truest engagement.

As a former educator (okay, a TA, but I cared!), I believe that
learning often requires some effort—not involves but requires.
Engaging with something you don't know or understand is hard. Giving
students tools is good. But if you give them a tool simultaneously
super-easy and deeply deficient, too many will choose it over harder,
better tools. (Of course, getting a book off a shelf didn't *used* to
seem like hard work.) At some point, schools and libraries should
promote tools that are "good for you" over ones that aren't.

I don't want to overdo this. I built LibraryThing. I'm the farthest
thing from anti-web. But I balk at pushing empty Google Book Search
pages on students who could get off their rear ends and hold the book
in their hands two minutes later.

Tim




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

Re: [CODE4LIB] coverage of google book viewability API

[Genny Engel]

Our request volume goes up all the time, as does the quantity of items
that patrons flip through and then abandon at the holds shelf.  The
better information they have up front before they make the request, in
theory, the lower the chance they'll request items that they then don't
pick up.

We recently added the Syndetics "enhanced content" that includes book
covers, selected first chapters, reviews, summaries, etc.
http://catalog.sonomalibrary.org
The patrons have been very happy with it, especially the book covers,
but it remains to be seen whether the additional content does reduce the
irrelevant-request volume.

This is a public library, so ymmv at academic libraries ...

Genny Engel


>>> [EMAIL PROTECTED] 05/07/08 08:45AM >>>
I think Kyle brings up a great point. If we can get links to previews,
patrons will have a better understanding of what a book has to decide
if
they want to go to another library on campus to look at it, request it
to be
retrieved from off-site storage, ILL it, etc. This would be a very
useful
thing to many patrons, I think.

Edward

On Wed, May 7, 2008 at 11:10 AM, Kyle Banerjee
<[EMAIL PROTECTED]>
wrote:

> > 0.2% full text? Yowch!
> >
> >  Do academic libraries with full-text versions of the book on
their
> >  shelves really want to point people to no-preview pages on
Google.
> >  That's like a dating site with no photos of the members, and the
> >  profiles omit everything but their favorite potato variety.
>
> At first, this whole thing reminded me of a few years back when
Amazon
> wanted libraries to load their inventory into catalogs. The idea was
> that letting people know an item that wasn't available in the
library
> could be bought from Amazon was a useful service. Not too many
> libraries were takers.
>
> 0.2% might even be better and worse than it looks. Worse in the
sense
> that it could be some random public domain garbage that there's
little
> or no demand for. However, at the end of the day the percentage of
> books available full text is far less important than if the ones
that
> are available are the ones that people want.
>
> On the other hand, if partial preview really is available for 6.2%,
it
> could be very useful for helping people decide if they need a book
at
> all. This has significant implications for ILL and circ costs over
the
> long haul. Presumably, the number of books with a preview available
> will increase dramatically with time.
>
> kyle
>

Re: [CODE4LIB] coverage of google book viewability API

[Bob Duncan]

At 12:04 AM 05/07/2008, Godmar wrote:

. . .
I had the same subjective impression in that I was surprised by how
many books have previews ...



While trying to figure out why I was seeing a link to a preview in
Virginia Tech's catalog when I was seeing a link to just basic info
in our test catalog (for the same book), I stumbled on an interesting
twist to the situation.  It appears that the information returned by
the Book Viewability API can vary based on the query.  Consider these
7 static URLs for "Inside the Economist's Mind: conversations with
eminent economists".  (Note that using the standard number values
below with Book Viewability API code achieved the same results in
GBS;  the static URLs are just for ease of illustration.)











Only the last three URLs bring up the book with a preview
available.  The first four bring up the book, but without a preview
available.  The non-preview results show a 2006 pub date, while the
preview available results show a 2007 pub date, and I get the whole
pre-actual-publication brief vendor record problem (I think), but
what's disconcerting about this is that in WorldCat, the OCLC number
and LCCN above belong to the book with the 2007 pub date, which makes
one wonder how/where GBS is getting its info.  And since the title
search brings up just one record, why haven't the records without the
preview been ditched in favor of the one with the preview?

Is this just a case of you get what you pay for, or do they have
database integrity issues?  (Note that I haven't explored this
extensively so it's conceivable I just happened to stumble upon the
only book in GBS that exhibits this phenomenon.)

Bob Duncan


~!~!~!~!~!~!~!~!~!~!~!~!~
Robert E. Duncan
Systems Librarian
Editor of IT Communications
Lafayette College
Easton, PA  18042
[EMAIL PROTECTED]
http://www.library.lafayette.edu/

Re: [CODE4LIB] coverage of google book viewability API

[Tim Spalding]

>The general consensus around here seems to be even the minimal
records tend to have useful information, more so than if Google was
just repeating the catalog entry.

What bothers me here is that this isn't a "good enough" situation.
This isn't so-so information in an information poor environment. The
library has the book in all its glory, right there on the shelf ready
for the deepest, truest engagement.

As a former educator (okay, a TA, but I cared!), I believe that
learning often requires some effort—not involves but requires.
Engaging with something you don't know or understand is hard. Giving
students tools is good. But if you give them a tool simultaneously
super-easy and deeply deficient, too many will choose it over harder,
better tools. (Of course, getting a book off a shelf didn't *used* to
seem like hard work.) At some point, schools and libraries should
promote tools that are "good for you" over ones that aren't.

I don't want to overdo this. I built LibraryThing. I'm the farthest
thing from anti-web. But I balk at pushing empty Google Book Search
pages on students who could get off their rear ends and hold the book
in their hands two minutes later.

Tim

Re: [CODE4LIB] coverage of google book viewability API

[Edward M. Corrado]

I think Kyle brings up a great point. If we can get links to previews,
patrons will have a better understanding of what a book has to decide if
they want to go to another library on campus to look at it, request it to be
retrieved from off-site storage, ILL it, etc. This would be a very useful
thing to many patrons, I think.

Edward

On Wed, May 7, 2008 at 11:10 AM, Kyle Banerjee <[EMAIL PROTECTED]>
wrote:

> > 0.2% full text? Yowch!
> >
> >  Do academic libraries with full-text versions of the book on their
> >  shelves really want to point people to no-preview pages on Google.
> >  That's like a dating site with no photos of the members, and the
> >  profiles omit everything but their favorite potato variety.
>
> At first, this whole thing reminded me of a few years back when Amazon
> wanted libraries to load their inventory into catalogs. The idea was
> that letting people know an item that wasn't available in the library
> could be bought from Amazon was a useful service. Not too many
> libraries were takers.
>
> 0.2% might even be better and worse than it looks. Worse in the sense
> that it could be some random public domain garbage that there's little
> or no demand for. However, at the end of the day the percentage of
> books available full text is far less important than if the ones that
> are available are the ones that people want.
>
> On the other hand, if partial preview really is available for 6.2%, it
> could be very useful for helping people decide if they need a book at
> all. This has significant implications for ILL and circ costs over the
> long haul. Presumably, the number of books with a preview available
> will increase dramatically with time.
>
> kyle
>

Re: [CODE4LIB] coverage of google book viewability API

[Jonathan Gorman]

>
>The Google API returns sufficient information to NOT point people to
>books with no preview--it tells if full view, partial view, or no view
>is provided for a given book. I agree that our software that uses this
>API ought to either suppress no-preview books entirely, or present them
>in a particular way that makes it clear that they're no preview (if
>there's any point to this at all).

What I've done in my very rough demo is to say something like
"Full text available", "Parts of text available" and "Additional information 
available".  (Not exactly, but it's not worth the time to look it up).  The 
general consensus around here seems to be even the minimal records tend to have 
useful information, more so than if Google was just repeating the catalog 
entry.  The links don't even show up at all if there is no google information.

Jon Gorman

Re: [CODE4LIB] coverage of google book viewability API

[Jonathan Rochkind]

The Google API returns sufficient information to NOT point people to
books with no preview--it tells if full view, partial view, or no view
is provided for a given book. I agree that our software that uses this
API ought to either suppress no-preview books entirely, or present them
in a particular way that makes it clear that they're no preview (if
there's any point to this at all).

Jonathan

Tim Spalding wrote:

0.2% full text? Yowch!

Do academic libraries with full-text versions of the book on their
shelves really want to point people to no-preview pages on Google.
That's like a dating site with no photos of the members, and the
profiles omit everything but their favorite potato variety.

Doing LCCNs and OCLC numbers for older books is a must.

Tim

On Tue, May 6, 2008 at 7:32 PM, Godmar Back <[EMAIL PROTECTED]> wrote:


ps: the distribution of the full text availability for the sample
 considered was as follows:

 No preview: 797 (93.5%)
 Partial preview: 53 (6.2%)
 Full text: 2 (0.2%)

  - Godmar



 On Tue, May 6, 2008 at 6:09 PM, Godmar Back <[EMAIL PROTECTED]> wrote:
 > Hi,
 >
 >  to examine the usability of Google's book viewability API when lookup
 >  is done via ISBN, we did some experiments, the results of which I'd
 >  like to share. [1]
 >
 >  For 1000 randomly drawn ISBN from 3,192,809 ISBN extracted from a
 >  snapshot of LoC's records [2], Google Books returned results for 852
 >  ISBN.  We then downloaded the page that was referred to in the
 >  "info_url" parameter of the response (which is the "About" page Google
 >  provides) for each result.
 >
 >  To examine whether Google retrieved the correct book, we checked if
 >  the Info page contained the ISBN for which we'd searched. 815 out of
 >  852 contained the same ISBN. 37 results referred to a different ISBN
 >  than the one searched for.  We examined the 37 results manually: 33
 >  referred to a different edition of the book whose ISBN was used to
 >  search, as judged by comparing author/title information with OCLC's
 >  xISBN service. (We compared the author/title returned by xISBN with
 >  the author/title listed on Google's book information page.)  4 records
 >  appeared to be misindexed.
 >
 >  I found the results (85.2% recall and >99% precision, if you allow for
 >  the ISBN substitution; with a 3.1% margin of error) surprisingly high.
 >
 >   - Godmar
 >
 >  [1] http://top.cs.vt.edu/~gback/gbs-accuracy-study/
 >  [2] http://www.archive.org/details/marc_records_scriblio_net
 >






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




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

Re: [CODE4LIB] coverage of google book viewability API

[Godmar Back]

On Tue, May 6, 2008 at 11:02 PM, Michelle Watson
<[EMAIL PROTECTED]> wrote:
>
>  Is there something in the code that prevents the link from being
>  offered unless it goes to at least a partial preview (which I take to
>  mean scanned pages), or have I just been lucky in my searching?  I
>  can't comment on whether or not the 'no preview'  is useful because
>  every book I see has some scanned content.
>

Yes, in Annette's example, the link is only offered if Google has
preview pages in addition to the book information. See the docs on
libx.org/gbs for further detail (look for gbs-if-partial )

I had the same subjective impression in that I was surprised by how
many books have previews - for instance, if I search for "genomics" on
addison.vt.edu:2082, 24 of the first 50 hits returned have partial
previews. Incidentally, 2 out of the 24 lead to the wrong book.
This is why I sampled the LoC's ISBN set.

It's likely that there's observer bias (such as trying "genomics"),
and it's also possible that Google is more likely to have previews for
books libraries tend to hold, such as popular or recent books. (I note
that most of the 24 hits for genomics that have previews are less than
4 years old.)
Conversely, for those recent years, precision may be lower, with more
books misindexed.

 - Godmar

Re: [CODE4LIB] coverage of google book viewability API

[Michelle Watson]

I've just implemented this in the test catalogue at Deakin - taking
the instructions from Annette Bailey's ppt demo - and was surprised
at the number of hits.  And every time I clicked on the Google link I
was taken to a partial preview of the book.

Is there something in the code that prevents the link from being
offered unless it goes to at least a partial preview (which I take to
mean scanned pages), or have I just been lucky in my searching?  I
can't comment on whether or not the 'no preview'  is useful because
every book I see has some scanned content.

If 'no preview' means no scanned text but info. such as summaries and
reviews, then I agree that this information is really useful,
particularly for distance education students - about 40% of our total
student population - as it is often enough to determine if the book
is worth requesting.  There is a benefit for libraries too because
they're not wasting time sending out books that are irrelevant to the user.

Michelle

At 11:08 AM 7/05/2008, you wrote:

On Tue, 6 May 2008 20:24:47 -0400
 Tim Spalding <[EMAIL PROTECTED]> wrote:

0.2% full text? Yowch!

Do academic libraries with full-text versions of the book on their
shelves really want to point people to no-preview pages on Google.
That's like a dating site with no photos of the members, and the
profiles omit everything but their favorite potato variety.


I think that depends how you view information services to your patrons.  If
you think full text is the end-all-be-all, then I say double-yowch.  But if
you think there's more to information than full-text, then perhaps you might
think that patrons will benefit from the other information one can get via
GBS.  I've seen books that didn't have a preview or full text, but GBS offered
links to reviews, author interviews, ToCs, summaries, etc.

Bob Duncan

~!~!~!~!~!~!~!~!~!~!~!~!~
Robert E. Duncan
Systems Librarian
David Bishop Skillman Library
Lafayette College
Easton, PA  18042
[EMAIL PROTECTED]
http://www.library.lafayette.edu/


Michelle Watson, Web Cataloguing Librarian, Library
+ Deakin University Geelong Victoria 3217 Australia.
( Phone: 03 5227 8220 International: +61 3 5227 8220
( Fax: 03 5227 8000 International: +61 3 5227 8000
: E-mail: [EMAIL PROTECTED]
: Website: http://www.deakin.edu.au
Deakin University CRICOS Provider Code: 00113B (Vic), 02414F (NSW)

Important Notice: The contents of this email transmission, including
any attachments, are intended solely for the named addressee and are
confidential; any unauthorised use, reproduction or storage of the
contents and any attachments is expressly prohibited. If you have
received this transmission in error, please delete it and any
attachments from your system immediately and advise the sender by
return email or telephone.
Deakin University does not warrant that this email and any
attachments are error or virus free.

Re: [CODE4LIB] coverage of google book viewability API

[Lars Aronsson]

Godmar Back wrote:

> ps: the distribution of the full text availability for the sample
> considered was as follows:
>
> No preview: 797 (93.5%)

> >  For 1000 randomly drawn ISBN from 3,192,809 ISBN extracted from a
> >  snapshot of LoC's records [2], Google Books returned results for 852
> >  ISBN.

> >  I found the results (85.2% recall and >99% precision, if you allow for
> >  the ISBN substitution; with a 3.1% margin of error) surprisingly high.
> >
> >  [2] http://www.archive.org/details/marc_records_scriblio_net


But doesn't "no preview" mean books that Google haven't scanned?
If Google had downloaded [2] and incorporated the bibliographic
records in their collection, then the recall would have gone from
85 to 100 %.  How impressive is that really?

I'm prepared to be impressed if they have indeed scanned books for
6.5% of all ISBNs in the Library of Congress.  But that's not
really 85% recall.


--
  Lars Aronsson ([EMAIL PROTECTED])
  Aronsson Datateknik - http://aronsson.se

Re: [CODE4LIB] coverage of google book viewability API

[Godmar Back]

On Tue, May 6, 2008 at 8:24 PM, Tim Spalding <[EMAIL PROTECTED]> wrote:
> 0.2% full text? Yowch!
>
>  Do academic libraries with full-text versions of the book on their
>  shelves really want to point people to no-preview pages on Google.

In the example I show on the slides to which I pointed, the link to
Google is displayed only for books for which partial previews exist.
For this, the use case is clear - users can browse at least some pages
of the book before deciding to head to the library to check the book
out.

>
>  Doing LCCNs and OCLC numbers for older books is a must.

Yes, I'll repeat the experiments for LCCNs and OCLC numbers if I have
time. In the LoC dataset, only about 3.2 of about 7.5 million records
had ISBNs.

 - Godmar

Re: [CODE4LIB] coverage of google book viewability API

[Bob Duncan]

On Tue, 6 May 2008 20:24:47 -0400
 Tim Spalding <[EMAIL PROTECTED]> wrote:

0.2% full text? Yowch!

Do academic libraries with full-text versions of the book on their
shelves really want to point people to no-preview pages on Google.
That's like a dating site with no photos of the members, and the
profiles omit everything but their favorite potato variety.


I think that depends how you view information services to your patrons.  If
you think full text is the end-all-be-all, then I say double-yowch.  But if
you think there's more to information than full-text, then perhaps you might
think that patrons will benefit from the other information one can get via
GBS.  I've seen books that didn't have a preview or full text, but GBS offered
links to reviews, author interviews, ToCs, summaries, etc.

Bob Duncan

~!~!~!~!~!~!~!~!~!~!~!~!~
Robert E. Duncan
Systems Librarian
David Bishop Skillman Library
Lafayette College
Easton, PA  18042
[EMAIL PROTECTED]
http://www.library.lafayette.edu/

Re: [CODE4LIB] coverage of google book viewability API

[Tim Spalding]

0.2% full text? Yowch!

Do academic libraries with full-text versions of the book on their
shelves really want to point people to no-preview pages on Google.
That's like a dating site with no photos of the members, and the
profiles omit everything but their favorite potato variety.

Doing LCCNs and OCLC numbers for older books is a must.

Tim

On Tue, May 6, 2008 at 7:32 PM, Godmar Back <[EMAIL PROTECTED]> wrote:
> ps: the distribution of the full text availability for the sample
>  considered was as follows:
>
>  No preview: 797 (93.5%)
>  Partial preview: 53 (6.2%)
>  Full text: 2 (0.2%)
>
>   - Godmar
>
>
>
>  On Tue, May 6, 2008 at 6:09 PM, Godmar Back <[EMAIL PROTECTED]> wrote:
>  > Hi,
>  >
>  >  to examine the usability of Google's book viewability API when lookup
>  >  is done via ISBN, we did some experiments, the results of which I'd
>  >  like to share. [1]
>  >
>  >  For 1000 randomly drawn ISBN from 3,192,809 ISBN extracted from a
>  >  snapshot of LoC's records [2], Google Books returned results for 852
>  >  ISBN.  We then downloaded the page that was referred to in the
>  >  "info_url" parameter of the response (which is the "About" page Google
>  >  provides) for each result.
>  >
>  >  To examine whether Google retrieved the correct book, we checked if
>  >  the Info page contained the ISBN for which we'd searched. 815 out of
>  >  852 contained the same ISBN. 37 results referred to a different ISBN
>  >  than the one searched for.  We examined the 37 results manually: 33
>  >  referred to a different edition of the book whose ISBN was used to
>  >  search, as judged by comparing author/title information with OCLC's
>  >  xISBN service. (We compared the author/title returned by xISBN with
>  >  the author/title listed on Google's book information page.)  4 records
>  >  appeared to be misindexed.
>  >
>  >  I found the results (85.2% recall and >99% precision, if you allow for
>  >  the ISBN substitution; with a 3.1% margin of error) surprisingly high.
>  >
>  >   - Godmar
>  >
>  >  [1] http://top.cs.vt.edu/~gback/gbs-accuracy-study/
>  >  [2] http://www.archive.org/details/marc_records_scriblio_net
>  >
>



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

Re: [CODE4LIB] coverage of google book viewability API

[Zheng Xiao]

yes, I got the same question here. There is too little books in GB provide
full text and partial preview

On Wed, May 7, 2008 at 7:32 AM, Godmar Back <[EMAIL PROTECTED]> wrote:

> ps: the distribution of the full text availability for the sample
> considered was as follows:
>
> No preview: 797 (93.5%)
> Partial preview: 53 (6.2%)
> Full text: 2 (0.2%)
>
>  - Godmar
>
> On Tue, May 6, 2008 at 6:09 PM, Godmar Back <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> >  to examine the usability of Google's book viewability API when lookup
> >  is done via ISBN, we did some experiments, the results of which I'd
> >  like to share. [1]
> >
> >  For 1000 randomly drawn ISBN from 3,192,809 ISBN extracted from a
> >  snapshot of LoC's records [2], Google Books returned results for 852
> >  ISBN.  We then downloaded the page that was referred to in the
> >  "info_url" parameter of the response (which is the "About" page Google
> >  provides) for each result.
> >
> >  To examine whether Google retrieved the correct book, we checked if
> >  the Info page contained the ISBN for which we'd searched. 815 out of
> >  852 contained the same ISBN. 37 results referred to a different ISBN
> >  than the one searched for.  We examined the 37 results manually: 33
> >  referred to a different edition of the book whose ISBN was used to
> >  search, as judged by comparing author/title information with OCLC's
> >  xISBN service. (We compared the author/title returned by xISBN with
> >  the author/title listed on Google's book information page.)  4 records
> >  appeared to be misindexed.
> >
> >  I found the results (85.2% recall and >99% precision, if you allow for
> >  the ISBN substitution; with a 3.1% margin of error) surprisingly high.
> >
> >   - Godmar
> >
> >  [1] 
> > http://top.cs.vt.edu/~gback/gbs-accuracy-study/
> >  [2] http://www.archive.org/details/marc_records_scriblio_net
> >
>



--
Zhx
XmuLibrary

Re: [CODE4LIB] coverage of google book viewability API

[Godmar Back]

ps: the distribution of the full text availability for the sample
considered was as follows:

No preview: 797 (93.5%)
Partial preview: 53 (6.2%)
Full text: 2 (0.2%)

 - Godmar

On Tue, May 6, 2008 at 6:09 PM, Godmar Back <[EMAIL PROTECTED]> wrote:
> Hi,
>
>  to examine the usability of Google's book viewability API when lookup
>  is done via ISBN, we did some experiments, the results of which I'd
>  like to share. [1]
>
>  For 1000 randomly drawn ISBN from 3,192,809 ISBN extracted from a
>  snapshot of LoC's records [2], Google Books returned results for 852
>  ISBN.  We then downloaded the page that was referred to in the
>  "info_url" parameter of the response (which is the "About" page Google
>  provides) for each result.
>
>  To examine whether Google retrieved the correct book, we checked if
>  the Info page contained the ISBN for which we'd searched. 815 out of
>  852 contained the same ISBN. 37 results referred to a different ISBN
>  than the one searched for.  We examined the 37 results manually: 33
>  referred to a different edition of the book whose ISBN was used to
>  search, as judged by comparing author/title information with OCLC's
>  xISBN service. (We compared the author/title returned by xISBN with
>  the author/title listed on Google's book information page.)  4 records
>  appeared to be misindexed.
>
>  I found the results (85.2% recall and >99% precision, if you allow for
>  the ISBN substitution; with a 3.1% margin of error) surprisingly high.
>
>   - Godmar
>
>  [1] http://top.cs.vt.edu/~gback/gbs-accuracy-study/
>  [2] http://www.archive.org/details/marc_records_scriblio_net
>

[CODE4LIB] coverage of google book viewability API

[Godmar Back]

Hi,

to examine the usability of Google's book viewability API when lookup
is done via ISBN, we did some experiments, the results of which I'd
like to share. [1]

For 1000 randomly drawn ISBN from 3,192,809 ISBN extracted from a
snapshot of LoC's records [2], Google Books returned results for 852
ISBN.  We then downloaded the page that was referred to in the
"info_url" parameter of the response (which is the "About" page Google
provides) for each result.

To examine whether Google retrieved the correct book, we checked if
the Info page contained the ISBN for which we'd searched. 815 out of
852 contained the same ISBN. 37 results referred to a different ISBN
than the one searched for.  We examined the 37 results manually: 33
referred to a different edition of the book whose ISBN was used to
search, as judged by comparing author/title information with OCLC's
xISBN service. (We compared the author/title returned by xISBN with
the author/title listed on Google's book information page.)  4 records
appeared to be misindexed.

I found the results (85.2% recall and >99% precision, if you allow for
the ISBN substitution; with a 3.1% margin of error) surprisingly high.

 - Godmar

[1] http://top.cs.vt.edu/~gback/gbs-accuracy-study/
[2] http://www.archive.org/details/marc_records_scriblio_net