DLF Discovery API comments

The DLF ILS Discovery Interfaces document has been revised, and the revised draft is  open for comments.

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.

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.

5.3.2. HarvestExpandedRecords

“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).

General 5.3

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?

This entry was posted in General. Bookmark the permalink.

2 Responses to DLF Discovery API comments

  1. David Kennedy says:

    Comment on 7.2.2 – Shibboleth was actually considered from the beginning. That is why there is a 7.2.1, LookupPatron, for the case where authentication is done by some external authentication source, and the calling application knows only of a user identifier and not of a user’s logon credentials. With LookupPatron, the user identifier known to the calling application does not need to be the primary patron identifier needed for successive calls, so long as the identifier can be resolved by the ILS. For instance, Shibboleth/openid/cas may return a directory id to the calling application, and the calling application may use LookupPatron to retrieve the ILS patron identifier from the ILS to then place a hold request using HoldTitle with the ILS patron identifier.

    Comment on 7.2.3 / 7.2.4 – The reason for the separate operations is that one has a smaller and more simplified structure for request/response. It is possible that it makes more sense to combine these two functions into one. Admittedly, this is something that the group considered, but did not spend a lot of time on.

  2. John Mark Ockerbloom says:

    Thanks for your comments. Here are my quick replies:

    5.3.1: HTTP not adding significant overhead: That really depends on the operation– I’ve seen cases where it does (e.g. building indexes via direct Lucene method calls vs. HTTP Solr calls). I’ve revise the language slightly, though (for this function and the ones that follow) to remove the implication that there is *necessarily* a big performance difference.

    As it stands, HTTP-based bindings are required for all the Level 1 operations, so I think we’ve pretty clearly endorsed web-based accessibility there. I don’t want to say that this is the only way to go, however. There may be good reasons to support a closer-to-the-metal binding as well.

    5.3.2: Our requirement for MARC holdings applies only if the ILS already maintains or supplied MARC holdings records. I’ll revise the language a bit to make it clear that we strongly encourage the provision of holdings languages in other formats if they’re available.

    5.3: Well, “until” support is actually required by the required OAI-PMH protocol anyway; I’ll note this explicitly in the document, and also note that we encourage it in other bindings.

    6.3.1: “bib” or “item” is now explicitly mentioned.

    6.3.6: I’ll add a comment to that effect.

    I see Dave Kennedy has already replied to the section 7 comments, so I’ll leave those for now.

    Many thanks for your suggestions!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s