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. I could learn more, but in the interests of making the API as accessible to developers as possible, perhaps it's preferable to make the values more self-explanatory? 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. 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). ________________________________________ From: [email protected] [[email protected]] On Behalf Of Anand Chitipothu [[email protected]] Sent: Sunday, November 07, 2010 10:03 AM To: Open Library -- technical discussion Subject: Re: [ol-tech] OL metadata and Daisy books On 07-Nov-2010, at 8:04 PM, Jonathan Rochkind wrote: > I am not exaclty sure what Tim is doing, but for my purposes it's really > really important for the OpenLibrary APIs to tell me what formats a book is > available in (if there are scans, and the URL(s) to get there; if there is a > in-browser reader, and the URL to get there, etc). I agree. How about extending the OL Books API to provide "preview": "printdisabled" when only daisy format is available and "preview": "borrow" when the book is only available to borrow? > This is (or would be if it were simple) one of the most common use cases for > OL, no? > > As far as dumps - - for my apps I generally prefer per-item APIs to dumps. > But if I were using dumps, I would not want to have to take two dumps and > merge them; it's enough software work already to regularly update and ingest > one dump. If the second dump is just provided over email, rather than at a > stable URL whose fetching can be automated, it is especially not useful. > Data dumps to be useful on my end, my end needs a way to regularly update in > an automated fashion, since a data dump is just a particular snapshot in time. Some people prefer not to rely on third-party services in production and maintain a copy of the data in their system. I think important to provide dumps to enable bulk access to the data available through the API. 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]
