I’d also like to propose a new feature if it would be simple to implement. I’d like to be able to look up records by Hathi Trust ID.

I’m building a simple web client for looking up detailed item information. The target audience is internal staff working on the bibliographic issues for our Hathi Trust submissions. I’d like users to be able to query by Hathi ID along with the other identifiers. If they query by Hathi ID, it would be nice to at least show the title, and possible tie the item to other information by using the returned identifiers in the record like the OCLC number.

What’s the difference between asking for?

?yourID1=oclc:00470409|lccn:68001537&yourID2=oclc:67890987|isbn:987652348X

Or asking for:

?yourId1=oclc:67890987&yourId2=lccn:68001537&yourId3=oclc:67890987&yourId4=isbn:987652348X

What does the pipe grouping do for you? Maybe this is related to the solution #3 vs #4 thing, cause maybe I can get what I want by constructing my request the right way even if you do #4. But the pipe grouping thing kinda seems like unneccesary complexity to me.

A middle ground is that you can rank them internally, and put the one you think is ‘best’ first. So the client can easily just take the first one and ignore the others. But I as a client am going to sometimes want to see all matches, not have the ones your algorithm considered ‘not as good’ hidden from me.

Perhaps the “records” data should also provide a “recordURL” It would be analogous to “itemURL” in that the API would be responsible for formatting the URL to a record. Then every consumer of this information would not have to know the “how to link to a record” convention, just as they do not need to know how to construct the handle URL for an item.

One bit of clarification: in the text under “Making the request,” I read that to mean that these two URLs return identical informatioon: http://catalog.hathitrust.org/api/volumes/oclc/00470409.json http://catalog.hathitrust.org/api/volumes/oclc/470409.json

In the multivolume request example, did you mean “…yourID2=oclc:67890987|isbn:987652348X”, with a “|” rather than a “&”?

On the final question about when the records don’t match, I’m leaning toward #4, the best matches. I’m a little concerned about cases where some important number changes, like when OCLC records merge. (or an ISBN is corrected or whatever.) So if I send OCLC, LCCN, and ISBN and there’s no matching OCLC number, would the service then fall back to LCCN? Or would a miss on the OCLC mean the whole request fails? In any case, experience with the new API will tell us whether the matching needs to be tweaked.

But if I’m sending LCCN=a&ISBN=b, probably because I think those both refer to the same ‘thing’, and you have multiple records that refer to that ‘thing’ — I want to see them all. I don’t want you to just pick an arbitrary one and hide all the rest.

I mean, if I just sent an ISBN, and you had two records with that ISBN (quite possible), you’d give me both of them, right, not just pick one you think is ‘best’?

Also, despite the fact that I asked for it, you’re right that that records stuff is confusing. I’m confused about the difference between http://hdl.handle.net/2027/mdp.39015079651611 and http://catalog.hathitrust.org/Record/003384758

I guess in part because HT is still working out. There doesn’t seem to be any reason to ever send the user to that /Record url, since it doesn’t even point to the item and provide access to searching or full text if available!

I still tend to err on the side of including extra info, cause someone might need it, and when they do you’re unlikely to have time to go back and add it. On the other hand, maybe this is too confusing.