Moving into the cloud means you need to think more carefully about the URL links in your metadata if you don’t want to annoy and frustrate library patrons.

This week I became aware of the amazing Understanding Shakespeare resources created by the clearly very talented JSTOR labs. The ability to connect line by line digital texts from the Folger Shakespeare Library with articles on JSTOR about the relevant Shakespearean play is incredible. Every English teacher I have showed this resource to was very, very impressed. This is project also demonstrates the practical application of two organisations working together and using metadata and APIs to create something that saves researchers time AND looks amazing. As a result I found an existing record on WorldCat and added this service to my library’s catalogue. For details see http://mentonegirls.worldcat.org/oclc/926274094

But there was a problem with the MARC 856 field in the global WorldCat record.

The record had been added to WorldCat by the library at the London Metropolitan University (which is fantastic) but the 856 LMU loaded into WorldCat was populated with the LMU link THEIR patrons use to authenticate into JSTOR. Adding this to the the global bibliographic infrastructure environment is not so fantastic.

In a traditional siloed library catalogue environment a library can happily have their own institution’s authenticating URL in the MARC 856 field because the library is not sharing the bibliographic record with any other library service. Patrons using the LMU catalogue have the necessary authentication credentials to access to remote eContent. In a traditional siloed library catalogue environment any library that grabs this record for their own use has the option to strip out and replace the LMU 856 with their own 856 when they upload the record into their catalogue. BUT…

In a next generation shared cloud based catalogue environment where libraries share the one global bibliographic record adding an authenticating URL from another library service with different authentication which won’t work is not a good idea. In this environment a library should either add the 856 to their local bibliographic record or better still use the catalogues utility for managing electronic resources and bypass the MARC record. In the case of WorldShare the electronic resource management utility is Collection Manager.

To fix this I:

  • added an extra 856 into the WorldCat record with a the direct link to http://labs.jstor.org/shakespeare and,
  • changed the $z public notes in the LMU 856 to read “via London Metropolitan University.

The end result is as follows with my additions highlighted in red:

856 4 0 $uhttp://labs.jstor.org/shakespeare/$zUnderstanding Shakespeare via JSTOR Labs.
856 4 0 $uhttp://0-labs.jstor.org.emu.londonmet.ac.uk/shakespeare/$zUnderstanding Shakespeare via London Metropolitan University.

Now any other library that uses this record within WorldCat has access to the generic non authenticating link to JSTOR and the public notes in the $z subfield tell users which link to use. For more information see

URL image by Rock1997 (Own work) [GFDL (http://www.gnu.org/copyleft/fdl.html) or CC BY-SA 4.0-3.0-2.5-2.0-1.0 (http://creativecommons.org/licenses/by-sa/4.0-3.0-2.5-2.0-1.0)%5D, via Wikimedia Commons

Advertisements