+1 Sounds good to me On Thu, May 26, 2011 at 10:29 AM, Jonathan Rochkind <[email protected]>wrote:
> Well, I mean, what I want as a client is a cover image if one exists for > any ISBN. Duplication will exist, data will never be perfect, although we > can hope OL's algorithms will get better at detecting and merging em, > realistically there's always going to be some duplication, even if only > intermittent on a given set. > > So either it's done on the server-side, possibly pre-computed, so you can > make one call and get a cover if available anywhere. Or you've got to do it > client side, even though it's a pain. > > I haven't looked at the API in a while, but if were designed so you could > get multiple hits back from an ISBN query, and each hit in the single > original response included a cover URL if available (or a Y/N on whether > cover is avail and the ID you can use to construct the URL) -- then it would > still only be one HTTP request. More than one HTTP request slows down my > app, but one HTTP request with this information, it won't effect performance > and won't really be that hard on the client side to just look through the > responses for the first cover. > > So ideally I'd hope OL API can at least support that, with one HTTP call? > > ________________________________ > From: [email protected] [[email protected]] on behalf > of John Miedema [[email protected]] > Sent: Wednesday, May 25, 2011 8:50 PM > To: Open Library -- technical discussion > Subject: Re: [ol-tech] book cover images that disappear > > The nice thing about the newest books API is that provides a single call > for all necessary data. OB3 moved to this api for that reason, helping to > resolve performance problems that came from making additional calls. I'm not > sure I would want to build extra calls and looping in my client code to > resolve what is really a data duplication issue. That said, I guess it would > be better to have some cover than no cover. > > > > On Wed, May 25, 2011 at 7:06 PM, Jonathan Rochkind <[email protected] > <mailto:[email protected]>> wrote: > Is there still a non-deprecated cover-image-specific API? > > For cover images specifically, it would clearly be optimal if an ISBN > lookup returned a cover image from ANY OL record having that ISBN listed, if > multiple then pick the most recent or the oldest or whatever. > > I would imagine there already is an OL general purpose API that returns > multiple hits for an ISBN lookup, when there are multiple hits? If so, when > writing a client app, the best bet would be to use that one, and have your > client code look through all the hits until a cover is found, instead of > stopping at the first one. > > ________________________________ > From: [email protected]<mailto:[email protected]> [ > [email protected]<mailto:[email protected]>] on behalf > of [email protected]<mailto:[email protected]> [ > [email protected]<mailto:[email protected]>] > Sent: Wednesday, May 25, 2011 6:40 PM > To: Open Library -- technical discussion > Subject: Re: [ol-tech] book cover images that disappear > > Thanks Anand and George, the second ISBN is the newer record, and as you > said, that's what is getting picked up. I think the right answer is for the > API to return the older record. My reasoning is that an entry of a duplicate > ISBN represents a shoddier entry because whatever process was used to enter > it (manual or automatic) should have checked for duplicates, and since it > did not, it is less trustworthy. Perhaps a thin argument, but it's just a > suggestion. Not sure what else you would do. Maybe the condition is rare > enough not to worry about. I will leave in your good hands. I got around > this by using the OLxxxx ID instead, which is unique. John > > > 2010/9/26 John Miedema <[email protected]<mailto:[email protected]>>: > > > Great. Re: the revision, > > > > > > For OB version 3, all OL IDs will get passed in as "OLID:12345" so that > > > would look like "OLID:12345@9". Right? > Yes. > > I think I can even support OLID:12345@2010-09-23, but I'll try keep > that a feature for later. > > > > Will that work for other IDs that can be used in version 3: e.g., > > > ISBN:23456@9, LCCN:34567@9, and OCLC:456789@9? > No. It won't work for ISBNs because the OLID returned by the ISBN > query might change over time. > > Anand > > > > > > On , Anand Chitipothu <[email protected]<mailto:[email protected]>> wrote: > > Hi John, > > > > > > Open Library is showing 2 books with ISBN 9780307387172. > > > > > > http://openlibrary.org/search?q=9780307387172 > > > > > > The covers.openlibrary.org<http://covers.openlibrary.org> picks the > first one with cover. Which seems to be working fine. > > > > > > http://covers.openlibrary.org/b/isbn/9780307387172-M.jpg > > > > > > The OL Books API picks any one book with the matching ID. It looks like > the Books API is picking the book without the cover and that is creating you > the trouble. > > > > > > http://openlibrary.org/api/books?bibkeys=ISBN:9780307387172 > > > > > > I searched for "9780307387172" in OL dump created on 2010-11-30 and found > just one entry with 6 revisions and last modified on 2010-08-12. > > > > > > /type/edition /books/OL9434361M 6 > 2010-08-12T06:30:18.650706 {"number_of_pages": 224, "weight": "8 > ounces", "covers": [1165319], "latest_revision": 6, "edition_name": "Reissue > edition", "title": "Into the Wild (MTI)", "languages": [{"key": > "/languages/eng"}], "subjects": ["Discovery And Exploration (General)", > "Outdoor Life", "Travel", "Biography / Autobiography", "Travel - General", > "Regional Subjects - West", "Travelers", "Travel / Adventure", "Special > Interest - Adventure", "Adventure and adventurers", "Alaska", "Biography", > "United States", "Wayfaring life", "West (U.S.)"], "type": {"key": > "/type/edition"}, "physical_dimensions": "8 x 5.1 x 0.7 inches", "revision": > 6, "publishers": ["Anchor"], "physical_format": "Paperback", > "last_modified": {"type": "/type/datetime", "value": > "2010-08-12T06:30:18.650706"}, "key": "/books/OL9434361M", "authors": > [{"key": "/authors/OL237257A"}], "created": {"type": "/type/datetime", > "value": "2008-04-30T09:38:13.731961 > "}, "identifiers": {"goodreads": ["441013"], "librarything": ["1199218"]}, > "isbn_13": ["9780307387172"], "isbn_10": ["0307387178"], "publish_date": > "August 21, 2007", "works": [{"key": "/works/OL1974535W"}], > "first_sentence": {"type": "/type/text", "value": "Jim Gallien had driven > four miles out of Fairbanks when he spotted the hitchhiker standing in the > snow beside the road, thumb raised high, shivering in the gray Alaska > dawn."}} > > > > > > > > The dates seem to be matching with the history view. > > > > > > http://openlibrary.org/books/OL9434361M/Into_the_Wild_(MTI)?m=history > > > > > > This indicates that there is no data loss. > > > > > > Anand > > > > > > > > On 25-May-2011, at 6:08 PM, John Miedema wrote: > > > > Hi George. I had an OpenBook pointer to ISBN 9780307387172 on November > 11, 2010. The record originally had no cover image for OpenBook, so I added > one and could confirm the image was there in my WordPress post using > OpenBook. I'm also certain I add an author to the record and it is also > gone. It has happened before, over a few years, and always for cover images > that I manually added. I don't often have to add new covers so I don't have > many examples, but it is always for these records. The wipe usually happens > some weeks or even months after I modified the record. Hope that helps, John > > > > > > > > > > On Tue, May 24, 2011 at 1:23 PM, George Oates [email protected]<mailto: > [email protected]>> wrote: > > > > Hi John, > > > > > > > > Odd - There's no note of you in the edit history there... Are you sure it > was > > > > that particular edition? > > > > > > > > g > > > > > > > > On 5/23/11 8:13 PM, John Miedema wrote: > > > > > Hi folks, I have noticed on several occasions that book covers I > manually add > > > > > will disappear later on. > > > > > > > > > > Here's one that disappeared. Can't say exactly when. > > > > > > > > > > http://openlibrary.org/books/OL24645176M/Into_The_Wild > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Ol-tech mailing list > > > > > [email protected]<mailto:[email protected]> > > > > > http://mail.archive.org/cgi-bin/mailman/listinfo/ol-tech > > > > > To unsubscribe from this mailing list, send email to > [email protected]<mailto:[email protected]> > > > > _______________________________________________ > > > > Ol-tech mailing list > > > > [email protected]<mailto:[email protected]> > > > > http://mail.archive.org/cgi-bin/mailman/listinfo/ol-tech > > > > To unsubscribe from this mailing list, send email to > [email protected]<mailto:[email protected]> > > > > > > > > > > -- > > John Miedema - [email protected]<mailto:[email protected]> - > http://johnmiedema.ca - 613-366-7960<tel:613-366-7960> > > > > > > > > > > > > > > _______________________________________________ > > Ol-tech mailing list > > [email protected]<mailto:[email protected]> > > http://mail.archive.org/cgi-bin/mailman/listinfo/ol-tech > > To unsubscribe from this mailing list, send email to > [email protected]<mailto:[email protected]> > > > > > > > > > _______________________________________________ > Ol-tech mailing list > [email protected]<mailto:[email protected]> > http://mail.archive.org/cgi-bin/mailman/listinfo/ol-tech > To unsubscribe from this mailing list, send email to > [email protected]<mailto:[email protected]> > > > > -- > John Miedema - [email protected]<mailto:[email protected]> - > http://johnmiedema.ca - 613-366-7960<tel:613-366-7960> > > _______________________________________________ > Ol-tech mailing list > [email protected] > http://mail.archive.org/cgi-bin/mailman/listinfo/ol-tech > To unsubscribe from this mailing list, send email to > [email protected] > -- John Miedema - [email protected] - http://johnmiedema.ca - 613-366-7960
_______________________________________________ Ol-tech mailing list [email protected] http://mail.archive.org/cgi-bin/mailman/listinfo/ol-tech To unsubscribe from this mailing list, send email to [email protected]
