Rights Evaluation Scheme

1. Introduction

   ZBLSA is a journals locator being developed by EDINA (edina.ed.ac.uk) as an integral part of the UK Higher and Further Education (HE/FE) Information Environment (IE) . ZBLSA will provide portals in the IE with a tool for locating journals and journal articles. When an end-user has identified an article of interest, ZBLSA will direct that user to the appropriate copy. In the current environment, a number of vendors compete to supply similar content. The appropriate copy of a specific article depends on the services to which an end user's institution subscribes. ZBLSA benefits librarians by ensuring that their end users are connected to subscribed services. The end-user benefits by gaining direct access to library resources and avoiding unnecessary payments. ZBLA benefits publishers by streamlining access to subscribed resources and directing traffic to their sites. If the end-user has no prepaid access right, ZBLSA will present a pay-per-copy option when appropriate.

   The ZBLSA RES eliminates the requirement for a library to maintain a complex table of subscription information to locate the appropriate copy. ZBLSA simply asks a supplier whether a member of a given institution is authorised to access a particular journal. Technically, this involves a simple request/response interaction between the resource provider and ZBLSA. The response need indicate only whether an article would be available to a user from a specific institution or with credentials that identify a subscriber (e.g. an ATHENS username and password). ZBLSA does not access the licensed content; it merely informs the end user of the location of that content. The end user accesses it directly using existing mechanisms for formal authentication and authorisation.

2. Benefits to publishers implementing the ZBLSA RES

   1. As a central component of the IE, ZBLSA will be a primary mechanism for directing users from the UK HE/FE community to publishers' web sites.
   2. ZBLSA can maximise use of resources by ensuring that end-users are presented only with links that are productive. By streamlining the link between discovery and location of the appropriate copy ZBLSA will reduce the opportunity cost of using electronic journals thus enhancing their value.

   ZBLSA will be used only for the stated purpose. If required, EDINA will provide publishers with the IP addresses of any server equipment authorised to issue ZBLSA rights evaluation requests.

3. Technical details

   The ZBLSA rights evaluation scheme has two parts:

   • ZBLSA will issue a REQUEST to the publisher's server that identifies the journal article in question, and specifies the requesting user's institution.

   • The publisher's server will return a machine-readable RESPONSE stating whether that journal article would be made available to a user associated with that institution.

   1. Request format

      This is constructed by extending the existing link format used to request a journal article from a specific publisher's site. For example, the existing link for an article in Abacus, volume 38, no. 1, pp. 1-15 appears as an OpenURL:

      http://openurl.ingenta.com/content?genre=article&issn=0001-3072volume=38&issue=1&spage=1

      To this existing format, we add a single further parameter to identify the user's institution. The obvious name-forms for identifying the institution are IP address, institutional DNS name, or Athens (the UK scheme for authentication) institution name. The identifiers may be expressed in any format acceptable to the publisher, but the following is suggested.

      The various forms of institution identifier can be represented as inst-schema:value, where schema may be replaced by ip, dns, or athens:

      inst-ip:129.215.70.163
inst-dns:ed.ac.uk
inst-athens:gla

      The full request format is produced by adding the new parameter to the existing format. There are two ways in which this can be done.

      1. To comply with the current OpenURL specification, the parameter may not be added to the query string. It can therefore be added to the path:

         http://openurl.ingenta.com/content/inst-ip:129.215.70.79?genre=article&issn=0001-3072&volume=38&issue=1&spage=1

      2. In anticipation of the forthcoming OpenURL standard, which permits the addition of new resolver-specific parameters to the query string (provided the name starts with a '_'):

         http://openurl.ingenta.com/content?_inst=ip:129.215.70.79&genre=article&issn=0001-3072&volume=38&issue=1&spage=1

      The former solution is technically correct at present, but the latter may be preferable for implementation. Though the latter is not strictly correct, it should become technically compliant in the near future and should cause no problems before then.

      Of course, ZBLSA will be tailored for each publisher's site according to the link format defined by that publisher. In addition, ZBLSA can use any other parameter name preferred by the publisher to denote the requesting user's institution, and could direct the request to a different CGI or a different server. In fact, any formulaic variation to these technical details could be accommodated by ZBLSA.

   2. Response format

      The response indicates whether the journal article would be available to a user at the specified institution. For simple cases, an HTTP response that expresses a simple "yes" or "no" would be sufficient. Using an XML encoding (which has the advantage of being extensible), the response might be:

      <success>1</success>

      where the value in the 'success' tag is 1 or 0 to indicate success or failure. Extra tags could be added in future to contain any extra information thought useful.

      For more complex cases, such as where a pay-per-copy option exists, the response could convey three Boolean values which indicate:

      • whether the article is held;
      • whether it is available to the requesting user by virtue of subscription rights;
      • whether it is available on a pay-per-copy basis.

      Using the tags <held>, <subs>, and <pay>, the three standard cases could be represented as follows:

      1. Available. The article is held and the user is authorised to see it:

         <held>1</held>
<subs>1</subs>
<pay>1</pay> (this tag is not used in this case)

      2. Not available. Either the article is not held:

         <held>0</held>

         or the user is not authorised to access it, and no pay-per-copy option applies:

         <held>1</held>
<subs>0</subs>
<pay>0</pay>

      3. Conditionally available. The article is held, and although the user is not authorised to access it, it can be supplied on a pay-per-copy basis:

         <held>1</held>
<subs>0</subs>
<pay>1</pay>

      Formally, an "XML namespace" should be specified, to define the meaning of the various tags. For AIP, a properly formed version of the response could be expressed as:

      <?xml version="1.0"?>
<pub:authorization xmlns:aip="http://www.auth.aip.org/">
   <pub:held>1</aip:held>
   <pub:subs>1</aip:subs>
   <pub:pay>1</aip:pay>
</pub:authorization>

      It makes sense for the publisher to own the namespace used in each case, as the publisher's server will be generating the response. These suggested encodings are made purely for consideration. As with the request format, ZBLSA has no absolute requirements other than realisation of the scheme in some form. The response could easily be extended so that if a partial match is available, e.g. the journal title but not the specified article, the user will be provided with a link at the most appropriate level of granularity.