I think the answer is, there is another API, the "REST" one, but it won't even tell me _anything_ about whether digitized copies are available?
http://openlibrary.org/books/OL6511983M.json My suggestion is still that I think discovering online copies at the IA is one of the most attractive use cases for the OL/IA, and I'd encourage you to provide for the API to support it. I'm beginning to have deja vu, I think maybe we've had this same conversation before a year or two ago? My use case: Using _some_ simple OL/IA api, look up a book by isbn, lccn, or any other identifying numbers you may have. If I get a hit in the OL database, find out easily from the API if online versions are avaialable at the IA, and if so what URL they can be accessed at. While this information is available on the HTML OL page for an edition, I believe maybe there's no way to get it from an API at all? I guess I could find the OL identifier from the API, and then screen-scrape the HTML? ________________________________________ From: [email protected] [[email protected]] On Behalf Of Jonathan Rochkind [[email protected]] Sent: Sunday, November 07, 2010 10:25 PM To: Open Library -- technical discussion Subject: Re: [ol-tech] OL metadata and Daisy books I guess the Google Books-compatible API is not actually sufficient to give me what I'd like to see to power my apps, then? I'd really like to see the API tell me which formats are avaialable, and ideally give me direct URL to those APIs. So I guess I'm requesting a non-GBS-compatible API? I'm not sure if it's completely predictable exactly what formats will be available if "preview=true", that's the root of the problem right? Whether you've got a data feed or a per-item api call. Could you leave the somewhat-confusing GBS-compatible lines, but add other lines too? Like "formats:pdf,epub,daisy,html" (tell you what formats are available, you still need to figure out the URLs yourself), or "pdf:http://something";, "html:http://etc";. Or perhaps using IANA/MIME content types instead of those nicknames. Or is there another API in addition to the GBS-compatible one, and maybe that's the one I'm really asking for this info to be added to? (or maybe it's even already there?) I admit I have trouble keeping what OL APIs are available and what they do straight, perhaps I've gotten confused. ________________________________________ From: [email protected] [[email protected]] On Behalf Of Anand Chitipothu [[email protected]] Sent: Sunday, November 07, 2010 8:06 PM To: Open Library -- technical discussion Subject: Re: [ol-tech] OL metadata and Daisy books On 08-Nov-2010, at 4:07 AM, Jonathan Rochkind wrote: > Yep, both dumps AND per-item api access are important, agreed. Ideally with > as consistent a metadata vocabulary between the two of them as possible, to > lessen confusion. > > I may not realize all the functions available from OpenLibrary/IA. I > actually don't know what the daisy format is, which is perhaps why I don't > know what "printdisabled" means exactly. (The daisy format is something that > allows.... something other than printing?). Nor do I understand what kind > of "borrowing" can be done from IA/OL. Daisy is an audio book format. IA has a restricted collection of scanned books available for blind people. More details here: http://www.archive.org/details/printdisabled Open Library allows downloading these books. Here is a sample: http://openlibrary.org/books/OL24218576M/A_romance_on_three_legs And yes, OL has a small collection of books that can be borrowed. Here is the list of them: http://openlibrary.org/subjects/lending_library And here is a sample one: http://openlibrary.org/works/OL52232W/The_science_of_life > I could learn more, but in the interests of making the API as accessible to > developers a possible, perhaps it's preferable to make the values more > self-explanatory? I agree. > What I'm interested in is if I can direct the user to an online copy of the > book, and in what formats. Because IA offers potentially a variety of formats > for each title, from PDF to eBook to the only HTML viewer (or perhaps even > several sorts of online HTML views?) So for starters, "preview" doesn't > seem like the right word to describe that (what's the "pre" part there?). > Secondly, it is sometimes kind of tricky/confusing to figure out exactly what > URL to get a given format at, even if one knows it's available. That terminology is borrowed from Google Books API. OL Books API is designed to be compatible with it. One can replace the Google Books API URL with OL Books API URL without any additional code changes. > So how about a line for each format available, with the URL to get that > format? If that is too lengthy for a 'data dump', then perhaps instead just > a line for each format with 'true' and 'false' (or 'true' vs the line is not > in the repsonse at all), you'd still need external knowledge to to figure out > once you know 'true' how to turn that into a URL to actually GET to the > format. For a per-item API, however, I think actually including the URL is > better, and kind of more in line with REST-ish prinicples where the response > should be self explanatory and not require outside knowledge to figure out > how to contruct the URL to the related resources. (Which also means if the > URL changes, then there isn't any client logic that needs to be changed, > because the only client logic is 'get the URL from the response', so as long > as the response returns the right URL it doesn't matter if it's different > from last week). Even we realized this recently. We started including URLs in the new APIs. You must have noticed that in the new Books API. For example, jscmd=data includes urls for authors. Anand _______________________________________________ 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] _______________________________________________ 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] _______________________________________________ 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]
