IESR Use Case 1: Dynamic Use of IESR by a Portal
| Creator | Ann Apps, Mimas, The University of Manchester, UK |
|---|---|
| Date | 2007-02-28 |
| Identifier | http://iesr.ac.uk/use/uses-cases/usecase1.html |
| Rights |
This work is licensed under a
Creative Commons Licence:
Attribution Required;
Non-Commercial;
Share-Alike.
|
| Change History | |
|---|---|
| 2007-02-28 | Correction to step 3: IESR now includes an index on Bib-1 attribute 13 (Dewey classification) Correction to step 4b1a1: IESR now describes more details of an OAI-PMH service via `interface' properties |
| 2006-11-09 | This is the first version |
Use Scenarios
These scenarios illustrate various ways in which IESR might be used according to the Use Case detailed in the next section.
Because, in the use scenarios in this section, the portal uses IESR dynamically there is no dependency on the portal builder's knowledge of available resources. Thus, potentially, an end-user may find useful resources of which they were unaware. Also it is possible that if they perform a similar search in the future, more resources may be discovered as IESR contributions from resource providers increase.
1.1 Mary is a physicist at ABC University who wants to do a literature survey on the Higgs-Boson particle. She uses a Z39.50 based metasearch portal provided by ABC University's library and enters `Higgs-Boson' as a search term. The portal uses IESR, via its Z39.50 interface, to discover appropriate bibliographic collections that cover particle physics, provide a Z39.50 service, and have appropriate authentication for Mary. The portal then provides to Mary the result of a Z39.50 cross-search over these collections, using `Higgs-Boson' in the `title' as a search term. Mary sees this list of search results within the portal web screen where she made the request. She selects any of interest via their web links. They could be either direct links to articles from collections of articles, or citation links from bibliographic services. She follows any that are citation links to full text, ABC University library's OpenURL resolver guiding her to `appropriate' copies.
1.2 Jenny is a social scientist who wants to find resources about family health. She is using a Z39.50 based social science portal and enters `family health' as a search term. The portal uses IESR, via its Z39.50 interface, to discover social science resources that cover family health and provide a Z39.50 service. The portal then provides to Jenny the result of a Z39.50 cross-search over these collections, using `family health' in the `title' or `subject' as a search term. Jenny sees this list of search results within the portal web screen where she made the request. She selects any of interest via their web links. They could be: literature about family health; direct links to appropriate datasets; or links to registration pages for access to collections of appropriate datasets.
1.3 Mike is a medical researcher looking at treatments for Alzheimer's disease and wants to find relevant current literature. He uses a Z39.50 based medical portal and enters `alzheimer' as a search term. The portal uses IESR, via its Z39.50 interface, to discover collections that potentially include resources about Alzheimer's disease, provide a Z39.50 service, and use the medical MeSH thesaurus to catalogue their items. The portal then provides to Mike the result of a Z39.50 cross-search over these collections, using the MeSH code for `alzheimer disease' in the `Mesh subject' as a search term. Mike sees this list of search results within the portal web screen where he made the request and selects any of interest via their web links.
1.4 Joanne is a mathematics researcher interested in the Poincaré conjecture and the recent work of Perelman. She uses a Z39.50 based mathematical portal. This portal offers several search options to the user including an `author' search, so Joanne enters `Perelman' in this field. The portal requires results in simple Dublin Core XML, for general interoperability according to the Bath Profile. The portal uses IESR, via its Z39.50 interface, to discover collections that include mathematical resources, provide a Z39.50 service with an `author' search field, and provide simple Dublin Core XML results. The portal then provides to Joanne the result of a Z39.50 cross-search over these collections, using `perelman' in the `author' field as a search term. Joanne sees this list of search results within the portal web screen where she made the request and selects any of interest via their web links.
1.5 Laura is a dance student who wants to find music resources, including recorded music, music scores, choreographic notation, and still and moving images. She is using a Z39.50 based portal and enters `music' as her interest and the various resource genres she seeks. The portal uses IESR, via its Z39.50 interface, to discover music resources. The portal then provides to Laura the web links to the discovered collections that contain items of the appropriate genre. Laura sees this list of search results within the portal web screen where she made the request. She selects any of interest via their web links.
[This scenario would support the initial step in the Scenario 7.3.1 developed by Leona Carpenter within the JISC Shared Services Synthesis Study.]
1.6 John is a social scientist who wants to find resources about economics. He uses an SRU based social science portal and enters `economics' as a search term. The portal uses IESR, via its SRU interface, to discover collections of social science resources in the economics field and provide an SRU service. The portal then provides to John the result of an SRU cross-search over these collections, using `economics' as a `subject' search term. John sees this list of search results within the portal web screen where he made the request and selects any of interest via their web links. They could be: literature about economics; direct links to economics datasets; or links to registration pages for access to collections of economics datasets.
1.7 Paul is looking for resources about tuberculosis transmission. He uses his institutional portal which provides a search box for Zetoc. He enters `tuberculosis' into a Zetoc `title' search and retrieves the expected Zetoc list of brief search results. The portal displays to Paul, in another part of its display, a list of other `more-like-this' resources that may be of interest to him. It does this by using IESR, via its Z39.50 interface, to discover medical resources that cover tuberculosis and provide a Z39.50 service, excluding Zetoc. The portal then provides to Paul the `more-like-this' list that is the result of a Z39.50 cross-search over these collections, using `tuberculosis' in the `title' as a search term.
[This scenario is based on a suggestion made by Chris Awre at the Digital Repositories, e-Research and Portals Workshop, held at Lancaster University Centre for e-Science on 6-7 September 2006.]
1.8 Sam wants to find a book about microlight aircraft. He uses MetaCat, a catalogue of resources available in a set of major libraries, and discovers a publication he would like to read. He then wishes to know if the book is available in his institution's library. MetaCat searches IESR, via its Z39.50 interface, to find the Z39.50 address, and further ZeeRex details, of Sam's institution's library's catalogue. If the library has its OPAC registered in IESR, MetaCat then provides to Sam a search of the library OPAC using the ISBN of the book.
[This scenario is based on a requirement from COPAC.]
Use Case
Use Case Summary
A researcher uses a metasearch portal (e.g. Z39.50 (or SRU) based) to discover resources about a chosen topic.
Primary Actor (and goals)
| Researcher | To discover resources about a particular topic |
Secondary Actors (and goals)
| Portal (e.g. Z39.50 (or SRU) based) | To provide a single search interface to an amalgamated set of resources |
| IESR | To assist discovery and use of registered resources |
| Terminology Service | To assist in determining search terms in a suitable vocabulary and of suitable granularity |
Stakeholders and Interests
| IESR Contributors | Increased use of resources |
Main Success Scenario
| Step | Action | Analysis |
|---|---|---|
| 1 | Researcher enters chosen topic as search term in portal | |
| 2 | Portal uses terminology service to translate natural language search term into a broader term suitable for collection discovery and then into a Dewey term | This is a terminology service use case, not an IESR one. An alternative to a terminology service could be terminology knowledge built into the portal |
| 3 | Portal performs Z39.50 search on IESR using Dewey subject term, restricting the search to collections that have a Z39.50 (or SRU) service (Service::dc:type(iesr:AccMthdList)=z3950) | Search uses Bib-1 attribute 13 - Dewey Classification (index: dewey) |
| 4 | Portal parses retrieved IESR XML records | For each collection this is a composite record that includes details of the collection, all its services and all associated agents |
| 5 | Portal reads Z39.50 (or SRU) service address details from parsed IESR records | Portal has to parse out elements of z3950s:// address |
| 6 | Portal performs Z39.50 (or SRU) metasearch over discovered collections, using the researcher's original topic as a search term within item titles | |
| 7 | Researcher views results returned by metasearch and selects any of interest via their web links | Portal needs to manage different response times and display of a potentially large result set |
Extensions
[A possible extension to step n of the 'main success scenario' is labelled nx, steps involved in its execution being labelled nxm, etc.]
| Step | Extension | Analysis |
|---|---|---|
| 1a | Researcher enters author name into a specific search form provided by a subject portal | Scenario 1.4 |
| 1a1 | Subject portal uses its own subject for IESR search and author name for cross-search | Steps 3 and 6d |
| 2a | Subject search is not the criterion for IESR search | Scenario 1.8 |
| 2a1 | Step 2 omitted. Followed by Step 3b | |
| 3a | Portal operates by SRU | Scenario 1.6 |
| 3a1 | Portal checks for Service::dc:type(iesr:AccMthdList)=sru | Steps 5 and 6 are also SRU |
| 3b | Subject search is not the criterion for IESR search | Scenario 1.8 |
| 3b1 | IESR search is according to required criterion | |
| 3c | No suitable records found | |
| 3c1 | Portal will not use IESR | This is failure scenario. IESR must contain a large and comprehensive variety of resources |
| 4a | Researcher has to use IP or Athens authentication if resources are not freely available | Scenario 1.1 |
| 4a1 | Portal rejects collections with unsuitable authentication restrictions (Service::dcterms:accessRights(iesr:AuthList), and uses only those with: IP check (ip), Athens (Athens) or freely available (none) | |
| 4b | Researcher is looking for resources of particular genres | Scenario 1.1, 1.5 |
| 4b1 | Portal selects collections that have the required itemType | IESR may need to capture more specific itemType values, e.g. journal articles and conference papers to support Scenario 1.1, music scores to support Scenario 1.5. Alternatively this criterion could be included in the search query at Step 3 |
| 4b1a | Further, researcher wishes to read peer-reviewed literature | |
| 4b1a1 | Portals rejects collections that do not include peer-reviewed literature | This is not currently captured by IESR Collection descriptions. A possible solution would be to check if the collection's OAI-PMH service supports the Eprints Application Profile. This could be checked via the `interface' property that returns the result of a ListMetadataFormats request |
| 4c | Researcher wishes to read only open access literature | |
| 4c1 | Portal restricts authentication requirement to services that have no access restrictions | |
| 4d | Portal uses a specific vocabulary, relevant to the discipline it supports, for cross-searching collections | Scenario 1.3 |
| 4d1 | Portal selects for cross-searching only those collections that support this vocabulary | Alternatively this criterion could be included in the search query at Step 3 |
| 4e | Portal wishes to provide to researcher only resources that it has some confidence in being current | |
| 4e1 | Portal checks the administrative metadata for the entities in the composite XML collection record for currency | A `status' field in the administrative metadata indicating when a record was last checked is required |
| 4f | Portal implements processing of the results of its cross-searching using Simple Dublin Core | Scenario 1.4 |
| 4f1 | Portal selects for cross-searching only those collections whose Z39.50 service is Bath Profile compliant (uses iesr:supportsStandard(iesr:StdsList)) | Alternatively this criterion could be included in the search query at Step 3 |
| 4g | Portal is looking for collections of a particular type | Scenario 1.8 |
| 4g1 | Portal rejects collections not of the particular type | IESR may need to support more collection types |
| 4h | Researcher wants resources about a particular era | |
| 4h1 | Portal selects collections that have an appropriate temporal coverage | Alternatively this criterion could be included in the search query at Step 3 |
| 4i | Researcher wants locally available resources | Scenario 1.8 |
| 4i1 | Portal selects collections that have a service appropriate to the researcher's internet domain | |
| 6a | Portal prefers to cross-search the subject field | Scenarios 1.2 and 1.6 |
| 6a1 | Portal creates cross-search using a suitable term that correlates to the input natural language term | Terminology service could be used again here |
| 6b | Portal needs to use a particular vocabulary for a subject search | Further to 4d, scenario 1.3 |
| 6b1 | Portal creates cross-search using a suitable term from this vocabulary that correlates to the input natural language term | Terminology service could be used again here |
| 6c | Portal requires service to support more specific search attributes and result sets | Scenario 1.4 |
| 6c1 | Portal retrieves the service ZeeRex file via iesr:interface to determine more specific search attributes, and searches only those that suit its requirements | |
| 6d | Portal wishes to cross-search the author field because this is the data the researcher has supplied | Scenario 1.4 |
| 6d1 | Portal creates cross-search using the author name | |
| 7a | Portal provides results of IESR search directly to the user | Scenario 1.5 |
| 7a1 | Steps 5 and 6 are omitted | |
| 7b | If link is to a citation, researcher wants to read full text | Scenario 1.1 |
| 7b1 | Researcher follows an OpenURL link from the citation to their institution's OpenURL resolver, which provides access to appropriate full text for perusal |