| 2.2 Feature & Functionality Table |
|
|
|
|
|
| Feature |
CDSware |
DSpace |
Eprints |
i-Tor |
MyCoRe |
|
|
|
|
|
|
|
|
| Technical
Specifications |
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1.0 Standards
Information |
|
|
|
|
|
| |
1.1 OAI-PMH version supported |
OAI-PMH 2.0 |
OAI-PMH 2.0 |
OAI-PMH 2.0 |
OAI-PMH 2.0 |
OAI-PMH 2.0 |
| |
1.2 Z39.50 protocol compliant |
No |
No |
No |
No |
No1 |
| |
1.3 Open source license1 |
GNU GPL |
BSD |
GNU GPL |
GNU GPL |
GNU GPL |
| |
1.4 Latest version release date |
Apr-02 |
Aug-03 |
Mar-02 |
Aug-03 |
Oct 03 |
| |
1.5 Latest version number |
0.0.9 |
1.1.1 |
2.2.1 |
1.1.4 |
1.0 |
|
|
|
|
|
|
|
|
| 2.0 Hardware |
|
|
|
|
|
| |
2.1 Minimum hardware requirements2 |
No specific requirements1 |
No specific requirements1 |
No specific requirements |
No specific requirements |
No specific requirements2 |
| |
2.2 SAN support3 |
|
Yes |
Yes |
|
|
|
|
|
|
|
|
|
|
| 3.0 Software |
|
|
|
|
|
| |
3.1 Operating system (tested) |
Linux/Solaris |
UNIX/MacOS/Windows2 |
GNU/Linux/Solaris1 |
Linux/Windows |
AIX/Windows/Linux/ Solaris |
| |
3.2 Programming language |
Python/PHP |
Java |
Perl |
Java |
Java |
| |
3.3 Database |
MySQL |
PostgreSQL3 |
MySQL |
MySQL & Oracle |
MySQL,
PostgreSQL; XML:DB compliant; Commercial databases3 |
| |
3.4 Web server |
Apache/PHP, Python |
Any4 |
Apache 1.3 2 |
Jetty |
Apache |
| |
3.5 Java servlet engine |
|
Any4 |
N/A |
Jetty |
Any4 |
| |
3.6 Search engine |
cdsware2 |
Lucene |
N/A |
Lucene |
Via JDBC and
XML:DB |
| |
3.7 Other |
WML: Website META Language |
OAICat |
N/A |
|
Apache Ant build tool |
| 4.0 Clients
supported |
All HTML 4.0 clients |
All web browsers |
Netscape,
Mozilla, IE, Lynx3 |
All HTML 4.0 clients |
All web browsers |
|
|
|
|
|
|
|
|
| 5.0 Staff
requirements4 |
|
|
|
|
|
| |
5.1 UNIX systems administrator |
Yes |
Yes |
Yes |
Recommended1 |
Recommended |
| |
5.2 Java programmer |
|
No |
Recommended |
No |
No |
Recommended5 |
| |
5.3 PERL programmer |
|
No |
No |
Recommended4 |
No |
No |
| |
5.4 Python programmer |
|
No3 |
No |
No |
No |
No |
|
|
|
|
|
|
|
|
| 6.0 Installed
base |
|
|
|
|
|
| |
6.1 Number of installations |
7+4 |
10+5 |
106 5 |
10 |
10 6 |
| |
6.2 Geographic coverage |
Europe & US5 |
Worldwide |
Worldwide6 |
Netherlands |
Germany & Sweden |
|
|
|
|
|
|
|
|
| Feature |
CDSware |
DSpace |
Eprints |
i-Tor |
MyCoRe |
|
|
|
|
|
|
|
|
| Repository &
System Administration |
|
|
|
|
|
| 7.0
Set-up/Installation |
|
|
|
|
|
| |
7.1
Automated installation script |
Yes |
Yes |
Yes |
Yes |
Yes |
| |
7.2 System update script |
|
Yes |
Yes6 |
Yes7 |
No |
Via CVS repository |
| |
7.3 Update system update without overwriting customized features5 |
Yes |
|
Yes8 |
Yes |
Yes7 |
| 8.0 Module-level API(s)6 |
Yes6 |
Yes7 |
Yes |
Yes2 |
Yes |
|
|
|
|
|
|
|
|
| 9.0 User
registration, authentication & password administration |
|
|
|
|
| |
9.1 Password administration |
Yes |
Yes |
Yes |
Yes |
|
| |
|
9.1.1 System-assigned passwords |
Yes7 |
Yes |
No |
No |
|
| |
|
9.1.2 User selected passwords |
Yes |
Yes |
Yes |
Yes |
|
| |
|
9.1.3 Forgotten password function7 |
Yes |
No |
Yes |
No |
|
| |
9.2 User registration verification/Other security mechanisms8 |
MySQL table/Apache ACL |
email/X.509 |
MySQL table9 |
No |
RDBMS table |
| |
|
9.2.1
Edit user profile |
Yes |
No |
Yes |
Yes |
|
| |
9.3 Limit Access by User Type9 |
Yes |
Yes |
Yes |
No3 |
|
| |
9.4 Multiple Authentication Methods10 |
Yes |
Yes |
No |
No4 |
|
| |
9.5 Limit Access at File/Object Level11 |
Yes |
Yes |
Yes |
Yes |
No |
| 10.0 Content
Submission Administration |
|
|
|
|
|
| 10.1 Define multiple collections within same
instance of system12 |
Yes8 |
Yes |
Yes |
Yes |
|
| |
10.1.1 Set different submission parameters for each collection13 |
Yes |
|
|
|
|
| |
10.1.2 Home page for each collection |
Yes9 |
Yes |
No |
No |
|
| 10.2 Submission Stages14 |
|
Submit,
Modify, Revise, Approve, etc.10 |
Assemble,
Pending, Approved |
|
Yes5 |
No1 |
| |
10.2.1 Segregated submission workspace15 |
Yes |
Yes |
Yes10 |
Yes5 |
|
| |
10.2.2 Submission roles16 |
Submitters,
Moderators, Reviewers, Approvers, Administrators |
Submitters,
Reviewers, Approvers, Editors |
User, Editor,
Administrator11 |
Yes5 |
|
| |
10.2.3 Configurable submission roles within collections17 |
Yes |
Yes |
|
Yes5 |
|
| 10.3 Submission
Support |
|
|
|
|
|
| |
10.3.1 Email notification for submitters18 |
Yes9 |
Yes |
Yes |
Yes |
No |
| |
10.3.2 Email notification for content administrators19 |
Yes9 |
Yes |
Yes |
Yes |
No |
| |
10.3.3 Personalized system access for registered users20 |
Yes |
Yes |
Yes |
Yes |
No |
| |
|
10.3.3.1
View pending content submissions21 |
Yes |
Yes |
Yes |
n/a |
No |
| |
|
10.3.3.2
View approved content22 |
Yes |
Yes |
Yes |
n/a |
No |
| |
|
10.3.3.3
View pending content administration tasks23 |
Yes |
Yes |
|
n/a |
No |
| |
10.3.4 Distribution license24 |
|
|
|
|
|
| |
|
10.3.4.1 Request distribution
license25 |
No |
Yes |
No |
No |
|
| |
|
10.3.4.2
Store distribution license with content26 |
No |
Yes |
No12 |
No |
|
| 11.0 System
generated usage statistics and reports |
|
|
|
|
| |
11.1 System-generated usage statistics27 |
No11 |
Yes |
No13 |
Yes6 |
No |
| |
11.2 Usage reports28 |
No |
Yes |
No |
Yes |
No |
|
|
|
|
|
|
|
|
| Feature |
CDSware |
DSpace |
Eprints |
i-Tor |
MyCoRe |
|
|
|
|
|
|
|
|
| Content
Management |
|
|
|
|
|
|
|
|
|
|
|
|
|
| 12.0 Content
Import/Export |
|
|
|
|
|
| |
12.1 Upload compressed files |
Yes |
Yes8 |
Yes |
Yes |
No1 |
| |
12.2 Upload from existing URL |
Yes |
No |
Yes |
Yes7 |
No1 |
| |
12.3 Volume import for objects29 |
Yes |
Yes |
Yes |
No |
Yes |
| |
12.4 Volume import for metadata30 |
Yes |
Yes |
Yes |
Yes |
Yes |
| |
12.5 Volume export/content portability31 |
Yes |
Yes |
Yes |
No8 |
Yes |
|
|
|
|
|
|
|
|
| 13.0
Document/Object Formats |
|
|
|
|
|
| |
13.1 Approved file format function32 |
Yes |
Yes |
Yes |
No |
No |
| |
13.2 File formats ingested33 |
All12 |
All |
All14 |
All |
All |
| |
13.3 Submitted items can comprise multiple files34 |
Yes |
Yes |
Yes |
|
Yes |
|
|
|
|
|
|
|
|
| 14.0 Metadata |
|
|
|
|
|
| |
14.1 Basic metadata schema35 |
Standard Marc21 |
Qualified Dublin Core |
Dublin Core |
Any |
Qualified Dublin Core8 |
| |
14.2 Support for extended metadata36 |
Yes |
Custom |
Yes |
Any |
Any9 |
| |
14.3 Metadata review support37 |
Yes |
Yes |
Accept, Edit,
Bounce (require changes), Delete |
No |
No |
| |
14.4 Metadata export38 |
OAI-Marc export |
Custom XML schema9 |
Custom XML Schema |
Yes |
Yes |
| |
14.5 Allow metadata harvesting39 |
Yes |
Yes |
Yes |
Yes |
Yes |
| |
14.6 Add/delete metadata fields |
Yes |
|
|
Yes3 |
Yes |
| |
14.7 Set default values for metadata40 |
Yes |
|
|
Yes3 |
|
| |
14.8 Supports Unicode character set for metadata |
Yes |
Yes |
Yes |
No |
Yes |
| 15.0 Real-time updating and indexing of accepted
content |
Yes |
Yes |
Yes15 |
Yes |
Yes |
|
|
|
|
|
|
|
|
| Feature |
CDSware |
DSpace |
Eprints |
i-Tor |
MyCoRe |
|
|
|
|
|
|
|
|
| Dissemination
(User Interface & Search Functionality) |
|
|
|
|
| 17.0 User
Interface |
|
|
|
|
|
| |
17.1 Modify interface "look &
feel"41 |
Yes |
Yes10 |
Yes16 |
Yes |
Yes |
| |
17.2 Apply a custom header/footer to static or dynamic pages |
Yes13 |
No |
Yes |
Yes |
Yes |
| |
17.3 Supports multiple language interfaces |
Yes |
Yes |
Yes |
Yes |
Yes |
| |
17.4 End user document folders42 |
Yes |
No |
No |
Yes |
|
| |
17.5 Discussion forum support43 |
No14 |
No |
Yes17 |
Yes |
No |
|
|
|
|
|
|
|
|
| 18.0 Search
Capability |
|
|
|
|
|
| |
18.1 Full text44 |
Yes |
Yes11 |
No18 |
Yes |
No10 |
| |
|
18.1.1 Boolean logic |
Yes |
No |
No |
Yes |
|
| |
|
18.1.2 Truncation/wildcards45 |
Yes |
No |
No |
Yes |
|
| |
|
18.1.3 Word stemming46 |
No |
No |
No19 |
No |
|
| |
18.2 Search all metadata47 |
Yes |
Yes |
Yes |
Yes |
Yes |
| |
|
18.2.1 Boolean logic |
Yes |
|
|
Yes |
Yes |
| |
|
18.2.2 Truncation/wildcards |
Yes |
Yes |
|
Yes |
|
| |
|
18.2.3 Word stemming |
No |
Yes |
|
Yes |
Yes |
| |
18.3 Search selected metadata fields48 |
Yes |
Yes |
Yes |
Yes |
Yes |
| |
18.4 Browse |
|
|
|
|
|
| |
|
18.4.1 By author |
Yes |
Yes |
Yes20 |
Yes9 |
Yes |
| |
|
18.4.2 By title |
Yes |
Yes |
Yes20 |
Yes9 |
Yes |
| |
|
18.4.3 By issue date |
Yes |
Yes |
Yes20 |
Yes9 |
Yes |
| |
|
18.4.4 By subject term |
Yes |
No |
Yes20 |
Yes9 |
Yes |
| |
|
18.4.5
By collection |
Yes |
Yes |
Yes20 |
Yes9 |
Yes |
| |
18.5 Sort search results |
|
|
|
|
|
| |
|
18.5.1 By author |
Yes |
No |
Yes |
Yes |
Yes |
| |
|
18.5.2 By title |
Yes |
No |
Yes |
Yes |
Yes |
| |
|
18.5.3 By issue date |
Yes |
No |
Yes |
Yes |
Yes |
| |
|
18.5.4 By relevance |
No |
No |
No |
Yes |
|
| |
|
18.5.5 By
other |
Any metadata field |
No |
Yes21 |
Yes9 |
Yes |
| 19.0 Indexed by
Google/Other Search Engines49 |
Possible15 |
Yes |
|
Yes |
Possible |
|
|
|
|
|
|
|
|
| Archiving |
|
|
|
|
|
|
|
|
|
|
|
|
|
| 20.0 Persistent
document identification50 |
|
|
|
|
|
| |
20.1 System-assigned identifiers |
Yes |
Yes |
Yes |
Yes |
Yes |
| |
20.2 CNRI Handles51 |
|
Yes |
Yes |
No |
Yes |
|
|
|
|
|
|
|
|
| 21.0 Data
preservation support |
|
|
|
|
|
| |
21.1 Defined digital preservation strategy52 |
Yes16 |
Yes |
No |
No |
No1 |
| |
21.2 Preservation metadata support (see also 14.2)53 |
Yes17 |
Yes |
No |
No |
No1 |
| |
21.3 Data integrity checks |
No |
MD5 checksum |
MD5 checksum |
No |
MD5 checksum |
| 22.0 Object
history/Version control |
Versioning system |
ABC Harmony
data model |
Some |
No |
No1 |
|
|
|
|
|
|
|
|
| System
Maintenance |
|
|
|
|
|
|
|
|
|
|
|
|
|
| 23.0 System
support |
|
|
|
|
|
| |
23.1 Documentation/manual |
Yes |
Yes |
Yes |
Yes3 |
Yes |
| |
23.2 Listserv |
Yes |
Yes |
Yes |
Yes3 |
Yes |
| |
23.3 Bug track/feature request system |
Yes |
Yes12 |
No |
Yes3 |
No |
| |
23.4 Formal support/help desk |
For fee |
No |
No |
No |
No |
|
|
|
|
|
|
|
|
| Notes on System
Features & Functionality |
|
|
|
|
|
| 1) For most of the systems discussed here, the operating system
and all of the supporting software are Open Source software licensed under
the GNU General Public License (GPL). MIT and Hewlett-Packard have agreed to
license all DSpace software with an open source, BSD license. DSpace intends
to add any third-party components under the same terms. |
|
| 2) Given the variety of local conditions, none of the systems
specify minimum CPU requirements. Where the system web site describes
potential hardware configurations, we have provided a link to that
information. |
|
| 3) Indicates that the system can operate on a storage area
network (SAN). |
|
| 4) Depending on the software indicated under Item 3.0
("Software"), some systems will require some staff technical
experience with the operating system, storage system, webserver, command
manager, and/or search engine. Systems administrators and programmers can be
allocated resources and not necessarily full-time staff, depending on the
scale and requirements of a particular implementation. |
|
| 5) Allows the system to be updated without overwriting the
modifications an institution might make to page templates, emails, help
pages, search pages, etc. |
|
| 6) Most of the systems allow some level of local customization
of the system. In some systems this is accomplished by modifying scripts.
Others provide an Application Programmer Interface (API) that allows a
programmer at the adopting institution to modify system functionality. |
|
| 7) Provides a secure process by which users who have forgotten
their passwords can select a new password without human intervention.
Typically, the system uses the user’s email address to administer the new
password. |
|
| 8) Registers and authenticates users who are authorized to
submit content to and/or administer content in the repository, as distinct
from the global audience of anonymous users who can access content that is
publicly accessible. |
|
| 9) Allows the repository administrator to limit access to
certain content based on the user’s level of authorization. This could be
used, for example, to limit access to an academic department’s working papers
to faculty members in that department. Similarly, it could be used to limit
access to materials that are restricted by research funding stipulations. |
|
| 10) Allows the repository administrator to apply various levels
of access restrictions to submitted items based on user type. For example,
most items would be accessible globally to all users; some items might be
available via IP address to a university community; and other items might be
limited to ID/password access to a relatively small group of users. |
|
| 11) Allows the repository system administrator to restrict
access to individual files within an item submission. For example, a
dissertation might contain images or other component files to which access
should be restricted. |
|
| 12) Allows the institution to define multiple content
collections and/or groups of users within one installation of the system.
Collections could be defined in various ways, including by subject matter,
content type or purpose, audience, etc. (e.g., a working paper series or
collection of curriculum support materials). User groups could represent
academic departments, schools, research institutes, administrative
departments (e.g., museums, hospitals, etc.), as needed to address the needs
of the implementing institution. |
|
| 13) Allows the repository administrator to set different content
submission and review/approval parameters (if desired) for each of the
collections and/or user groups defined within the repository. |
|
| 14) Allows repository system administrators to designate the
number and types of stages through which content might pass from initial
submission to inclusion in the repository. |
|
| 15) Provides a separate pre-public workspace that stores
incomplete and/or pre-approval stage content submissions. This can simplify
the process for submitting a document by allowing the user to save an
interrupted or incomplete submission, rather than abandon an incomplete
submission altogether. |
|
| 16) Provides for a configurable set of review functions and
administration within a repository. (For example, content approval (per
whatever criteria the user group has adopted); metadata review, editing, and
approval; etc.) |
|
| 17) Some systems apply the same roles and process across all
collections in the repository. Others specify these functions at the
collection level, allowing different collections within one instance of the
system to offer different submission and review processes. |
|
| 18) Sends an email notification to a user regarding the status
of a content submission (e.g., that the item has been approved for inclusion
in the repository or has been returned to the submitter). |
|
| 19) Sends an email notification to a content administrator
(e.g., a reviewer, approver, etc.) when a submission has been routed to them
for review, approval, etc. |
|
| 20)
Allows registered users access to content and process status information.
This type of function can allows users to determine the status of content
submissions and/or pending content approval tasks. |
|
| 21) Allows users to review all the content that they have
submitted to the repository. |
|
| 22) Allows users to review and/or complete unfinished content
submissions (that is, content submissions that were initiated, but not
completed for some reason). |
|
| 23) Allows content administrators (e.g., reviewers, editors,
approvers, etc.) to review submissions awaiting processing. |
|
| 24) To allow the host institution to administer and disseminate
the material submitted to the repository, a repository typically needs each
contributor to grant the institution an irrevocable, non-exclusive,
royalty-free license to distribute the content, to translate its format for
the purpose of digital preservation, and to maintain the content in
perpetuity. |
|
| 25) Allows the institution to integrate a request for rights to
maintain and distribute the content as part of the content submission
process. Some systems support multiple license terms, which may vary by
content collection or by user. Others address such license terms by
procedures outside the system software itself. |
|
| 26) Allows the institution to store specific license terms with
each content submission. As license terms may change over time, or by content
type, this enforces clarity as to which terms apply to each submission. |
|
| 27) Allows repository administrators to track the use and
adoption of the repository. This facilitates system capacity planning and
supports internal resource allocation and budget support issues. |
|
| 28) Pre-set and/or configurable usage reports can add to the
usefulness of system-generated usage statistics. |
|
| 29) Allows an institution to import existing digital libraries
and other digital material. |
|
| 30) Allows a repository to import metadata for existing digital
collections. |
|
| 31) An explicit expectation for an institutional repository is
that the content managed by the system will survive the system itself and can
migrate as new technologies evolve. This feature refers to the manner in
which content can be exported from the system. |
|
| 32) This feature allows the system administrator to limit
content submission to approved format types.
This allows the repository to indicate which digital formats it is
willing to accept (from a policy perspective) as opposed to which formats the
system is capable of accommodating (from a technical perspective). This can
help support repository policies designed to ensure ongoing access to, and
preservation of, the repository’s contents. |
|
| 33) Refers to the digital formats that a system is capable of
ingesting (as opposed to those an institution may decide to support as a
matter of policy). |
|
| 34) Allows a user to submit multiple files and/or file types a
part of a single deposit. This permits, for example, a user to submit a
research paper along with its supporting data set or a conference paper along
with the overhead presentation given at the conference. |
|
| 35)
This refers to the extent to which a system can store metadata related to a
content submission and make that metadata searchable via a user interface.
The OAI protocol harvests unqualified Dublin Core metadata. All the systems
here support that baseline Dublin Core metadata, which is what makes it
possible to search across repositories using the systems. |
|
| 36) As a lowest common denominator, the unqualified Dublin Core
will not be sufficiently detailed to serve the needs of many institutional
repository collections. Therefore, in
addition to the Dublin Core, the OAI protocol supports parallel metadata
sets, allowing repositories to expose additional metadata specific to a
particular collection or content type. Some systems support (or plan to
support) other metadata standards, including those for domain-specific, preservation,
and rights metadata. |
|
| 37) For the metadata harvesting to be effective, a repository
must establish a quality control process and quality threshold on the
metadata stored in the system. This will prove especially true for
repositories that intend to allow authors to self-archive their papers and
provide their own metadata. This feature supports a metadata approval process
whereby metadata can be reviewed, corrected, enhanced, and/or approved prior
to being made available through the system. |
|
| 38) Allows an institution to export the repository’s metadata,
in XML or some other structured format, to facilitate migration to a
subsequent system. |
|
| 39) Allows system administrator to "turn off" the
ability of OAI harvesters to harvest metadata from the repository overall.
This would effectively disable the repository’s interoperability. |
|
| 40) Allows the repository system administrator to establish
defaults for metadata fields to simply metadata entry. For example, an
institution field could be set to default to the hosting institution (for
example, Institution="University of Pennsylvania"). |
|
| 41)
Allows an institution to modify the look of the interface through an API or
by adapting scripts that control the service's presentation. |
|
| 423) Allows users to store repository content in personalized
document folders within the system. |
|
| 43) System supports discussion forums within the repository. |
|
| 44)
This item refers to the internal system search and retrieval software and
presentation layer software, not to external service providers or search
engines. Some of the systems that don’t have an integrated search engine
provide instructions for adding an Open Source search tool. |
|
| 45) Allows the use of wildcards (for example, *=multiple
characters; ?=single character). |
|
| 46) Allows a search to return results based on the root form of
a word. For example, “land” will also match “landed,” “landing,” lands,” and
“landed.” |
|
| 47) Allows a user to search all defined metadata fields. |
|
| 48) Allows a user to search selected metadata fields. For
example, search only the “title” or “author” fields. |
|
| 49)
Indicates that the system can be searched by Google and other internet search
engines, if the search tool is pointed at the correct system server. |
|
| 50) Persistent naming allows a repository to change its internal
retrieval mechanisms and/or physically move content without compromising
reference citations and other links. These persistent identifiers remain
valid even were the repository content to be migrated to a new system or were
management responsibility for the repository to be assigned to a third party. |
|
| 51) The CNRI Handle System allows institutional repositories to
achieve the continuity and persistent naming described above (see 20.0). The
Handle System protocols enable a distributed computer system to store handles
of digital resources and resolve those handles to locate and access the
resources. The information associated with each handle can be changed to
reflect the current state of the identified resource without changing the
handle itself, thus allowing the name of the item, as well as reference
citations and other links, to persist over changes of location and other
state information. |
|
| 52) Some systems have integrated features that facilitate the
long-term digital preservation of submitted material. These can be important
features, as preservation best practice suggests taking steps early in the
life-cycle of an electronic resource mitigates the cost and technical
difficulty of preserving it in the future. However, a successful digital
preservation program also requires extensive policy development, funding, and
planning to support such preservation support features. Further, it should
not be inferred that absence of these features precludes digital
preservation. |
|
| 53) Preservation metadata stores technical information that
supports preservation decisions and action, documents preservation action
taken, records the effects of preservation strategies, to ensure the
authenticity of digital resources over time, and notes information about
collection management and the management of rights. |
|
|
|
| System-Specific
Notes |
|
|
|
|
|
| CDSware Notes |
|
|
|
|
|
| 1)
System requirements depend on collection size, number of expected users,
database platform, etc. |
|
| 2) CDSware uses its own indexing technology and search engine. |
|
| 3) Only needed if institution intends to add new features to the
system. |
|
| 4) Exact number unknown as CERN does not follow up all
installations/downloads of the CDSware package. |
|
| 5) Switzerland (3), France, Germany, Italy, and the US. |
|
| 6) API and command line interface. |
|
| 7) Not mandatory. |
|
| 8) Supports hierarchy of collections (any tree), as well as
Virtual Collections ('horizontal views'). |
|
| 9) Configurable. |
|
| 10) Wide range of options: see
<http://doc.cern.ch/EDS/current/guide/english/> |
|
| 11) Uses third-party
tools, such as Webalizer. |
|
| 12) CERN Conversion Server can be attached to CDSware to
automate conversion to PDF (for documents):
<http://doc.cern.ch/Convert> |
|
| 13) The collections home page can also be customized. |
|
| 14) In development for next release. |
|
| 15) The HTML formats of CDSware records can either be created
on-the-fly or they can be pre-processed, saved to files to allow web search
engine indexing. |
|
| 16) Automated conversion to PDF format. |
|
| 17) Marc21 standard. |
|
|
|
|
|
|
|
|
|
| DSpace Notes |
|
|
|
|
|
| 1) For suggested DSpace hardware configurations, see:
http://dspace.org/what/dspace-hp-hw.html |
|
| 2)
DSpace has been tested on multiple UNIX platforms (including Linux, hp/ux,
Solaris), as well as on MacOS and Windows. |
|
| 3) Institutions using DSpace are experimenting with various
database systems, including DB2, MySQL, and Oracle. |
|
| 4) While DSpace ships with Apache and Tomcat, the system will
work run with any web server and java servlet engine. It has also been tested
with JBOSS and others. |
|
| 5)
Ten DSpace implementations are in full production worldwide, and over 100
additional implementations are in progress (worldwide). |
|
| 6) Updating script requires some manual changes. |
|
| 7) For each major module. |
|
| 8) Uploads compressed files, but doesn't uncompress them. |
|
| 9) METS in development. |
|
| 10) Requires some programming. |
|
| 11) Via Google or customized Lucene implementation. |
|
| 12) Through the SourceForge system. |
|
|
|
|
|
|
|
|
|
| Eprints Notes |
|
|
|
|
|
| 1) Designed to run in most UNIX environments. |
|
| 2) Apache 2.0 compatibility in development. |
|
| 3) Does not use javascript. CSS support preferred, but not
essential. |
|
| 4) PERL programmer requirements depend on the extent of
customization an institution requires. |
|
| 5) 88 running v2; 18 running v1.1. |
|
| 6) UK, Ireland, India, Italy, Brazil, Australia, USA, Canada,
France, Austria, Sweden, Germany, Slovenia. |
|
| 7) Updating script requires some manual changes to configuration
files. |
|
| 8)
Can update system without overwriting modifications to page templates,
emails, help pages, and search pages. |
|
| 9) Can be modified to use other systems, e.g., LDAP. |
|
| 10) State of files is stored in SQL database. |
|
| 11) Default. Submission roles can be modified and/or extended. |
|
| 12) Could be configured to provide this functionality. |
|
| 13) Planned. |
|
| 14) Default formats: PostScript, PDF, ASCII, and HTML. |
|
| 15)
Batch processing (to improve system performance) in experimental stage. |
|
| 16) Requires some programming. |
|
| 17) Uses third-party software tools. |
|
| 18)
Full-text searching is under development. While Eprints.org does not yet have
an integrated full-text search capability, collateral full-text search
engines have been integrated by several Eprints installations. For example,
the Indian Institute of Science (IISc), in Bangalore, India
(http://eprints.iisc.ernet.in/) has integrated the Greenstone Digital Library
Open Source Software to provide full-text searching, and the Archive SIC
(Archive Ouverte en Sciences de l'Information et de la Communication) has
implemented the htdig search engine (see: http://archivesic.ccsd.cnrs.fr/
search.html). |
|
| 19) Currently only provides stemming for plurals. Fuller
stemming in development. |
|
| 20)
Not set as a default, but is configurable by system administrator based on
institution-supplied metadata. |
|
| 21) System administrator can select sort fields. Search results
can be sorted by any standard field. |
|
|
|
|
|
|
|
|
|
| i-Tor Notes |
|
|
|
|
|
| 1) Recommended for installation. |
|
| 2) i-Tor allows institutions to extend certain aspects of the
interface using Java (for example, to create custom views for search
results). |
|
| 3) Planned for December 2003. |
|
| 4) Does not support validation by IP. |
|
| 5) i-Tor is designed to provide an institution with the tools to
set up any required workflow, but does not design a workflow into the system
itself. |
|
| 6) Uses Analog third-party software. |
|
| 7)
i-Tor allows data to be harvested directly from a researcher's home page.
Assuming that the individual researcher's home pages are adequately
maintained, this would eliminate the need for faculty to periodically update
the repository. |
|
| 8) Planned. |
|
| 9) Configurable by system administrator based on
institution-supplied metadata. |
|
| 10) In development. |
|
|
|
|
|
|
|
|
|
| MyCoRe Notes |
|
|
|
|
|
| 1) Planned. |
|
| 2)
System requirements depend on collection size, number of expected users,
database platform, etc. |
|
| 3) Open Source environment: JDBC compliant RDBMS (tested: MySQL,
PostgreSQL); XML:DB compliant databases (Apache Xindice, eXist, Tamino); and commercial environment: IBM
Content Manager with IBM DB2. |
|
| 4) Tested: Tomcat and Websphere. |
|
| 5) XSL skills required for customizing user interface layout. |
|
| 6) Ten installations for MILESS, the predecessor on which MyCoRe
is based. Five unofficial MyCoRe test sites. |
|
| 7) Possible via CVS. |
|
| 8) Configurable. |
|
| 9) Configurable. MyCoRe does not have a hard-coded metadata
model. The system provides a Qualified Dublin Core data model as an example,
but users can define/configure their own data models as required. |
|
| 10) Planned, via Lucene. Some limited text search functionality
is given by the underlying XML:DB API MyCoRe uses (for example for searching
in the abstract/description of objects). |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|