The use case is that software that's looking at that page can easily see 
that there's a json representation of it available, and where to get it. 
This is not for raw human use, it's for software use.

Examples of software that might be 'looking' at an OpenLibrary item 
detail page include:
*  a browser plug-in like LibX, looking over the user's shoulder as he 
browses the web.
* A web spider of some kind
* An OAI-PMH client of an OAI-PMH feed that includes OpenLibrary pages. 
(feed provided by OL/IA itself, or an OAI-PMH feed provided by a third 
party but indexing OL content).
* Many more uses that we can't predict right now, but which people will 
come up with when the architecture is there.

The link that Ed suggests is to advertise in a standard 
software-understandable way "There is a JSON representation of this 
resource available." A button that can be seen by humans may or may not 
be a good idea, depending on if you think humans are interested in 
clicking to get a JSON representation (I doubt it).  The link Ed 
suggests is for a different purpose, for automated discovery of the json 
representation of the resource represented by the url.


Karen Coyle wrote:
> Ed Summers wrote:
>> I guess the main thing I wanted to
>> communicate is that you could simply add:
>>   <link rel="alternate" type="application/json"
>> href="{open-library-id}" />
>> to the <head> element in OpenLibrary HTML pages for books, and that
>> would go a long way to making machine readable data for books
>> discoverable by web clients.
> Ed, the first thing that comes to my mind when I see this is: button. 
> Unless folks will be blindly crawling the OL* I don't know how they'll 
> get to a particular page to execute this code, except by being a 
> person searching and getting the web page. (If they are using the 
> search API they get back a list of IDs from which they'd create one or 
> more 'get' commands like this one.) A download button on the page 
> would make sense, but mainly if it downloaded into a usable format 
> (EndNote, MARC). All this to say that I don't get what the use case is 
> for this particular bit of code -- but I'm assuming you had one in 
> mind. Please do tell!
> * If anyone wants the whole OL database, json dumps are available: 

Jonathan Rochkind
Digital Services Software Engineer
The Sheridan Libraries
Johns Hopkins University
rochkind (at)