IESR Use Case 4: Static Use of IESR by a Portal Builder
| Creator | Ann Apps, Mimas, The University of Manchester, UK |
|---|---|
| Date | 2006-11-09 |
| Identifier | http://iesr.ac.uk/use/uses-cases/usecase4.html |
| Rights |
This work is licensed under a
Creative Commons Licence:
Attribution Required;
Non-Commercial;
Share-Alike.
|
| Change History | |
|---|---|
| 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.
4.1 Jane provides systems support for biogridPortal, an eResearch Grid portal for the bioinformatics research community within UK Higher Education. biogridPortal provides an integrated suite of appropriate services whose technical interfaces interoperate, and thus plug into biogridPortal, using Web Services SOAP. She wants to include access to a bibliographic collection within biogridPortal to enable bioinformatics researchers to include within their workflows literature surveys about specific research areas. Jane searches the IESR Web interface to find a suitable bibliographic service, which includes bioinformatics literature and has a Web Services SOAP interface. She finds BiblioCit, which is a collection of bibliographic citations of journal articles and conference papers, and which has a SOAP interface. After checking that the authentication requirements and terms and conditions of BiblioCit match her user community, Jane reads the technical connection details of the BiblioCit SOAP service. She uses these details to include a connection to BiblioCit within biogridPortal. The portal is then able to provide support for Gary, a bioinformatics researcher who wants to find research literature about a particular disease in cows. He uses biogridPortal to develop and run workflows to obtain research results. He is now able to select the BiblioCit bibliographic service within biogridPortal, as part of a workflow when he wishes, possibly searching for bibliographic records that have the cattle disease in the title.
4.2 Peter is building a Z39.50-based Engineering portal. He uses the IESR Web interface to discover resources about Engineering that have a Z39.50 access service. He determines from IESR the details of Z39.50 access to his chosen resources. He uses these details to build into the portal a Z39.50 cross-search over these engineering resources.
[This scenario is based on a PerX use case.]
4.3 David is developing an OpenURL resolution service. He wants to be able to generate links to collections available within the JISC Information Environment that provide in-bound linking using OpenURL syntax, i.e. collections that have an associated OpenURL Link-To resolver. David searches the IESR Web site to discover all collections that have an OpenURL service. He ignores any transactional services because these are probably similar to his OpenURL resolution service. From the rest he chooses those he thinks suitable for his application. He determines the location address, aka baseURL, of each OpenURL resolver. He includes these in his application along with appropriate descriptive details of the collections taken from their IESR records.
4.4 (Sequel to 4.3) David then wants to extend his resolution service to include collections that provide linking in via proprietary CGI interfaces which they advertise publicly in the IESR (this is the definition of an OpenURL target). David searches the IESR Web site to discover collections that have a webcgi services. He ignores any that also have an OpenURL service because he has already included those. From the rest he chooses those he thinks suitable for his application. He accesses the WSDL file to determine the syntax details of searching the collection via its CGI service. He includes these in his application along with appropriate descriptive details of the collections taken from their IESR records.
4.5 Kate is an aeronautical engineer. She wants to set up a personal RSS 'portal', using her choice of RSS reader. She wants to add RSS feeds to this personal RSS `portal', which will alert her when and where new engineering resources become available. She would also like to include alerts for issues of her favourite aeronautical engineering journals. Kate searches the IESR Web site to discover RSS services related to engineering. For those she finds with a single location address, she adds this address to her personal RSS portal. She discovers that Zetoc provides RSS journal alerts. She goes to the Zetoc RSS service `help' page (Service More Information) from where she is able to select the RSS feeds for the particular journals in which she is interested.
4.6 Roger is building an application that will provide access to several repositories of eLearning resources. He knows that IESR contains details of JORUM and wants to reuse this description. He needs the description in XML format so that he can plug it directly into his application. He also wants to add details of JORUM's OAI-PMH service. He uses the IESR OpenURL interface to acquire these XML descriptions.
Use Case
Use Case Summary
A portal builder discovers suitable resources for inclusion.
Primary Actor (and goals)
| Portal Builder | To discover suitable resources for inclusion |
Secondary Actors (and goals)
| Portal | 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
| Researcher | To use portal to discover resources about a particular topic |
| IESR Contributors | Increased use of resources |
Main Success Scenario
| Step | Action | Analysis |
|---|---|---|
| 1 | Portal Builder uses the IESR Web interface to discover resources that are appropriate for a particular discipline | IESR needs subject terms that are `words' unless either Extension 1a is followed, or search is on `any field' |
| 2 | Portal Builder restricts the discovery to resources that can be accessed by a particular service access method (protocol) | |
| 3 | Portal Builder reads from the IESR Web interface details of service access for each resource | This may involve reading the technical iesr:interface details, e.g.ZeeRex or WSDL |
| 4 | Portal Builder includes in the portal description and technical details of each resource they choose |
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 | Portal Builder uses Dewey term for subject search | |
| 1a1 | Portal Builder uses terminology service to translate natural language search term into a Dewey term | |
| 1b | Portal covers all disciplines | Scenario 4.3 |
| 1b1 | Portal Builder omits Step 1 and performs initial IESR search at Step 2 | |
| 1c | Portal Builder knows which resource they are interested in | Scenario 4.6 |
| 1c1 | Portal Builder performs a title search for the particular resource, and omits Step 2 | |
| 1d | Portal Builder requires XML format | Scenario 4.6 |
| 1d1 | Portal Builder uses IESR Web interface to determine IESR identifier of resource (as Step 1c1) | This step could be omitted if IESR had an interface to return a single entity XML record using its title and entity type. This could be implemented as an extension to the OpenURL interface. This would also provide a m2m lookup service for IESR identifiers, the identifier being in the retrieved record |
| 1d2 | Portal Builder retrieves XML format using IESR OpenURL interface (or a direct retrieval via the IESR identifier), and omits Steps 2 and 3 | |
| 1e | No suitable records found | May also occur at Step 2 |
| 1e1 | Portal will not use IESR | This is failure scenario. IESR must contain a large and comprehensive variety of resources |
| 2a | Portal Builder also wants to find a collection of a particular type | Scenario 4.1 |
| 2a1 | Portal selects collections of a particular type | IESR may need more collection types (Scenario 4.1) |
| 3a | Portal Builder includes only resources that are available to the portal's user community | |
| 3a1 | Portal Builder checks that the authentication requirements of each Collection and its Service, and the terms and conditions of each Collection, match their user community | Scenario 4.1 |
| 3b | Portal Builder does not wish to include transactional services | Scenario 4.3 |
| 3b1 | Portal Builder ignores transactional services | |
| 3c | Service access detail is more complicated than given by IESR description | Scenario 4.5 |
| 3c1 | Portal Builder reads the service's `help' page, which is linked to from the IESR Service description |

Attribution Required;
Non-Commercial;
Share-Alike.