This is a great document. A lot of time was clearly put into it, by people who know what they’re doing, both in terms of what the ILS (or similar system) needs to provide, and what formats/methods it makes sense to provide it in.
I think it will be especially useful to people evaluating new ILS (or back-end ILS replacement) software–it gives us an easy way to evaluate whether a particular back-end offers the hooks needed to loosely couple with front ends, without every evaluator having to re-invent the wheel.
But of course, I have some comments.
5.3.1, HarvestBibliographicRecords (Level 1)
“Other bindings: Since this is an expensive, data-intensive operation, it may also be useful to have more specific library implementations closer to the ILS. A Java or Perl object library could be more efficient, for example. However, if it is not unacceptably inefficient, a web service binding (whether OAI-PMH or some other implementation) is likely to be more portable and robust. “
I realized reading this that I had assumed all of these operations HAD to be web services (in the sense of something over HTTP). I was surprised to see this wasn’t a requirement. Reading through the rest of the document, I think that the real reason it’s not a requirement is to allow for ‘legacy’ protocols like NCIP etc.
The efficiency thing is a total red herring, in my opinion, as are the mentions of Java or Perl libraries. A web interface is necessarily not significantly less efficient than those, and I can prove it if you don’t believe me. (Just take your hypothetical java or perl library, and wrap it in a simple http server that listens on port 80, takes arguments in url query string, and returns the responses of the library over the wire. This adds no significant overhead. QED. ) I’d take out those references.
I’d also make it clear for the entire document that a web service binding (in the sense of something, anything, over HTTP) is STRONGLY PREFERRED.
I think maybe there has always been a change to this particular operation to require OAI-PM, but as a general rule I think the spec should say that a HTTP service binding is preferred for ALL operations. Be in the web world.
“A list of expanded records, including their bibliographic identifiers. The expanded
records must include (where available):
• The bibliographic identifier
• The bibliographic record
• Any associated MARC holdings records (and their identifiers) “
Wait, is this saying that holdings information MUST be returned in the MARC format? Doesn’t that kind of go against the principle of not requiring specific ‘bindings’ and formats, especially legacy ones that may never have worked well?
I’m not sure MARC holdings format is necessarily the best, it’s kind of a pain. Should you at least make clear that alternate formats for holdings data are allowed too? One I’d suggest listing as a possibility is ONIX Serials Coverage Statement, which I think is very suitable for describing serial holdings even thought it wasn’t designed for that. Only for serial holdings, but everything else does such an insufficient job of serial holdings, it’s worth mentioning even though it’s scope is only serials. http://www.editeur.org/onixserials/ONIX_Coverage09.html
This applies to 5.3.4 HarvestHoldingsRecords (Level 2) too. Over in 6.4.1 they describe various holdings formats, and here seem to be implying that MARC holdings isn’t necessarily required. I’d add ONIX SC to that list myself, but maybe I’m just crazy for being so crazy about ONIX SC. ONIX SC is really nice! (Our current methods of tracking and revealing serials holdings are totally broken, giving software no way to identify if a particular volume/issue is held).
In all harvest operations, I’d add simply that the ‘until’ argument is STRONGLY recommended. It makes so much more possible.
6.3.1 GetAvailability (Level 1)
“id_type: (type string; required): defines the type of record identifier being
used in the request. ”
I don’t understand what this means. Ah, bib or item? Say that, “type (bib or item)”
6.3.6 SearchCourseReserves (Level 4)
“While not all course reserve systems are managed through the ILS, this section of the API is relevant for those institutions where it is. “
Add: “Or any other system whether ILS or not that may manage course reserves.”
As we move towards a more componentized world instead of a monolithic ILS world, we’ll have individual systems that only implement part of the functionality of the ILS. I’m assuming about all these specs that a system which only implemented one component of traditional ILS functionality would still be encouraged to implement the applicable operations–these standards are, in my mind, written in part to help bridge the gap between our legacy ILS world and a system with more loosely coupled components.
7.2.2 AuthenticatePatron (Level 3)
username/password supplied doesn’t allow shibboleth/openID-type logins where the username/password are not seen by either the client or the ILS-server, but mediated by a third party identity provider. It’s a bit tricky to figure out how to use either openID or shibboleth with a web services model, but possible. I understand the team isn’t spending much time on level 3 operations now, but perhaps it could say here that while we’re not sure how to do it yet, we anticipate enhancing this definition at a later date to allow/support shib/openid style authentication.
7.2.3 GetPatronInfo (Level 3) / 7.2.4 GetPatronStatus (Level 3)
I don’t understand why these are two separate operations, instead of just one. But there’s probably a good reason?