OAISter -> points to plenty of non open access stuff

So I had been operating under the incorrect assumption that OAISter only aggregated feeds which claimed to be of open access materials.

After embarrassingly sending them a letter (and cc’ing code4lib) asking for clarification I noticed their collection development policy page. (Embarrassing because I should have checked first).


  • We harvest and retain all records that point to digital resources.
  • This includes freely-available and restricted-access digital resources.

Continue reading “OAISter -> points to plenty of non open access stuff”

(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. Continue reading “(Re-)Introducing the Umlaut”

Issues with my SFX in HIP code

Specifically with the stuff that generates the coverage strings missing from the SFX API. In some cases of SFX including services from ‘related’ SFX objects, my current code will generate empty or incorrect coverage strings that do not match what the SFX menu itself provides.

I am trying to come up with a very hacky workaround to this. If you want the new version, contact me in a couple days (I should REALLY put this stuff in a publically available SVN). But a VERY hacky workaround is what it will have to be, and will probably still have some edge cases it can not deal correctly with. To explain what the deal is… it’s confusing to explain, but I’ll just give you my Ex Libris enhancement request:

Continue reading “Issues with my SFX in HIP code”

‘Link Resolver’ understood as ‘OpenURL Service Provider’

Dan Chudnov envisions a scenario for using OpenURL to let a person carry their ‘services’ around with them from website to website, in an automatic way. At least that’s my interpretation of his scenario, I’m sure he or someone else will correct me if I’m mis-characterizing it.

That’s started me thinking in more detail about what the architecture needed to support this scenario would look like. I’m going to make a few posts about this, starting with this one investigating how we should think about the ‘link resolver’. (Note that I’m not sure if this is exactly what dchud was thinking just stated differently, or expands upon it, or even contradicts it! That’s why we write these things down, to tease out from each other what we mean and build shared mental models and vocabulary, right?)

So, what is a ‘link resolver’? Well, of course, it’s something that takes an OpenURL, which represents a bibliographic item and tells the user where he can get electronic access to the item. (And, yes, the OpenURL includes not just an item citation, but the ‘context’ of the request, but let’s face it, the item requested, the ‘referrent’, is the principle payload, and the main thing that ‘link resolvers’ act upon; in practice the extra stuff is just bonus). The very name ‘link resolver’ implies this scenario, but let’s consider an alternate more abstract understanding of the class of services our ‘link resolvers’ fit into. Continue reading “‘Link Resolver’ understood as ‘OpenURL Service Provider’”