Create an account to submit your own knowledge base entries..

All topics Knowledge Base



	Articles Extras Plugin
	Backup
	Common Log Format (CLF)
	Connexions & Rhaptos (Rice University)
	Custom Block Manager
	Custom Block Manager OCS
	eJournal-Software
	External RSS Feeds
	Galley Icons
	GNU EPrints (University of Southampton)
	Google Site Search
	HathiTrust Digital Library (collaboration of 26 United States research institutions)
	Jalali calendar support
	LatexRender support
	Metadata
	NLM Citation Plugin
	OCS Plugins
	OJS Plugins
	ONIX DOI xml Export
	Open Journal Systems OJS (University of British Columbia and Simon Fraser University)
	Paymethod::Moneris
	Piwik
	Polished Theme
	Popular Articles Block Plugin
	Public Folder Browser Plugin
	Reviewer Index Plugin
	SciELO Export Plugin
	Select Role Block
	Static Pages
	Static Pages OCS
	SWORD 1.2 Repository Deposit
	Technology Standards
	Thesaurus (tematres integration)
	Vancouver Citation Plugin
	VG Wort Zählmarken
	Views report

[Article: gnu eprints (university of southampton) | Discussion ]

Has one of the biggest user community worldwide
Easy-to-use repository application
Strenghs:
- Runs on multiple OS (Windows, Linux, etc.)
- Most features are customizable on individual publication level
- Supports an easy author-initiated submission into the repository
- Has a big community with supporting users and developers
Weaknesses:
- Installation and configuration can only be realized on the command line level via Perl scripts (no GUI installer and no opportunity of configuration via web-based GUI)
- not completely scalable
EPrints is rather a repository for publications which are already published, in so far it doesn't try to show the peer review and the journal production

Institutional affiliation and other indicators of the viability of the open-source project
Name of system:	GNU EPrints
Current version of system:	3.2.2
Tested version of system:	3.0
URL of project homepage:	http://www.eprints.org
Institutional affiliation:	School of Electronics and Computer Science, University of Southampton
Age of project:	Project founded in 2000
Notes on long-term viability of project:	Formal community programme. Fee-based EPrints Services unit. EPrints seems to be widely-deployed and well-supported.
Degree of deployment:	EPrints is perhaps the most widely deployed of the open-source ePublishing systems under consideration by this study. As of this writing, the application's wiki page lists 223 separate, known archives actively using the software in production.
Type of open-source license:	GNU General Public License (GPL), Version 2 or later
Other documentation (Webliography):


Technical requirements, maintenance, scalability, and documented APIs
Local install or ASP?:
Operating system requirements:	GNU/Linux. Also Solaris and MacOS. Version 3 now runs under Apache on Windows.
Hardware requirements:
Application server requirements:	Apache, with mod_perl
Web server requirements:	Apache, with mod_perl
Primary programming language:	Perl 5.6.1
Auxiliary programming languages:
Database server requirements:	MySQL
Application framework:
Other software requirements:
Required skills:	While version 3 of this application can run under Windows, all instances of it must run under Apache, so experience setting up Apache is required as is experience setting up the many Perl modules that are required. Unfortunately, the installation documents seem to assume that EPrints will be the only application running in Apache, i.e., that it will not be running on a shared server. This is a bad assumption, which led to problems during the installation phase. Moreover, as I painfully found out, the order of operations in which the installation occurs must be followed to the letter, even if there are one or two steps that seem, on the surface, like the order in which they execute would not be relevant. Still, the documentation for installing EPrints on Ubuntu provides a step-by-step installation procedure that, if followed and not deviated from in the slightest, results in a successful install. A GUI-based installer would be nice. As it stands, installation is handled via a somewhat primitive Perl script.
Internal backup and restore functions:
Scalability: Application:
Scalability: Data:
API: Code extensibility:	The application provides a defined API for the creation of plugins. It also provides support for packaged "extensions", basically entire sets of plugins all installed as a single package.
API: Batch Ingest:
API: Batch Ingest formats:
API: Batch Export:
API: Batch Export formats:
API: Support of JSR 170:
API: Support for OAI Harvesting (OAI-PMH):
API: Support for eduSource Communication Layer (ECL):
API: API: Support for other Web services:


