(Re-)Introducing the Umlaut

Here at my place of work, we have deployed the Umlaut software package as a front-end to our SFX link resolver. Umlaut is an open source project originally developed by Ross Singer then at Georgia Tech, and subsequently worked on quite a bit by me. This has been the main thing I’ve been working on for the past 8 months or so, in the middle of all my regular duties. Umlaut is sometimes called a “link-resolver front end” or a “middle-tier link resolver”. In fact, the Umlaut is a link resolver, in the sense that it receives OpenURL requests–usually representing a citation for a scholarly work–and responds with information on services available related to that citation–most significantly, with electronic availability. However, unlike most typical link resolver products (such as SFX), the Umlaut does not manage it’s own “knowledge base” of information on what titles an institution possesses from what vendors, and how to link to them. Umlaut relies on SFX–accessed through the SFX API–for that information and service.

What does it do?

So why Umlaut, what does it get us? For starters, it allows us a great deal of flexibility with the user-facing interface. While SFX itself allows you to customize it’s templates, providing a seperate interface layer which talks to SFX via the SFX http xml api means that when new versions of SFX come out, our interface should keep working with little modification (hopefully no modification, if the sfx apis continue to be backwards-compatible, as Ex Libris intends). It also gives us flexibility to create interfaces that would have been difficult or impossible soley through the sfx template system. But interface customization is just the start, more importantly it gives us a platform to add functions and services not found in SFX at all.

I’m going to show you some live links to our deployed Umlaut, even though I know you may find bugs; we just deployed this, and it’s not entirely smooth yet.

Direct Linking

For instance, here’s a screenshot of our version of a “direct link with banner frame” implementation. When a user clicks on a “Find It” link resolver link, they can be taken directly to the article they want, not just to a menu. They are provided with a menu in a frame at the top in case the link didn’t work and they need other options, or in case they want to access other link resolver services despite having the full text. Here’s what should be a direct link to that page instead of a screenshot, but you’ll just see our enterprise login since you can’t see the full text. [1]

Physical Holdings

We still have a ‘full’ link resolver menu too, which the user can choose to see, and which is shown when no full text is available. This menu provides location and availability information on physical holdings directly on the screen–no click necessary to see it (at least when there’s an ISSN match; if there’s no ISSN or ISBN match, a link is provided to a keyword search in the catalog instead [2]). It also imports any urls found in our catalog in a MARC 856 field–if those urls found in the catalog don’t duplicate SFX-controlled urls. (Our first example shows a link found in a MARC 856. In this case Umlaut got confused and didn’t realize search.epnet.net was another name for ebscohost.com; that link should really be suppressed. Dealing with our tangle of metadata is not easy).

Relevant Links

Umlaut provides a few more value-added services too. When appropriate, Umlaut provides links to look up a periodical citation in Ulrich’s or OCLC Worldcat (as in this example, see right-hand column). For a book citation, a link to Amazon, OCLC Worldcat, or isbndb to find the best online price to buy the book at. Umlaut’s pretty good about not providing links that go nowhere, the link is only put on the page if a hit is there at the destination.

Search for Public Access

Somewhat more excitingly, Umlaut does an author/title keyword search of IndexData’s indexes of OAISter and Open Content Alliance freely available text, to see if maybe what the user wants can be found for free online, saving an ILL request. This is imperfect because we have no controlled metadata match points, all we can do is an author title keyword search. But when it works, it’s cool. Here is an example of finding an OAISter hit (and I just happened to run into this one looking for examples for other things, I didn’t even rig it!). Note the third link under “electronic versions”. Neat, huh?

OPAC queries Umlaut

I’ve also got Umlaut integrated into my OPAC, so not only the full text links, but also those ‘see also’ links (to worldcat, isbndb, amazon, etc) show up. (For instance. Wait for the ulrich’s and worldcat links to show up in left-hand column under ‘see also’).

Where can it lead us?

So this isn’t necessarily any gigantic step ahead of what you get from native SFX alone. I think it does include some key interventions that our users will appreciate. But more than what Umlaut is doing for me now, I’m interested in the promise of Umlaut. I’ve spent quite of bit of energy building off the great start Ross Singer got to, helping to turn Umlaut into a stable flexible platform to add all sorts of other things to. We have succeeded in de-coupling (or really, making more loosely coupled, but that takes longer to say) the link resolver knowledge base (still held within SFX in our case) with the link resolver software (Umlaut, which provides some services beyond what SFX does).

Any other link resolver with an API, Umlaut could be hooked up to also, in theory, if someone wanted to write the connector. Could that lead to a commoditization of the link resolver _knowledge base_, so we could buy knowledge base maintenance from whoever does the best job without worrying about the quality of their software, just hook up their knowledge base to Umlaut? Theoretically, maybe some day.

