New Stuff

Discussing EPrints Development

Please use eprints-devel to discuss future development. To review changes to our tickets and repository, subscribe to eprints-changes.

To subscribe to the lists, send a mail with one of the following lines in the message body to majordomo@ecs.soton.ac.uk

subscribe eprints-devel
subscribe eprints-changes

WARNING: eprints-changes may be HIGH traffic.

Release Plans

Exact schedules are not yet decided.

We plan to release a beta of EPrints 3.1 in the first few months of 2008.

3.1 will be a one way upgrade from 3.0 but with minimal hassle. A few config. files may require tweaks, and the database structure may be slightly changed. 3.1 will introduce new features.

Once the first 3.1 beta is released we will make a branch. We will then develop new features for 3.2 while providing bug fix releases for 3.1 and 3.0. Once 3.1 appears to be reliable, we declare it stable, and stop providing bug fix releases for 3.0. In theory no new features will be added after 3.1 beta-1, but this may be a rule we bend. A more fixed rule is that no new features will be added to 3.1 after 3.1.0 is released, so we can aim for stability. (phew)

3.1.x releases will, like 3.0.x, only provide bug fixes and very small changes, such as minor configuration options, which will not change the behavior unless you set them.

Quite a few parts of EPrints 3.1 will be Plugins or sets of plugins and cgi scripts. The collective term for these is "extensions". A bunch of files together which can be added to EPrints to add functionality, without requiring hacking the core code. Where possible we will release the extensions and plugins individually on EPrints Files. This serves two purposes:

1. Sites which don't yet want to upgrade to an unstable release can get the key feature they need.
2. It means each extension will get tested by more sites, earlier.

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.

Scalability

Planned as extension

• Subjects input component that doesn't load everything at once - AJAX fetching of lower levels

Planned

• 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.

Proposed

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

I think the ideal would be to only rebuild view pages when necessary -- ie when new subjects have been added or new eprinte have been added, just regenerate the views in which they need to appear. Is there some reason that can't be done? Ben 23:06, 11 December 2007 (GMT)

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:

Planned

• 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)
• generate and email warnings about anomalous metadata states (e.g. items "in press" for more than 24 months) as trailed in ECS

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 better with the authors' desktop environemnt (laptop / Microsoft Office / file system browser.

Planned as extension

• A drag-and-drop-interface client 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

Planned

• 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
• Export and RSS feeds for view pages.
• add_field and remove_field bin scripts.
• ZIP , wget and .tar.gz feature for file upload.
• Custom templates for searches, views and abstract pages for basic collection styling.

Proposed

• 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.)
• Plugin "masking" - to allow an installed plugin to subclass an existing plugin but to be called instead of it. This would be very useful for the DC plugin.
• AJAX autocompletion on search fields.

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.
• Validation Workflow Component (needs some bugs ironing out)