Difference between revisions of "New Stuff"

From EPrints Documentation
Jump to: navigation, search
(New Features Planned for EPrints 3.1)
(Planned as extensions)
Line 47: Line 47:
* User interface control panels for some (hopefully, eventually, all) repository configuration that are currently performed by editing configuration files.
* User interface control panels for some (hopefully, eventually, all) repository configuration that are currently performed by editing configuration files.
* Config file browser
* Config file editor  
* Config file editor  
* EPrints config reloader  
* EPrints config reloader  

Revision as of 17:00, 11 December 2007

New Features Planned for EPrints 3.1

This page is to collect the features that we have planned or had requested to appear in EPrints 3.1 . This page does NOT constitute any form of guarantee as to the features that will actually appear!

This page shows both planned and proposed features.

  • Planned features are features that will be in 3.1 unless they run into difficulty or priorities shift.
  • Proposed features are features that we'd like to do, but probably won't.
  • ... as extension; these are new features which can be packaged up entirely as an extension, with no change to the core code. These are intended to be included in the final 3.1.0 release, but may be released separately on files.eprints.org before that time. If things slip they make not make it into the 3.1 series, but will be available from files.eprints.org.

Roughly speaking, planned things need to actually have a specification, whereas proposed things can be a bit vauge.


Planned as extension


  • Handling HUGE authority lists (use SQL database with index; just document this, no code needed)
  • Eliminate need to run generate_abstracts: by detecting when a flag has changed and rebuilding abstract page on demand.


  • Eliminate need to run generate_views by rebuilding pages on request if they are more than N hours old.

Increased Interoperability

No final decision yet on exact set of new plugins. May just come down to "those that are ready when we go to beta."

  • More importers to improve the ease of deposit by leveraging existing editorial effort in external services (e.g. arxiv, ACM Digital Library, IEEE Digital Library, Web of Science, DSpace, Fedora, ORE, PDF and Office metadata extractors)
  • Extending data-entry quality with more Name Authorities (e.g. Conferences) and other auto-completion (uncontrolled keywords).
  • Increase the value of holdings with a wider range of exporters (e.g. wordprocessors, spreadsheets, email, ZIP, MP3 for podcasting, RDF for the Semantic Web, DSpace, Fedora, ORE)

Repository-scale Quality Management:


  • Add a QA Screen similar to admin screen, which will be a place holder for QA tasks
  • Find a nice way to add a QA role (possibly separate from editor role)

Proposed as extensions

  • duplicate detection
  • legacy metadata correction using name authorities and authoritative sources such as CrossRef
  • efficient batch checking and editing including one-step search and replace across the whole repository, e.g. replace "DeRoure" with "De Roure" in all Creator.Surname fields or batch editing - allowing a single metadata field to be efficiently checked and corrected in multiple eprints, e.g. a screen containing editable Journal Name fields from 100 separate eprints.

Administration Configuration Management

Planned as extensions

  • User interface control panels for some (hopefully, eventually, all) repository configuration that are currently performed by editing configuration files.
  • Config file browser
  • Config file editor
  • EPrints config reloader
  • EPrints abstracts regnerator

These should all check that the config is OK.. config file should revert if needed.

Possibly these will require some uber-admin role.

Proposed as extensions

  • HTML Visualisation of configuration files (workflow, phrases etc.)
  • Skins manager for branding.
  • Manager for object types (e.g. article, thesis) and metadata fields (e.g. "experimental technician" for a data set or "director" for a multimedia object.)
  • Multilingual phrase editor.
  • Deposit Workflow editor.
  • Process Workflow editor (see below)
  • Subject Hierachy editor (already exists)
  • Browse View and Bespoke Search editors
  • Plugin Manager to control non-core software.

Desktop Integration

Making EPrints work from a desktop.

Planned as extension

  • A drop-interface for submitting files, using SWORD. This would create a basic record in the repository.
  • Read-only interface via webdav

Proposed as extension

  • Read/Write webdav interface.

Web 2.0

Pending outcomes from Web 2 meeting

Other Features


  • More built-in metadata for scientific data applications.
    • URIs for documents.
    • Need some advice from the experts on this one. ie. The guys who've already been doing this stuff.
  • the ability to search subobjects and related items, eg. search eprints by document format (already done)
  • Elimination of need for generate_static (this is mostly done)
  • Improved generate_views to produce variations of a view (by first author, by year etc.)
  • Action icons for delete/deposit/edit etc on "Manage Items" and "Review". This is done, but the icons could be nicer :-)
  • EPrints Toolkit - a service-level API that is available through scripting and REST interfaces. This is done, but still requires security and may gain some features before 3.1


  • Process Workflow: as well as the deposit workflow, a process workflow will manage the various sequences of actions that an eprint can undergo from creation to final deposit (and beyond). This may include collaborative authoring, problem management, refereeing, copyright clearance, security clearance, IPR checking, metadata quality checks, e-journal and conference workflows. (EPrints currently allows, but does not manage, process workflows.)

Proposed as Extension

  • Virtual Collections: an individual eprint may be represent a collection of other eprint items; mainly used for image collections, workshop proceedings or learning objects composed of teaching assets. This may be achievable just with a new default type.
  • Calendar view: calendar screen to track all embargo and license expirations, plus other planned events and timeouts.
  • Increased support for "eprints application profile" Dublin Core recommendations.
  • Web Services interface: currently in beta, awaiting debugging of the .NET SOAP interface.
  • Better Semantic Web support (see Harry Mason's PhD work)
  • Integration with Google Scholar or Web of Science (for citation capture and analysis.
    • Gather citation data (score) from somewhere
    • Provide view
    • Provide search/order facility on this.
  • Map widgets for input/output of location metadata
  • Interoperable Statistics: statistics on the download use of individual eprints, eprint collections (per user, per research group, per community) or whole repository.