IESR Use Case 8: Populating IESR by Harvest
| Creator |
Ann Apps, Mimas, The University of Manchester, UK |
| Date |
2006-11-09 |
| Identifier |
http://iesr.ac.uk/use/uses-cases/usecase8.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.
8.1 It is decided to include OpenURL resolver details in IESR by importing data from an OpenURL Resolver Registry, and to keep these details up-to-date by regular daily checks for updated data. When a new resolver is added to IESR by this method, the library is contacted to ensure that they agree to their resolver being described in IESR. They are also asked if they wish to include other details that the OpenURL Resolver Registry doesn't include, such as the preferred link text, as well as additional agent details.
8.2 It is decided to include repository details in IESR by importing data from a registry of OAI repositories, and to keep these details up-to-date by regular daily checks for updated data. When a new repository is added to IESR by this method, the organisation is contacted to ensure that they agree to their repository being described in IESR. They are also asked if they wish to add other details that the OAI repository registry doesn't include, such as standard subject terms, including Dewey, details of other services beyond OAI-PMH and possibly additional agent details.
8.3 It is decided that IESR will share records with a similar registry, NZSR, in New Zealand. NZSR uses the IESR metadata schema. IESR collects all the records from NZSR using its OAI-PMH harvest interface. It reassembles the entity records in a suitable form for indexing in its internal database. Subsequently, IESR collects changed records from NZSR once a week and updates or adds records accordingly. (Conversely NZSR uses the IESR OAI-PMH service to collect IESR records, using Use Case 2.)
Use Case
Use Case Summary
Resource descriptions are added to, and maintained in, IESR by harvesting them from another registry.
Primary Actor (and goals)
| IESR |
To increase the quantity and currency of resources described in IESR by harvesting them from another registry. To quality check resource descriptions, and disseminate resources |
Secondary Actors (and goals)
| Registry |
To provide a public API for gathering content |
| Resource Provider |
To have resources included in IESR, providing increased use of their resourcess |
Stakeholders and Interests
| IESR Users |
To discover and use resource descriptions |
Main Success Scenario
| Step |
Action |
Analysis |
|---|
| 1 |
IESR identifies a suitable registry from which to acquire content |
|
| 2 |
IESR collects records from registry by OAI-PMH |
This will probably require several incremental requests using the resumptionToken |
| 3 |
IESR creates a Contributor record for the harvested registry |
|
| 4 |
IESR performs augmentation on some records automatically, including indication that inclusion was automatic |
A `status' field in the administrative metadata is required that indicates that a record was ingested from another registry |
| 5 |
IESR adds new records to database |
|
| 6 |
IESR checks and augments records manually |
Some de-duplication may be needed. Resource URIs would assist this |
| 7 |
IESR sets up regular incremental harvesting from registry to react to any updates |
|
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 |
|---|
| 2a |
Registry doesn't have an OAI-PMH harvest interface |
|
| 2a1 |
IESR sets up specific code to harvest via a proprietary API |
Requires development of software specific to registry |
| | | |
| 3a |
IESR has an inclusion policy (e.g. only UK repositories in Scenario 8.2) |
|
| 3a1 |
IESR selects records for inclusion according to policy |
|
| | | |
| 6a |
Imported data is not in IESR XML format |
Scenarios 8.1, 8.2 |
| 6a1 |
IESR generates IESR XML records from the imported data values |
Requires development of software specific to format |
| 6b |
IESR has insufficient manual effort available to augment description |
|
| 6b1 |
Imported resource will be incomplete in IESR |
This is a partial failure scenario. IESR staff are required for augmenting descriptions |
| | | |
| 7a |
Resource provider is notified that their descriptions are in IESR |
Scenarios 8.1, 8.2 |
| 7a1 |
Any additions requested by the resource provider are added by IESR |
|
