EPrints v3 feature requirements

Feature requirements from v3 London launch meeting

This page is aimed at managers and administrators of repositories based on EPrints software, and invites further feedback on features and issues that were raised at the preliminary EPrints v3 launch meeting in London on 8th December 2006.

The following tables document the features and issues. The left hand column gives the name of the feature or issue requested, the middle column shows how we think that it should fit in with our development plans (with reference to the plan keys below), and the final column is the result of our initial internal discussions about how the feature should be implemented. Particular requests and queries for feedback are highlighted in the final columns, but you are invited to comment on all parts that interest or concern you, including prioritisation as indicated by the development plan columns.

There are various ways you can respond:

Send comments to relevant EPrints lists, replying to the list mail from which you heard about this consultation
Private comments can be sent to Les Carr lac AT ecs.soton.ac.uk, EPrints technical director

Development plans:

3.0	Include in forthcoming 3.0 release
3.1	Include in subsequent 3.1 release (planned for Easter 2007, around 3 months after 3.0)
3.n	Include in an unspecified release after 3.0. Feedback is required to help set priorities and timetables. Note that 3.n features could well appear in 3.1.
P	Plugins development track. Note that plugin releases are independent of the core code release timetable.
H	Not planned for an implementation, but to be released as a "HOW-TO" note showing interested sites how to create the feature for themselves. This may happen for very site-specific features, e.g. LDAP adaptations.
A	Autocompletions – this is the same as the plugins development track.

Feature requests (BLACK SHEET)

Feature	Dev	Comments / Proposal
Reference Manager Import plugin	P	Need sample data from users.
RefWorks Export plugin	P	Need sample data from users.
Lightbox "Export plugin" for Sets of Images (Reading to provide?) Also use as native viewing option for "Collection of Images" type.	P 3.n	Plugin can be used for search results. Also built in for single eprints that have a collection of picture files.
Unknown Referee Status	3.0	General unknown status for all Boolean items, not just 'Referee Status'.
Expiry / renewal of license	3.0 3.n	Simple metadata addition + new script. (Rendering of citation should only mention license AFTER it has expired.) Consolidate all event-based activity under control of "eprints cron", which can also be used to generate_static or send out subscriptions. Also extend search UI to match time periods and provide an 'Export to Calendar' so editors / administrators can be regularly informed of updates on forthcoming changes to the repository contents (and be emailed about them).
Role of individual beyond authorship (e.g. photographer, artistic consultant)	H	Easy metadata alteration but thought unlikely to be used in general. We will provide an explicit "how to" on the documentation site, so that administrators can make the necessary configuration changes.
Aggregates of Items	3.n	The software already handles "list of item refs"; as long as the aggregates are static, we just need to add user interface components (metadata type, rendering, etc.).
De-duplication	A 3.n	Avoid typing in a duplicate of an existing article by use of autocompletion on article title. [Quicktime demo] Also a deduplication action on a QA screen plugin for use by editors and administrators to identify existing duplicates.
Reconciling Authors and Authorities	3.n	Another action button on the QA screen plugin.
Intelligent Cut/Paste Fixer for PDF/Word/HTML	3.n	JavaScript "cleanup" button activated by initial scan of pasted material.
LDAP as Name Authority	H	HOW-TO produced with the rest of the LDAP scripts and advice.
Stats and Usage Reporting	3.n	Screen plugins from the Interoperable Repository Statistics (IRS) project
Auto-extraction of Metadata	3.0 3.n	In 3.0 a trigger on the document upload event can invoke bespoke extraction method. Subsequent versions will include simple extractors.
WebDAV	3.n	Possible to allow the repository (or selected bits of it) to be mounted on a workstation as if it is a disk. Use cases required!
Export to ZIP	3.n	Combine all file downloads for selected eprints into a single ZIP file. Cheap alternative to mounting using WebDAV.
Will autocomplete work for editing imported records?		Not a requirement, but a question. Answer: Yes, but depends on the script! The user may have to delete some fields.
EPrints Application Profile	3.0 – 3.1	Not something that was raised at the meeting, but JISC"s work on the Eprints Application Profile will start to be supported in version 3.0.
Export to MP3	P	Not something that was raised at the meeting, but a never-used capability of EPrints v2 remembered in subsequent discussion. Have your latest abstracts spoken and recorded to MP3, ready for podcasting. Is there support for this feature?
Plugin manager plugin	3.n	Not something that was raised at the meeting, but a feature that emerged in subsequent discussion. An administrator"s screen that helps manage all the installed plugins / screens, including visibility.

Issues (GREEN SHEET)

More config done by librarians, e.g. adding new metadata types, defining new workflows.

3.n

We can do the simpler things quickly, but we don't know what things people want most urgently. Will consult with users, with aim of producing metadata or workflow plugin screens in some form for 3.1. Will become part of a larger effort known as "the admin suite".

Questions. What do you want to see most urgently? Which facilities would you like to be able to control from a web screen instead of a config file? Please be specific!

Expanded workflows

3.n

A request was made to greatly expand the support for workflows in EPrints, to allow complex pathways for action. First some explanation about what is already there, and then a short proposal.

EPrints has used the term "workflow" to refer to the sequence of steps that a depositor has to go through to create an eprint. However, EPrints also has a very generic model of process-based workflows undertaken by editorial teams. An eprint is moved into "editorial review" by a depositor, where it is acted upon by one or more individual editors, each of whom provide various "services". Examples of these services are suitability checking, metadata QA, DOI discovery, mediated input, security clearance, copyright clearance and "finally move to live repository". An editor will see the eprint in their list of "items to review" when its state (metadata) matches their registered subscription (e.g. any journal article from School of Medicine which lacks an ISSN or any item which has completed all QA processes). The eprint can move from one editor to another as a consequence of the metadata changes that are made to it by the individual editors. The eprint can also be rejected back to the depositor with an explanatory message at any stage. All editorial actions are recorded in the item"s history and the editors" history.

To create an explicit workflow structure, EPrints need only (a) make explicit the repository's complete list of editorial services as the potential stages of a workflow (b) create a new piece of metadata for each eprint to describe the actual required stages of its workflow (c) create each kind of eprint with a named workflow (d) allow each editor's subscription to be triggered by the "next requested service" or "next required stage" of the workflow (e) give each editor a "move to next stage of workflow" button. This would create an essential linear pipeline, where the eprint can also be rejected back to the depositor with an explanatory message at any stage.

Questions: Is expanded workflow support necessary? Is the proposal sufficient? Can you supply examples of the workflow that you use or want to support?

Event - awareness

3.n

There was talk about needing a proper 'event-based system', but I think we may have all the components there. Add a metadata 'timer' type (for embargo and expiry) and a proper eprints_cron utility and an extension to search UI and providing an 'Export to Calendar' then editors / administrators can be regularly emailed with updates on forthcoming changes to the repository contents. User feedback / requirements / use cases required.