Submission, peer review management, and administrative functions
Support for multiple, discrete publications:	Multiple archives are repositories are supported, each housing multiple documents, files, etc.
Multiple administrative roles:	The application provides four distinct roles: The main Administrator; the Repository Administrator; the Editor within a given repository; and the individual User.
Administrative roles configurable:	The roles provided by the application appear for be hard-coded, i.e., you cannot add to the number of these roles.
Submission into system initiated by authors:	A self-signup is provided for new authors. Once an account is generated, authors may submit to a particular respository. Their submission enters the idiosyncratic workflow for that repository where it may be reviewed and approved by, e.g., a repository editor before being put on public display.
Metadata fields configurable:	The metatdata is alterable on a per-archive basis. This is accomplished via editing of two configuation files on the command-line. More, if a field is added within these configuration files, it must likewise be manually added/configured in the database. The wiki indicates that work is underway to create a "tool" which will make this whole process much easier.
Editorial workflow configurable per publication:	Separate workflows can be created on a per-repository basis using XML configuration files contained in the directory tree for that particular repository instance. It appears that segments ("stages") of the custom workflow can be restricted per user type, i.e., to Repository Administrators, to Editors, to regular Users.
Automated email alerts to authors, editors and reviewers:
Stylesheets, customizable look and feel per publication:	The look and feel is configurable on a per-repository basis. Again, this is controlled via command-line manipulation of configuration files and contents of repository directories. With each change, such things as static pages must be regenerated, the default configuration for the archive must be reloaded, and ideally the Web server must be restarted.
Versioning:
Archiving:


Access, formats, and electronic commerce functions
Accessibility of system:
Accessibility of document output:
Internationalization support:	The application and database fully supports Unicode encoding (utf-8). Locale files are installed and configured at the command-line.
Output in multiple document formats:	Insofar as the application accepts multiple documents formats for input, it likewise provides those documents to the user in the same format in which they were submitted.
Document formats supported:	The default document formats supported include: Plain text; HTML; PDF; Postscript; MS Powerpoint; MS Word; JPEG; PNG; GIF; TIFF; BMP; MPEG; Quicktime; AVI.
Plug-in requirements:
Usability notes:
Citation linking:
OpenURL resolver:
RSS feed:
Digital rights management:
Full-text search and retrieval:	Yes. The following are required: xpdf (for PDF indexing); wvware (for MS Word indexing); lynx (for HTML indexing).
Federated searching:
Authentication mechanisms:	The application can be configured to support authentication against an external LDAP server. By default, it authenticates against its internal authentication store. Interestingly, the application can be configured to be a Login-Only repository (where all interations with it must first be authenticated) or as a repository in which user registration is not even required.
Subscription services:	Insofar as this application is not a electronic publishing system in the same sense as the other systems under consideration by this study are, it does not provide subscription services. In another sense, though, it supports RSS and Atom feeds, so at least in that sense the notion of "subscription" is provided.
Electronic commerce functions:	The application does not appear to provide any sort of ecommerce functions. Its main bent, in fact, is to provide fully open access to materials.
Context-sensitive Help support:


Additional program-specific criteria: security, archiving, aggregation, ...

Summary data
Strengths:	The application nicely provides facility for controlled-vocabulary indexing of documents using the Library of Congress Subject Headings (http://en.wikipedia.org/wiki/Library_of_Congress_Subject_Headings) and/or the organizational structure of one's local institution. The default application is simple, yet powerful. The administrative roles and default, streamlined workflow are well-thought-out and useful. The workflow, branding, and import/export is all configurable, though all at the command-line by a system administrator and not particularly easy or straightforward.
Weaknesses:	Installation procedures assume that ePrints is being installed on its own server. Web server dependent (Apache). Primitive installation script. The configuration of the application as a whole, as well as of each individual archive, is performed at the command-line by a system administrator, using text-based configuration files. The EPrints wiki indicates that administrative tools, presumably GUI in nature, are currently under development.