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