1 / 11

Functional Requirements for Eprints Application: Meeting Notes and Key Insights

This document captures the key discussions and functional requirements gathered during the Eprints application profile working group meeting held on June 5th at King’s Fund, London. Julie Allinson, Digital Repositories Support Officer at UKOLN, led discussions on stakeholder engagement, metadata requirements, and the importance of identifying complex objects. The meeting focused on enhancing metadata quality, understanding user needs, and ensuring compatibility with various library cataloging and preservation approaches to improve search and repository usability.

dara-lamb
Télécharger la présentation

Functional Requirements for Eprints Application: Meeting Notes and Key Insights

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Functional Requirements Eprints Application Profile Working Group Meeting 5th June, King’s Fund, London Julie Allinson Digital Repositories Support Officer UKOLN, University of Bath UKOLN is supported by: www.bath.ac.uk

  2. Overview • Scope • Stakeholders / designated community • Requirements gathering • Requirements

  3. Scope • In scope • DC elements plus any additional elements necessary • Identifiers for metadata records, data, related resources etc. • Hospitable to the use of a variety of subject access solutions e.g. classification schemes, controlled vocabularies, name authority lists • Establishing an understanding of complex objects and prioritising requirements • Inclusion of properties required to fulfil other search requirements such as institution of origin, research funder, national and regional views, as provided by the RDN • Out of scope • Other metadata formats • Other uses of identifiers. • Decisions on terminology solutions • Decisions on how to model complex objects

  4. Stakeholders • Who is this for? • Designated (user) Community • UK repositories search service [CONSUMER] • UK eprint repository managers/administrators [PRODUCER] • Stakeholder Community • Search service users • JISC Programmes • JISC • Eprint repositories community • Software developers • Repository staff • Repository users • Out of scope? • DCMI community • Other search services • Other funding bodies

  5. Requirements gathering • Why? • To find out what already exists, and • what the community wants • To engage the community in uptake • How? • Existing practice / application profiles / standards • Scenarios and use cases • Eprints UK project conclusions • Working group, feedback group, wider community engagement

  6. Existing practice • Local practices can be seen by searching repositories, examples: • eprints.org, e.g. ePrints Soton • DSpace, e.g. Edinburgh Research Archive • DSpace metadata is qDC: http://www.dspace.org/technology/metadata.html • Fedora, e.g. Queensland QUT • Other, e.g. CCLRC ePubs • More?

  7. Possible scenarios • Consistent metadata for aggregator search service • Search or browse by journal, conference or publication title • The versions question • The latest version • Added-value services • More real-life scenarios needed …

  8. Use case • Primary use case • Application profile for eprints used by UK repositories search service • Use case is … • A step towards identifying requirements • A sequence of events to fulfil the primary use case • Other use cases • For wider uptake and use

  9. Requirements (1) • provide a richer set of metadata than allowed by simple DC, tackling the metadata issues identified here: Issues with current use of simple DC • implement an unambiguous method of identifying the full-text(s) of an eprint • offer a preliminary solution to version identification issues, relating to revisions, status, translations and multiple formats • support search of any, or all, fields, particularly of title, author, description, keyword • support browse by any field, as required (not including description or identifier fields). This may include browse by: • keyword • author • date • publisher • journal, publication, conference, book, series name • originating repository / institution • support subject browse based on knowledge of controlled vocabulary • support filtering of search results and browse tree by type, publisher, date range, status and version

  10. Requirements (2) • enable movement from search results and browse tree to available copies, optionally filtered by format • enable movement from search results and browse tree to OpenURL 'link server' • support citation analysis (between expressions) • support navigation between different 'versions' of the same eprint • be suitable for use in the context of OpenURLs and OpenURL resolvers i.e. support navigation/discovery of particular version of an eprint (e.g. most recent version of the "Author's Original") and navigation/discovery of most appropriate copy of discovered 'version' • be compatible with dc-citation WG recommendations • be compatible with preservation metadata approaches • be compatible with library cataloguing approaches

  11. Questions • Are we happy with the scope? • Are there more methods for gathering requirements? • Do we need more scenarios • More to do? • Agree the scope of ‘eprints’ • Assess usage of resource types for ‘eprints’ • Mappings of local practices

More Related