Managing link persistence with OpenURLs
Statement of problem
Web resources can change location over time, or the route of access for users belonging to a specific institution can change with the same outcome, i.e. broken links. This is undesirable when providing links within teaching material where it is impractical to review and republish the material on a regular basis.
The current approach at the Open University is to create ‘managed’ links which are used in teaching material and environments instead of the primary link for a resource. These managed links are managed by two systems:
- For free web resources managed links are provided by ROUTES
- For subscribed web resources (e.g. databases) managed links are provided by a locally developed system
An example is that if we wish to include a link to the BBC homepage within the VLE we would not use the Primary URL:
but instead use the ROUTES created ‘managed’ URL:
Although this practice solves the problem of persistence over time (if the primary URL for the web resource changes, we can update the ROUTES or local system without having to update the course material), it creates several new problems:
- To provide a link to any web resource you have to know a special link, which you have to ask for from the library
- The ‘managed’ URLs do not make sense outside the context of the OU, meaning that if a student copies a reference to a resource, including the link, these references are not really appropriate for use except within the OU environment
- The library has to ‘manage’ URLs for all referenced resources, no matter whether the Primary URL is correct or not
Business Requirements
In order to avoid these issues we need a solution which:
- Preserves the Primary URL in the original reference
- Does not require the entry of a special ‘managed’ URL by course authors or others involved with the authoring and editorial process
- Does not require management of Primary URLs which are valid
Proposed Solution
The proposed solution is that we should use OpenURL to provide links to resources wherever possible. For bibliographic formats – journals, journal articles, books (whether in print or electronic) the expression of these in OpenURL is well documented, and the translation of the OpenURLs generated by link resolvers is well understood.
However, when providing links to a web resource, the use of OpenURL is novel. What it will allow us to do is to take a Primary URL, check whether there is a Managed URL for it and direct the user to the Primary or Managed URL depending on what is available.
The flow would be as follows (using the OU OpenURL resolver, which is an SFX implementation):
Sep 14th 2009 • 13:09
by Eric Hellman
Putting url’s inside OpenURL (in rft_id) is a Good Thing To Do, and if fact is done by enough sources that the best resolvers already pass through the URL into the option menu or the redirect engine. What I’ve not seen is the implementation of replacement URL lists for the purpose of url maintenance.
Another very simple way to implement this if you have a commercial resolver that does not support url in rft_id would be to deploy your own resolver in a redirect chain configuration in front of the commercial resolver. If your resolver sees url in rft_id, then it does appropriate redirection, if not it passes the OpenURL on to the commercial resolver.
Sep 14th 2009 • 14:09
by ostephens
Thanks Eric. As far as I know SFX doesn’t pass through a URL in rft_id to the option menu or redirect engine, but I think it would be relatively trivial to add this – there is an existing option that uses what I assume is a custom field to pass a URL from a MARC 856 field into the option menu, so the hooks are all there to do this.
Obviously we want to use rft_id in the OpenURL to keep the implementation standard, but internally in SFX it would actually be useful to use the custom field as this allows us to maintain the primary URL in the rft_id, while having the alternative URL (whether the same or actually alternative) in the custom field.
Sep 14th 2009 • 14:09
by Laurian Gridinoc
The purl.org project was intended to do the same, I wonder how many open/purl-like or short url initiatives are in the OU. For example we built a custom one for managing links in iTunes U and for Tweeter OU have their own bit.ly account.
Sep 14th 2009 • 14:09
by ostephens
Thanks Laurian. The advantage I can see if using the OpenURL rather than creating a purl or other short URL is that it means that the Reference itself can contain the primary URL – and so it can be exported and reused outside the OU context without becoming invalid.
It also allows us to be consistent in the way we do things, as for electronic journals and articles OpenURL is a really good way of forming links based on the available metadata, avoiding the need to put a link into the reference completely.
Sep 14th 2009 • 15:09
by Laurian Gridinoc
This reminds me of XRI cross-reference capabilities … I’ll dig more into OpenURL, I’m not familiar with its syntax/capabilities.
Sep 16th 2009 • 22:09
by Eric Hellman
This post on “Implementing OpenURL for simple web resources” inspired me to write an article on all the things that redirectors can be used for:
http://go-to-hellman.blogspot.com/2009/09/redirector-chain-mashup-design-pattern.html
Here’s another approach for your problem:
Have an onLoad javascript call your link maintenance database and then rewrite the links in your page. This could be implemented in a JSON sort of way. (and no Openurl)
Here’s why. There will be situations where you want to maintain the anchor text as well as the link, and this solution allows you to do it. Also, a well-crafted javascript will allow all the links to work (well, the good ones, at least) even if you link maintenance service goes down or disappears.
Sep 18th 2009 • 15:09
by ostephens
Thanks Eric, interesting stuff.
I’m not sure I quite understand the issue of the anchor text? We haven’t finalised this yet, but I suspect we will use the whole of the reference as anchor text, rather than just the link… (not sure about this, need to look at the display I guess). Within the reference (i.e. textually) we will display the ‘primary’ URL rather than any proxy/OpenURL
I can see a possible downside to the solution here, which is that you have to look up every link in a page on-the-fly – which is something we tend to avoid for performance/load reasons.
Pingback
Oct 22nd 2009 • 13:10
by Telstar » Blog Archive » Linking strategies
[…] of posts on linking from references to resources, and particularly on how we are planning to use OpenURLs to provide persistent links to web pages, but I’ve not yet described our overall approach to […]