Difference between revisions of "New Stuff"

From EPrints Documentation
Jump to: navigation, search
(Increased Interoperability)
(Repository-scale Quality Management:)
Line 28: Line 28:
  
 
== Repository-scale Quality Management: ==
 
== 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)
 +
 +
=== Proposed ===
 +
 
* duplicate detection
 
* duplicate detection
 
* legacy metadata correction using name authorities and authoritative sources such as CrossRef
 
* 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.
 
* 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.
* Add a QA Screen similar to admin screen
 
* Add a qa role.
 
* Les to spec. some QA Tools.
 
  
 
== Administration Configuration Management ==
 
== Administration Configuration Management ==

Revision as of 16:47, 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.
  • Planned 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.

Scalability

Planned as extension

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.

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)

Proposed

  • 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

User interface control panels for all repository configuration that are currently performed by editing configuration files.

  • 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.
  • Config file editor
  • EPRints config reloader
  • EPrints abstracts regnerator
    • These should all check that the config is OK.. config file should revert if needed.

Other Features

  • 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.)
  • 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.
  • 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.
  • Integration with Researcher's Desktop (the repository is just another Network Place via WebDAV).
    • Suggest a drop-interface for submitting, using SWORD
    • Read interface via webdav
    • Maybe allow update of files. (maybe only while in inbox, maybe not)
  • Web 2.0 support (see outcomes from [1] Web 2 meeting]
  • 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.
  • More built-in metadata for scientific data applications.
    • URIs for documents.
  • Map widgets for input/output of location metadata
  • the ability to search subobjects and related items, eg. search eprints by document format
  • the improved way gen_static works so that most pages can be rebuilt automatically to save running the script all the time (current exception= auto js and auto css but that's doable)
  • improved generate_views with new features
  • the action icons for delete/deposit/edit etc on "Manage Items" and "Review"
  • API Toolkit - a service-level API that is available through scripting and REST interfaces
  • Interoperable Statistics: statistics on the download use of individual eprints, eprint collections (per user, per research group, per community) or whole repository.