Openlibrary: Books API: Promote original work description to each edition

[ClaudiuCeia]

Description

I'm building a mobile app that allows people to scan ISBNs and get some info on the book that they've scanned. However, I'm not sure I can always get the description, particularly when the scanned ISBN is for an edition that "inherits" the description from the original work.

Evidence

I have ISBN: 9780091953638
For that, I can get data via:

• The API, using jscmd=data
• The JSON API, just appending .json to the normal book URL

However, none of the above see to return the "parent" OLID, or some way to get to https://openlibrary.org/works/OL17507444W.json, which is the data for the "parent object".

Admitedly, I can get the "works" array if I use jscmd=details but according to the docs, it's unrecommended/deprecated, and I'm not comfortable with using it in the app in that case.

Expectation

I expected more control over the available fields to be retrieved through the Books API. At the very least, the description field should always be available when jscmd=data, if it exists on either the specific edition or the parent work.

Proposal & Constraints

Adding the description field as described shouldn't break any existing integrations of the API.
For the long run, some control over the granularity of the returned data would be nice. I'd imagine something like:

https://openlibrary.org/api/books
      ?bibkeys=ISBN:9780091953638
      &fields=author,cover,description,...  // This can be an enum field documented in the API docs
      &format=json

[tfmorris]

That seems like a reasonable request (PR happily accepted), but in the meantime:

• https://openlibrary.org/books/OL26095592M.json does provide a link to the work as well (works key). Ignore the plural and array, it's always just a single work.
• jscmd=details is unlikely to go anywhere since we barely have resources to fix bugs, let alone remove features.

[ClaudiuCeia]

That seems like a reasonable request (PR happily accepted), but in the meantime.

Great to hear!

jscmd=details is unlikely to go anywhere since we barely have resources to fix bugs, let alone remove features.

Sorry to hear that! I'll see if I can jump in at any point, I'm in the same boat with some open source projects.

Feel free to close this issue, I can reopen it if I have a PR. Thanks!

[mekarpeles]

What rate will you need to hit this API?

Because assuming the rate is pretty light, you can also try:

https://openlibrary.org/isbn/9780091953638.json

This API resolves to the right edition + gives work-level IDs, but has the additional benefit that if the isbn is missing from our catalog, OL will attempt to pull it from other sources.

In the cases where we don't have the book, we're (internally) limited to ~1 request a second so if you expect that we'll need to just-in-time-fetch many of the books you lookup, this may not be the best option.

Unfortunately, it won't get you the work-level description :)

[xayhewalo]

this seems like a good first issue for some interested in Open Library's data.

@hornc Are there any plans to address this issue? Also, are you willing to be assignee?

[LeadSongDog]

@ClaudiuCeia
Any chance this app could also act as a data source? It might be helpful to have it able to capture images of cover, title page, t.p. verso, blurb, and/or TOC in cases where OL does not already have access to these. It would be way simpler to get someone to grab these images when the needful edition is already in their hand. Upload could wait until they are on WiFi if bandwidth is a concern.

[ClaudiuCeia]

@LeadSongDog - definitely!

The camera functionality was there from the start (for the barcode at least). I'm just worried about folks taking bad photos (blurry, bad light, etc)

Unfortunately, my time has been very limited and I had to put this project aside for a while. If I remember correctly, last I worked on it I also integrated the Google Books API to fill in missing data. and properly attributed each piece of data displayed.

[ClaudiuCeia]

In the cases where we don't have the book, we're (internally) limited to ~1 request a second so if you expect that we'll need to just-in-time-fetch many of the books you lookup, this may not be the best option.

Sorry, I must've missed this! Thanks for the heads-up - will keep in mind for when I manage to work on the app again. Does this limit apply to _all_ requests? How comes it's so low, is it due to the third party sources?

[xayhewalo]

Assigning @hornc per slack discussions since this is data related