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.
Instead of ‘link resolver’, let’s talk about ‘OpenURL service providers’. An OpeURL Service Provider is something that takes an OpenURL, and provides the user with one or more services that can be performed on or with the resource cited in the OpenURL. Now, of course our ‘link resolvers’ are OpenURL Service Providers like this and always have been. The services they provide include: getting full text, showing physical location in our libraries, document delivery (ILL). (These are the services specified in the SAP1/2 OpenURL ‘profiles’). An SFX instance (or an Umlaut instance!) is also capable (at least in principle) of providing a bunch more services not specified in the SAP1/2 profiles, including: Saving to a bibliographic reference manager; finding articles that cite the given reference; suggesting other resources that may be of interest to me, from ‘related articles’ to library subject guides; etc. Whatever else you can think of.
Note that some of those are not really about ‘resolving’ (what resolution is there in simply saving my citation to RefWorks?), but, okay, no problem, our ‘link resolvers’ are already really OpenURL Service Providers.
But now let’s think about what else counts as an “OpenURL Service Provider.” Anything that can take an OpenURL as a request, and return a service of use to the user. Wait, RefWorks itself can take an OpenURL! Aha, RefWorks itself is an OpenURL Service Provider all by itself. It provides only one service: Storing a citation to your RefWorks file. Try it yourself, if you or your institution has a RefWorks account:
RefWorks as an OpenURL “resolver” (ie, service provider) has a base URL of:
Try setting that up in your OpenURL Referrer Firefox Extension as your ‘link resolver’. Look at a page the extension works with, such as google scholar, look you have RefWorks as your ‘link resolver’ (that is, service provider!). (Gee, logging into RefWorks from off campus is a pain. We could talk more about that, but we won’t).
That works! Pretty neat, huh? Well, kind of, setting RefWorks as your (sole) “link resolver” isn’t so useful, now all you can do is save references from your ‘link resolver’.
But this helps answers Dan’s question about “How do we fit people without an institutional link resolver into this system”? Even without an institutional link resolver, I can purchase an individual account on RefWorks (I think; if not, pretend I can), now I can have RefWorks available to me through an “OpenURL Service Provider” architecture. Along with any other services, free or pay, present and future, that will accept OpenURL’s and provide functions in response. Even if I have an institutional link resolver, why should I bet at the mercy of my institution’s admins in deciding what services I have available to me? I should be able to pick and choose them from any available OpenURL Service Providers. Which suggests I don’t just have one ‘link resolver’, I need a way of having multiple “OpenURL Service Providers” associated with me.
In addition to RefWorks, what other OpenURL Service Providers might exist? Well, all of our content providers (ie, ‘databases’, ‘targets’) that accept OpenURL are such. You could set, oh, say, EBSCOHost as your ‘link resolver’. You’d only get EBSCOHost provided articles in response, you wouldn’t want to choose that as your sole ‘link resolver’, but it’s an OpenURL Service Provider. (Note that one OpenURL Service Provider (such as my institutional link resolver) can in return redirect the user to another (such as an OpenURL-accepting content provider). This is in fact a common scenario already).
Of the services Dan provides as examples he wants to fit into his scenario, which can be provided as OpenURL Service Providers? Well, ‘print’ probably can’t, print is something you do locally. ‘Email’, eh, I suppose a service could be provided to do that, but what’s the point? Digg or Delicious? Are about URLs. Can a URL and title be provided in an OpenURL Context Object ‘payload’ as a referrent (not talking about a URL that is supposed to resolve to more metadata; the URL is simply the document identifier, the end)? I’m not sure, but if they can, then Digg or Delicious could be OpenURL Service Providers. Considering other services we might want is left as an exersize for the reader.
Note that all these services are defined with identifiers in SAP1/SAP2. We’d need to create a whole new OpenURL ‘profile’ to include extra services, and then go on creating new ones every time a new kind of service were thought of! This is an unfortunate way to have things structured. As a result, link resolvers like SFX currently just define their own services (along with identifiers represneting these services) in a completely proprietary and non-standard way. That’s unfortunate. Instead, we really want a flexible framework where services can be added fairly quickly, as needed, to a ‘service registry’, added on as identifiers to be used with existing ‘profiles’, not requiring the creation of a new profile. This is a problem that needs a solution one way or another. A non-optimal but low-barrier solution is to start with what SFX uses and just create our own agreed upon list to use, even if it’s not actually allowed by the OpenURL standard to do things this way (SFX is already doing things this way, of course).
Next, in future essays, we’ll talk about different possibilities for putting together an architecture to support Dan’s scenario based on this notion of “OpenURL Service Provider”. The questions are: How is a user associated with one or more OpenURL Service Providers? How are the services provided by these providers to be displayed to the user from any given ‘source’?