IESR Use Case 6: Dynamic Use of IESR by a Service Application

Creator	Ann Apps, Mimas, The University of Manchester, UK
Date	2006-11-09
Identifier	http://iesr.ac.uk/use/uses-cases/usecase6.html
Rights	This work is licensed under a Creative Commons Licence: Attribution Required; Non-Commercial; Share-Alike.

Use Scenarios

These scenarios illustrate various ways in which IESR might be used according to the Use Case detailed in the next section.

6.1 An application, Zcheck, will check that Z39.50 services registered in IESR have correct machine address details. Zcheck uses the IESR Z39.50 service to discover all collections that have a Z39.50 service. From the discovered descriptions Zcheck determines the location of the Zeerex record for the service, and also the contact details of the service administrator. Zcheck finds the Z39.50 address for each service from either the IESR service record or the Zeerex file. If the Z39.50 access requires authentication Zcheck simply verifies the service address. Otherwise it checks the Zeerex file to determine whether a particular fielded search will work (choosing another common one from a list if not) and attempts the search. If the Z39.50 server does not respond as expected, Zcheck sends a diagnostic email to the service administrator and also IESR staff.

6.2 A library's metasearch application has not been able to connect to a particular database's Z39.50 server for the past 24 hours. The application then automatically looks to verify the URL for the database's Z39.50 server through the digital library service registry. The application discovers the port number is now different from what it has configured for the database, and automatically updates its configuration with the new port number.
[This scenario is taken from the Registry Use Cases discussed at the Digital Library Service Registry Workshop, held in Washington DC on 23 March 2006. 3 Service Resolution and Configuration.]

6.3 Archie Visit is a cataloguer. He oversees quality control on submissions to his University's institutional repository. In reviewing a particular submission, Archie attempts to view the submitted resource, which appears to be a PDF document. However, his PDF viewer cannot open the requested file. Archie clicks a `validate format' button on the metadata edit screen. The repository software queries the service registry for a format validation service, and finds one at Harvard (attached to Harvard's Global Digital Format Registry). The resource in question is automatically passed to the validation service, which replies back that the object cannot be validated as a PDF, but did validate as a Microsoft Word document. The repository software corrects the file's extension, and Archie is able to finish his work on approving the submission.
[Note that the use case deals with the `service registry query' part of this scenario only.]
[This scenario is taken from the Registry Use Cases (see 6.2). 5 Resource Validation.]

Use Case

Use Case Summary

An application provides a service based on IESR records.

Primary Actor (and goals)

Secondary Actors (and goals)

Stakeholders and Interests

Main Success Scenario

Extensions

[A possible extension to step n of the 'main success scenario' is labelled nx, steps involved in its execution being labelled nxm, etc.]