More nearer term, additional features I want to add to Umlaut include:

  • Rochester “Getting Users Fulltext” style code to skip right to the full text, skipping content-provider metadata pages.
  • Google Books search to complement the OCA and Gutenberg searches I’ve got.
  • connection to OCLC Identities
  • xISBN/thingISBN use. (Some thought is required in how to integrate this while avoiding false positives). Bowker ISSN service for metadata enhancement. OCLC xISSN? Integrate preceding/succeeding title information from OPAC or xISSN?
  • Integrate my various local document delivery services into menu of options when full text isn’t available.

[See current Umlaut wish list at on wiki]

Are you interested in working with Umlaut?

We are looking for more development partners for Umlaut. I say ‘development partners’ because it is still at the stage where it’s going to be a bit of work to get it deployed–and you’re probably going to have to write code to get it to talk to your OPAC. At this point, to use/participate in Umlaut, your library probably needs to have a programmer on staff who can devote some time to it (you don’t neccesarily need a ruby/rails expert; I wasn’t before I started working with Umlaut). But I am interested in providing support and help for people to do that—and I’m interested in people who want to add even more services to Umlaut. The more institutions we can get using Umlaut, if we can build a community, then our investment in the software is more secure, it’s more likely to continue as a successful and full featured project. Interested? Talk to me.

For those looking for technical details to give our Umlaut the run-through, the base url is:

http://findit.library.jhu.edu/resolve

[1]: Sadly, our user testing suggests that most users do not notice this banner ‘escape hatch’ (as Steve Toub called it) at all. It might as well not be there. Nonetheless, since the biggest comment we got about SFX was “Why can’t Find It just take me right to the full text”, we really wanted to enable direct linking. And if you have direct linking, you really need that escape hatch in cases where it doesn’t work. But users don’t notice the escape hatch. It’s a dilemma. Also, there are some content providers who include javascript which would eliminate our banner; when we identify such, we exclude them from the direct-linking behavior. Either another alternate link will be shown, or the full menu will be shown. Another warning: [Added 16 Jan 4pm EST]: It appears to me that even more targets then I originally thought have problems with being put in a frameset; often difficult to reproduce odd problems. I think the frameset banner design is actually fatally flawed, and a dead-end. More later.

[2]: Why wouldn’t there be an ISSN or ISBN match to our catalog, even if we do hold the item? The OpenURL citation sent to us could have incomplete or errant information. Our catalog records could be incomplete or errant. The resource cited might not have an issn/isbn at all. Or, especially in the case of books, the resource cited with one isbn might be a slightly different version than the one we hold physically with a different isbn.

7 thoughts on “(Re-)Introducing the Umlaut

  1. did you (have to) extend the sfx xml api for any of the other value-added services or is the sfx api going to be the backend protocol of umlaut? and another question: it looks as if umlaut can cobble together multiple knowledge bases, too. is this correct?

  2. robert: I used to have a free-standing PHP script that directly interrogated the SFX db for human-readable ‘coverage’ information. However, with the January SFX update, the SFX API has been extended so this is no longer neccesary. I still directly query the SFX db for ‘search’ services, but this could be done differently–not with the API (as the API works too slowly and times out for this type of query), but with an SFX kb export.

    As far as ‘cobble together multiple knowledge bases’, I hadn’t thought about it in those terms, but I’d say, yes. Depending on the details of what you mean by this, additional code might need to be written to have it work the way you want, but the architecture certainly supports this idea, yeah, for instance querrying two seperate SFX instances and combining the results is easily supported. Depending on the situation, there might be some issues with avoiding duplicate “hits” in the full text list (if the multiple knowledge bases have overlapping coverage).

  3. @jrochkind: i see the stuff i’m working on – a publishing platform for electronic journals – rather on the backend service side of umlaut, hence the question for multiple knowledge bases. so the question for me would be, whether speaking the sfx protocol would be another nice dissemination format for such a service.

  4. on a second thought it would be even better, if the sfx protocol could also be used to aggregate small services like ours into a knowledge base.

  5. Well, there is no ‘sfx protocol’, I don’t think, I”m not sure what you mean by that.

    Yes, Umlaut would be capable of querrying your own local data store, if someone wrote an Umlaut ‘service’ plug-in for that.

    But rather than have link resolver software like Umlaut query many dozens (or hundreds) of different fairly small scale repositories, I think the best solution to this is in agregators like OAISter. OAI-PMH is the protocol that already exists to aggregate metadata, and I’d encourage you to explore whether that protocol makes sense for the platform you are working on, if you aren’t already.

  6. i guess, with sfx protocol i just mean “openurl in” and “sfx xml out”. i’m only somewhat familiar with the metalib x-server api, but assume the sfx one is similar.

    you are also right in that querying many repositories will not scale. but on the other hand, there’s always this trade-off to make: the closer the knowledge base is to the service providers, the better the services can be (integrated).

    and yes, we already disseminate our metadata via oai-pmh, so it is available via oaister.

    reading about umlaut just gave me the idea, this may be the way to integrate our data with our institution’s sfx service by-passing the exlibris knowledge base.

Leave a comment