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
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
The OpenLibrary.org http://www.openlibrary.org team has just finished
its latest release on the long path towards one web page for every book
ever published.
What's new?
* added another 6 million book records (13.4 million total) with 18
million more records waiting to be integrated
Original Message
Subject:[ol-tech] Latest OpenLibrary.org release
Date: Wed, 07 May 2008 11:20:08 -0700
From: Alexis Rossi [EMAIL PROTECTED]
To: [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED]
The OpenLibrary.org
* built an API http://www.openlibrary.org/dev/docs/api to the data
which allows you to query the database for objects matching
particular criteria or to GET an object from the database
Not SRU? Any reasons why you rolled your own?
Rob
I'm the only non-techie on the team, so I don't know that much about
SRU. (Our head programmer lives in India, and is presumably asleep at
the moment, otherwise I'd ask him!) Is it an interface that is used
primarily by libraries? We are definitely hoping that our API will be
used by all
I'm the only non-techie on the team, so I don't know that much about
SRU. (Our head programmer lives in India, and is presumably asleep at
the moment, otherwise I'd ask him!) Is it an interface that is used
primarily by libraries? We are definitely hoping that our API will be
used by all
SRU is crap, in my opinion -- overengineered and under-thought,
incomprehensible to non-librarians and burdened by the weight of history.
The notion that it was designed to be used by all kinds of clients on all
kinds of data is irrelevant in my book. Nobody in the *library world* uses
it, much
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
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
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
I shouldn't respond to such blatant trolling, but heh...
On Wed, 7 May 2008, Casey Durfee wrote:
SRU is crap, in my opinion -- overengineered and under-thought,
incomprehensible to non-librarians and burdened by the weight of history.
What is so incomprehensible about it? Is it the fact it
Nobody in the *library world* uses
it, much less non-libraries.
Ironically, I was just checking email in between using the WorldCat SRU server.
In addition to the systems Rob mentioned, there are also article databases like
JSTOR and Springerlink that implement SRU, and every metasearch
13 matches
Mail list logo
