Umlaut in terms of DLF ILS Discovery API model

I realized it would be useful to analyze Umlaut in terms of the DLF ILS Discovery API model.

Umlaut needs to talk to my OPAC/ILS in order to display local holdings, with availability and location, as well as a button to place a request/hold with the ILS.

DLF Task Force Model Functions Used

What Umlaut currently does is described very well by the DLF task force model functions, which I’ll list in the order that Umlaut calls them:

6.3.3 Search (Level 2) (Identify ILS records with certain ISBNs, ISSNs, LCCNs, OCLCnums, or as a last resort title and author keyword matches–along with specifications of format limits in some cases, only serials, etc.).

6.3.1 GetAvailability (Level 1) [Specifically of type ‘item’] (Figure out location and availability for items for the bibs identified previously, to display).

8.3.1 GoToBibliographicRequestPage (Level 1) (Umlaut puts a ‘request’ button on the Umlaut page, and sends user to the ILS/OPAC to actually make the request, when clicked).

Also, Umlaut doesn’t currently do this, but I would love it to use:

7.2.5 GetServices (Level 3)  (To figure out whether the ‘request’ button should even be displayed in the first/place, and possibly additionally tell the user more about what they can with this item possibly not involving the ‘request’ button).

I haven’t implemented that mainly because hacking it into Horizon is a pain (although not impossible with direct-sql access to the underlying Sybase db, as you have with Horizon. I understand what it would take, it would just not be fun).

Interesting that one Level 2 service is required for Umlaut to do what it does.

Suggests Umlaut Implementation Improvements

I hacked all these in before the DLF recommendations even existed, so they aren’t written in terms of the DLF services. (And it’s to the DLF reccommendations credit that they properly and accurately describe my real world use case).  But it strikes me that it would be of benefit to re-write the Umlaut code so it is specifically factored and described in terms of those services. It would make it very clear what needs to be done to add support for a new ILS/OPAC too—add classes that can provide that search(), getAvailability(), and goToBibliographicRequestPage() functionality for your particular ILS–and already written common Umlaut code will take care of the rest.   If your ILS miraculously already supported the DLF functionality, that might already be done for you, but if not, you know exactly what you need to write, hacking into your ILS somehow.

(Incidentally, I personally suspect that even in a hypothetical future case where your ILS claims to support those functions, there will be enough idiosyncracies that you’d still need to write some specific Umlaut code to rationalize and normalize things a bit. This doesn’t disturb me greatly though, one step at a time. Realistic expectations.)

Ross was actually already moving the Umlaut code in that direction of having clearly defined ILS-specific functional modules for an ILS, that are then used by common Umlaut code–although he too was writing before the DLF task force, so it wasn’t written in exactly those terms. The DLF task force spec is actually an aid in architecting such a system, they’ve already helped you factor out your functionality.  But anyway, I inherited Umlaut from Ross with this aspect being not entirely finished, and for expediency didn’t finish carrying out that direction. But I ought to refactor Umlaut in that direction, specifically around the DLF task force model. If any other institution actually expresses a real interest in Umlaut, that’ll probably be my motivation to do so.

Kinks

There are a few practical kinks that would keep the code from being a perfect 1-to-1 mapping of the DLS task force model functions. For instance, in a single request to HIP for ‘6.3.3 Search (Level 2)’, I actually get back complete bib records from HIP, not just local bib #s. And HIP is slow enough at all this, that you really wouldn’t want to make a second request to HIP just for the sake of sticking to the model. So I imagine an Umlaut adapter for 6.3.3 Search could optionally return MARC bibs, in which case Umlaut woudln’t need to make a call to etc.) 6.3.1 GetAvailability — or could just return bibIDs, sticking to the DLF task force model, in which case Umlaut would proceed to making a seperate 6.3.1 GetAvailability call after all. No big deal.

Somewhat more troubling…

Also, GetAvailabilty is going to be a little bit tricky for serials. Horizon identifies not just two levels for serials (Bib and Item), but three:  Bib, which can contain zero to many Copies (which might better be called ‘Runs’ or maybe something else, but Horizon calls them ‘copies’) which can contain 0 to many ‘Items’.  At the ‘Copy’ level is where summary holdings statements are stored, which are very important for Umlaut to get and display for a useable interface. It’s only at the ‘Item’ level that a request can be placed though.  It’s generally at the ‘Copy’ level that ‘Location’ is associated with–at least the way we use Horizon. I think it’s theoretically possible for Bib or Item to have possibly different ‘locations’ too.

I’m not sure the simple DLF schema for availability is actually capable of supporting this. It’s good that the DLF schema is kept simple, but for getting what I actually need for serials from Horizon, I’m not sure it would work. I think some other ILSs use a three-level model for serials (and occasionally multi-volume works) too, no?

Advertisement