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]
