EprintsAP use case 1
From DigiRepWiki
This document is part of the Eprints Application Profile Wiki.
[edit]
JISC Digital Repositories Programme Use Case
Use Case Name
| Application profile for eprints used by UK repositories search service |
Use Case ID
| Eprints_useEprintsAP_use_case_1_case_1 |
Authors
| Author 1 | Julie Allinson |
Project
| Eprints Application Profile Working Group |
Date Created
| 17-05-2006 |
Use Case Summary
|
This use case describes a proposed situation in which the RDN/INTUTE search service implements the Eprints Application Profile for harvesting from repositories and offering search, browse and other functionality to its consumers. |
Primary Actor (and goal)
| Eprints Search Service | Offering cross search of UK repositories, and other services; harvesting from repositories. |
Other Actors (and goals)
| PROSPERO | To offer an interim repository service. |
| Individual repositories | To receive deposit and provide access. |
| Other search services / harvesters | Harvesting / cross search. |
| UKOLN / Eduserv Foundation | To propose the application profile and ensure it is fit for purpose. To register the DCAP in the JISC IE Schema registry. |
| Producer | To deposit materials in the repository. |
| Consumer | To find materials. |
| Repository administrators | To ensure sufficient, accurate and high quality metadata is captured. |
Stakeholders and Interests
| JISC | Funding body |
| RDN/INTUTE | Success of search service. |
| Repository Management | Successful and cost effective repository. |
| Universities | Profile-raising through better access and promotion of its research outputs. |
| DCMI Community | Promotion of correct use of DC. |
| Digital Repositories Programme phases 1 and 2 | To learn from example and to see findings guide the development of the profile and search service. |
Main Success Scenario
| 1 | RDN/INTUTE implements Eprints Application Profile for harvesting. |
| 2 | Institutional repositories implement the profile and structure their data accordingly to enable harvesting by the RDN/INTUTE service, and potentially others. |
| 3 | The profile and cataloguing guidelines ensure metadata offered for harvesting is consistent across repositories. |
| 4 | Metadata enables UK repositories search service to support browsing by a defined set of fields, including, but not limited to author, subject, repository |
| 5 | Metadata enables UK repositories search service to support fielded searching of a defined set of fields, including, but not limited to author, title, keyword etc.. |
| 6 | Metadata enables UK repositories search service to filter search results by a defined set of criteria, e.g. document format, , type etc. |
| 7 | In particular, the metadata enables search, browse, or filter by publication (journal, book, conference proceedings etc.) name or conference name. |
| 8 | Metadata clearly identifiers the originating repository and institution. |
| 9 | Metadata also enables different versions [expressions] and formats [manifestations] of the same Work to be linked, maintaining their relationship to one another |
| 10 | Metadata enables UK repositories search service to replace older version in aggregated content with more recent version |
| 11 | Metadata makes an unambiguous distinction between different versions [manifestations] and formats [expressions] of the same work (possibly harvested from different repositories) and whether those relate to differences in language, intellectual content or publication status. |
| 12 | Links and identifiers are consistently and unambiguously created for each work, manifestation and expression. |
| 13 | Metadata is structured to enable moving from search results and browse tree to an OpenURL ‘link server’, if desired. |
| 14 | Metadata is structured to allow citation service to support citation analysis (between works). (? Not needd now??) |
| 15 | RDN/INTUTE service supports other value-added services (not yet scoped). |
| 16 | RDN/INTUTE service is deemed successful. |
Extensions
| 2a | Institutions do not implement Eprints Application Profile |
| 2a1 | RDN/INTUTE service must harvest oai_dc, or |
| 2a2 | RDN/INTUTE service refuses to harvest repositories not implementing the profile |
| 2a1 | Additional advocacy activity to encourage uptake. |
| 3a | Guidelines are not used effectively; metadata quality suffers in ensuing service |
| 3a1 | Guidelines must be re-written |
| 4,5,6,7,8a | Incoming data does support the profile and thus these are not possible. |
| 4,5,6,7,8a1 | Scope of search service suffers |
| 4,5,6,7,8b | Requirements gathering exercise establishes that these are not necessary. |
| 4,5,6,7,8b1 | Profile must be modified to reflect this |
| 9a | Different versions are listed together in search results, without any indication of their relationship to one another. |
| 9b | Authority of data is questioned because of multiple search results. |
| 11a | It is impossible to distinguish between different works, expressions and manifestations. |
| 11b | Authority of data is questioned because it is impossible to understand the status of search results. |
| 12a | Inconsistent use of identifiers and links mean search service cannot interpret incoming data accurately |
| 12a1 | Quality of search service suffers. |
| 16a | Service is not widely used |
| 16a1 | Increased advocacy |
| 16a2 | Changes to profile and guidelines are needed. |
| 16a3 | Changes to service are needed. |
