• No results found

Open Source Software for Use in Learning Object Repositories. A Review and Assessment

N/A
N/A
Protected

Academic year: 2021

Share "Open Source Software for Use in Learning Object Repositories. A Review and Assessment"

Copied!
43
0
0

Loading.... (view fulltext now)

Full text

(1)

Texas Center for Digital Knowledge College of Information 1155 Union Circle 311068 Denton, Texas 76203-5017 Phone: 940-565-2473 Fax: 940-369-7872

Open Source Software for

Use in Learning Object Repositories

A Review and Assessment

Prepared for

The Florida Distance Learning Consortium

OnCoRe Blueprint Project

by

The Texas Center for Digital Knowledge

William E. Moen, Principal Investigator <william.moen@unt.edu>

OSS LOR Project Team Cadi Lusk Samuel Muwanguzi

Jill Siewert

(2)

Table of Contents

1. Project Overview ... 1

1.2. Background and Purpose of the Study... 1

1.3. Project Methodology, Assumptions, Limitations ... 1

2. Open Source Software Overview ... 2

2.1. Freely Available Source Code ... 3

2.2. Community-based Development ... 4

3. Repository Overview ... 4

3.1. Terminology ... 4

3.2. Functions and Components ... 5

3.3. Implementation Styles ... 6

4. Organization of Report ... 8

5. Digital Repository Platforms for LORs ... 2

5.1. DSpace ... 2 5.1.1. Background ... 2 5.1.2. Overview of Functionality ... 2 5.1.3. Technical Specifications ... 9 5.2. EPrints ... 10 5.2.1. Background ... 10 5.2.2. Overview of Functionality ... 10 5.2.3. Technical Specifications. ... 11 5.3. Fedora Commons ... 11 5.3.1. Background ... 11 5.3.2. Overview of Functionality ... 12 5.3.3. Technical Specifications ... 13

6. Content Management Systems for LORS ... 13

6.1. Drupal ... 13 6.1.1. Background ... 13 6.1.2. Overview of Functionality ... 13 6.1.3. Technical Specifications ... 14 6.2. Plone... 14 6.2.1. Background ... 15 6.2.2. Overview of Functionality ... 15 6.2.3. Technical Specifications ... 16 7. Hybrid Platforms ... 16 7.1. eduCommons ... 16 7.1.1. Background ... 16 7.1.2. Overview of Functionality ... 17 7.1.3. Technical Specifications ... 18 7.2.Rhaptos/Connexions ... 18 7.2.1. Background ... 18 7.2.2. Overview of Functionality ... 18 7.2.3. Technical Specifications ... 19

8. Summary of Findings from Implementors Using OSS Platforms and Applications ... 19

8.1. Factors Influencing Choice of OSS ... 20

8.2. Common Advantages Specific to OSS... 20

8.3. Common Challenges ... 20

8.4. Resources Needed ... 21

8.5. Factors Influencing Choice of Software... 21

9. Platform Specific Findings from LOR Implementors – Digital Repository Platforms ... 21

9.1. DSpace ... 21

9.1.1. Factors Influencing Choice of OSS... 21

(3)

9.1.3. Necessary Resources ... 22

9.1.4. Advantages/Challenges/Precautions Specific to DSpace ... 22

9.2. EPrints ... 22

9.2.1. Factors Influencing Choice of OSS... 22

9.2.2. Factors Influencing Choice of EPrints ... 22

9.2.3. Necessary Resources ... 22

9.2.4. Advantages/Challenges/Precautions Specific to EPrints ... 23

10. Platform Specific Findings from Implementors – Content Management Systems ... 23

10.1. Drupal ... 23

10.1.1. Factors Influencing Choice of OSS... 23

10.1.2. Factors Influencing Choice of Drupal ... 23

10.1.3. Necessary Resources ... 24

10.1.4. Advantages/Challenges/Precautions Specific to Drupal ... 24

11. Platform Specific Findings from Implementors – Hybrid Platforms ... 24

11.1. eduCommons ... 24

11.1.1. Factors Influencing Choice of OSS... 24

11.1.2. Factors Influencing Choice of eduCommons ... 24

11.1.3. Necessary Resources ... 25

11.1.4. Advantages/Challenges/Precautions Specific to eduCommons ... 25

12. Emerging Trends and Future Directions in OSS and LORs ... 25

13. Summary and Conclusions ... 27

References ... 28

Appendix A: Technical Report Template to Record Specific Details ... 32

(4)

Open Source Software for Learning Object Repositories:

A Review and Assessment

1. Project Overview

This review and assessment of Open Source Software (OSS) platforms and applications was

commissioned by the Florida Distance Learning Consortium (FDLC). The project was carried out by the Texas Center for Digital Knowledge at the University of North Texas over a nine-month period from January through August 2009.

1.2. Background and Purpose of the Study

The FDLC requested the Texas Center for Digital Knowledge to undertake a study to review open source software (OSS) platforms and applications that could be used in the context of implementing learning object repositories (LORs). This report presents the results of that study.

The review’s primary focus was to collect information on OSS alternatives available for institutions and organizations considering the use of OSS for their LORs. The review focused on technical specifications, features, and functions of the underlying software rather than implementation-specific use of the OSS. However, as part of the study, the project team interviewed implementors using the platforms and applications reviewed in this report; some implementation-specific information is provided as part of this report.

FLDC identified a number of OSS platforms and applications to review. These included: • DSpace

• Fedora Commons • Drupal

• Connexions

During the initial phase of the study, the project team identified other OSS platforms and applications that are currently in use in specific LOR applications. This report also includes information on the following:

• Eprints • Plone

• eduCommons

For each platform and application, the report offers a brief synopsis. In addition, a detailed description of specific features and functionality is provided for each platform and application. Prior to the sections describing each platform and application, the report presents an overview of open source software in general and terminology used in the report. This helps set the stage for discussion of individual OSS platforms and applications. Finally, the findings from interviews with implementors of specific OSS platforms and applications are presented.

1.3. Project Methodology, Assumptions, Limitations

Two primary phases of work comprised the study:

1. Collection and compilation of information on each OSS platform and application 2. Interviews with implementors of OSS platforms and applications reviewed.

(5)

In Phase 1, project team members examined publicly available sources to gather information. We used the information to develop the overviews and the details of specific features and functionality. Individual implementations using the OSS platforms and applications were also identified. Based on the information gathered in Phase 1, a list of implementations was developed and interviews were arranged with key personnel at the implementations. The project team conducted approximately hour-long interviews with the key personnel from specific implementations.

At the outset of the study, the Principal Investigator (PI) made a number of assumptions about the study; several of those assumptions turned out to be problematic. The following lists the key assumptions and provides a comment indicating the assumption’s effect on the study:

LOR landscape was straightforward: The project team realized early in the study that the LOR landscape is complex in terms of the OSS software being used. See Section 3.3 for a discussion of implementation types and styles.

Each platform/application would be used in multiple implementations of LORs: It turned out that the number of LORs using the OSS platforms and applications reviewed in the study is not large. For example, while the number of DSpace implementations is very large, LOR-specific implementations of DSpace could not easily be found.

Good instances of LORs using the platforms could be identified: In the context of the preceding bullet item, the project team did not have a large number of candidate implementations to work with when identifying potential implementations to use in the interview phase.

People associated with the platforms would readily review our compiled information for accuracy: To ensure accuracy of the details of features and functionality included in this report, we asked key developers or organizations responsible for the OSS platforms and applications to review our results. Although we had some responses to our requests, we did not receive the level of responses we had expected.

In addition to these assumptions, the team discovered that publicly available information did not always provide the level of detail or currency needed for our report. We identify in the reports the version number of a release that is covered by the report. We were disappointed in not receiving responses from the key developers when we requested reviews of our data. Such feedback could have confirmed the data we compiled in terms of features and functionality. Although some unanticipated situations related to the assumptions affected study, the study produced a wealth of information about the OSS platforms and applications. We have confidence that the information contained in this report is accurate given the extent of the information we were able to compile.

2. Open Source Software Overview

This section provides an overview of the concept of OSS. It is not intended to be a comprehensive treatment of OSS, but rather an introductory overview for readers not familiar with the concept. Important topics such as the business case for using OSS or guidelines for decision-makers in choosing OSS over proprietary software are not addressed.

OSS is not a relatively new concept, although in recent years it has evolved a strong and influential worldwide following, contesting the dominance of proprietary software. Generally, OSS refers to a computer program or software, developed through a collaborative effort, whose source code is freely available to the general public for use and modification. Hundreds, if not thousands of OSS products currently exist. Recognizable examples of OSS software include:

• Apache HTTP Server (web server) • Linux (operating system)

(6)

• MySQL (database)

• Mozilla FireFox (web browser)

Hundreds, if not thousands of OSS products currently exist. We can assign the following three general characteristics to OSS:

• Free to download and use

• Access to and ability to modify source code • Licenses that govern use

While available free of charge to download and use, this does not mean that there are no costs involved in using OSS. As one of the implementers we interviewed said, “when choosing to use OSS, an

organization is making a commitment to people.” Appropriate staffing, knowledgeable technical people, hardware and other technical infrastructure need to be in place. Therefore, the care and feeding of OSS platforms and applications becomes the responsibility of the organization using the software.

The following two sections provide additional, and sometimes complicating, details to this simple characterization.

2.1. Freely Available Source Code

In contrast to proprietary software – in which the source code is often licensed, acquired at a cost, and cannot be altered or redistributed without permission from owners – users of OSS are legally allowed to access, use, modify, and redistribute the source code and derivative works under an OSS License. The complexity arises due the number and variety of types of licenses. The following aspects of OSS are

defined by the Open Source Initiatives,

OSS licensing is available at:

Minimally, the distribution terms of any OSS must comply with the criteria mentioned below.

Free redistribution: The software will never require a royalty or other fee for downloading the code, even if the code has been altered.

Source code. If the software is distributed in an executable form, the raw form must be made available as well. Deliberately making source code complicated and difficult to follow is not allowed.

In addition, the following relate to the licenses governing OSS:

Derived works. The license allows modifications and derived works to be made from the source code. When the modifications are distributed, they have the same licensing terms the original software carried.

Integrity of the author's source code. The license may require derived works to carry a different name or come in the form of a patch to ensure the original author keeps the credit for their work.

No discrimination against persons or groups. The license must not discriminate against any person or group of persons.

No discrimination against fields of endeavor. The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.

(7)

Distribution of license. The rights attached to the program must apply to all versions, modifications, and redistributions of the license.

License must not be specific to a product. If a part of a program is extracted from the software, the licensing still applies to the program segment.

License must not restrict other software. The license must not place restrictions on other software beyond itself. For example, the license must not insist that all other programs installed on the server be open-source software.

License must be technology-neutral. No provision of the license can restrict the platforms the software is installed on or restrict its use by certain people.

2.2. Community-based Development

The development environment of OSS often differs significantly from the controlled environment where commercial software development takes place. While commercial development is typically conducted by paid software engineers, OSS development makes use of a community of volunteer software designers and/or knowledgeable users to develop the core of the software’s source code and release it to the public at no cost. A second significant characteristic of this community development style is the use of early and frequent releases of the software, enabling the entire community (in some cases millions of users) to participate in the identification and debugging process. Finally, the direction of future OSS development is typically determined by the community as well. Simply stated, if added functionality is desired, an

individual or user group develops the code for that functionality and submits it back to the community for others to use (or not) and possible inclusion into the core (if successful).

3. Repository Overview

The LOR OSS landscape is complex and mildly overwhelming to those unfamiliar with its intricacies, as reflected by the variety of platform types examined in this report. To assist in developing an

understanding of this landscape, we provide a list of key concepts and terms pertaining to digital repositories. Further, before delving into specifics of technical features and functionality of specific OSS platforms and applications, it is beneficial to have, in addition to the terminology, an overview of important functions and components – also known as a technical stack – of a digital repository. Finally, as indicated earlier, the project team identified a variety of implementation types and styles. These are presented as a way of grouping the OSS platforms and applications reviewed in the study.

3.1. Terminology

To assist in clarifying the concepts surrounding “learning object repositories”, the project team developed the following definitions for key terms used in this report:

Application: A computer program or software used to perform specific work.

Application program interface (API): A type of middleware that enables an administrator to request various services from the application within itself or from outside applications. • Application server: Can refer to hardware or to a software framework. In our context, it is a

software framework that supports the construction of applications via a set of components, for example, components that provide transaction processing, security, and other services. An application server such as Zope is an example of application server that connects repository applications such as Plone to its database.

(8)

Content management system (CMS): A software application that facilitates the creation, management, and publication of web content (e.g., digital media, scripts, text, etc.) through a series of interfaces, frequently designed for nontechnical users. Common features include user management, workflow, versioning of content, publishing of content to a repository, separation of semantic layer from layout. CMS are usually oriented more towards the creation and

management of a whole “page” and only has generalized support for uploaded “objects”. Typically, a CMS has a database backend where the website content is stored, templates or themes that provide a consistent user interface across all sections of the website, cascading style sheets (CSS) to format text on the presented web pages, and easy ways to update and add content. Drupal and Plone are examples of CMS.

Digital repository platform: A software platform that provides minimally an interface for adding content to the system (including the creation of metadata), an interface for

searching/browsing/retrieving content, a database for storing content, and an administrative interface to facilitate collection management and preservation activities. A digital repository is usually more oriented towards managing objects and metadata with only simple support for web pages and user administration. DSpace and Fedora are examples of digital repository platforms. • Implementation: A specific instance of theinstallation and configuration of all components of a

digital repository platform, a content management system, or a learning object repository. • Learning management system (LMS): The software platform used to conduct classes in an

online environment and includes features for course delivery (lectures, notes, and other course materials), assessment (tests, grade books) and community engagement (message boards, chat, email, etc.). Leaning management system is also known as Course Management Systems or Virtual Learning Environments (VLE). BlackBoard (proprietary), Moodle (open source), and Sakai (open source) are commonly used LMS in educational environments.

Learning object (LO): A digital resource (simple or complex) that can be used to support learning. Examples include images, Power Point presentations, project ideas, lecture notes, animations, videos, etc.

Learning object repository (LOR): An implementation of a platform or application that, at a minimum, stores and provides access to learning objects.

Middleware: Any software that connects two or more independent software applications, allowing them to exchange data. Middleware occupies the space between the user interface and data-management components. An application server such as Zope is an example of middleware that connects a repository's applications such as Plone to its database. Another example is the API. • Open courseware (OCW): Open access collections of educational materials used and created

by educators at institutions of higher education and organized into courses of study. OCW is designed to promote an open and reusable body of learning that is accessible worldwide but is not designed to give formal credit towards a degree.

Platform: An environment in which software applications can run.

3.2. Functions and Components

At minimum, four core functions are essential to any LOR implementation. These include: • An interface for adding content to the system

• An interface for searching/browsing/retrieving content • A database for storing content

(9)

• An administrative interface to facilitate collection management, configuration, preservation, and other activities

Additional features and services may include functions such as interoperability with a LMS and other systems, interaction with metadata harvesting services, and authoring of content.

An implementation of a repository requires the installation and configuration of four major components: • A server, typically using Unix/Linux or Windows as an operating system

• A web server (e.g., Apache or IIS and related web application tools) • A relational database (e.g., MySQL, DB2, Oracle, Postgres, SQL server) • Repository software

Typically, each component builds on and uses the other component to function. Therefore, a server running a Windows or Unix-based operating system must exist before a web server and relational

database can be installed on it. Once those components are in place, the repository software provides the framework that allows these components to work together as a digital repository.

3.3. Implementation Styles

In studying OSS LOR software and their implementations, three different methodologies of implementation emerged.

The first implementation style employs relatively straightforward, out-of-the-box style software such as DSpace and EPrints. The creators of this software specifically designed it to meet the needs of a repository (i.e., it contains all the functions needed for input, workflow, searching/browsing/retrieval capabilities, collection management, metadata creation and harvesting, user authentication, etc.). Although an implementer may choose to customize aspects of the repository (e.g., the web interface and additional metadata schema support), once installed and configured the software requires minimal modifications to function as a repository.

The second implementation style is based on a content management system (CMS) such as Drupal and Plone. As defined above, these platforms were not designed specifically for use as digital repositories. They were primarily page rather than object oriented, and they offered minimal metadata support. A style of implementation that bridges between a pure CMS approach and the hybrid approach below uses a digital repository platform such as the Fedora Commons repository as its back-end repository and combines it with a content management system (CMS) such as Drupal to provide the user-friendly front-end web interface to access the repository contents. This style of implementation requires more in the way of programming and attention to information architecture than out-of-the-box platforms. However, in the context of Drupal and Fedora, the Islandora (a Drupal module) enables communication between Drupal and Fedora thus making this style of implementation relatively easy to accomplish and create a LOR implementation.

The third implementation style employs a highly customized hybrid platform, often based upon a web CMS such as Plone or a general purpose digital repository platform such as Fedora. For this form of implementation, the platform provides the underlying structure required for input, collection management, publishing, user authentication/security, and other functions. Additional layers of middle-level software (applications developed locally, available commercially, or as OSS) are added onto the framework to provide/support for other repository functions. These functions include data models, workflow, additional interfaces for content discovery or collection building, support for additional metadata schema and harvesting, and application programming interfaces (API) for customizing the software and extending features as needed. This style of implementation requires the highest level of technical and programming support in order to function as a repository. Examples of hybrid LOR platforms include Rhaptos (the

(10)

Plone-based platform developed for the Connexions repository at Rice University), and eduCommons (the Plone-based platform developed to support the OpenCourseWare initiative).

Typically, the second and third implementation styles are used to accommodate local repository requirements and/or to fit into existing information systems. When successful, however, some hybrid platforms are eventually repackaged for distribution as out-of-the-box style LOR platforms. This

appropriation and reuse of code for new projects is a legitimate practice that can be considered the heart of OSS development. Finally, our review suggests that the repository software may be a vital component in any application that uses and offers support for authoring, collaboration, and other publishing services, Connexions being a powerful example of such an implementation. Figures 1 - 3 illustrate both the organization and layering of the technical components and the different implementation styles.

Figure 1. Digital Repository LOR Implementation

(11)

Figure 3. Hybrid Repository LOR Implementation

4. Organization of Report

The rest of this report is organized into two parts: 1) information on each of the platforms and applications we examined; and 2) summaries of interviews with implementers and discussion of trends we noted during our research. The details on each platform and application are organized into the different categories as discussed in Section 2, OSS Platforms Reviewed:

• Digital Repository Platforms o DSpace

o EPrints

o Fedora Commons • Content Management Systems

o Drupal o Plone • Hybrid Platforms

o eduCommons o Rhaptos/Connexions

For each platform and application, we provide a short narrative regarding the background, funding, and current direction of development; an overview of the platform's functionality, architecture, and features; followed by a list of the technical specifications required for its implementation. In our analysis of data we first start off with a general summary followed by more specific details for each platform.

A supplementary document, Technical Specifications Report, that accompanies this report provides detailed information – specific features, functionally, and other technical information – for each platform and applications. Included in the supplementary document is a report that provides cross-platform comparison of the technical features. The project team used the form presented in Appendix A to record the technical features, functions, other parameters for each of the examined platforms and applications. Table 1 lists the first and second level categories of information compiled for the supplementary

document. Discovery

1.0 Users' Options for Browsing the Repository 2.0 User Options for Searching the Repository Personalization

3.0 Users' Options for Personal Customization Community and Evaluation

4.0 User Grouping, Evaluation and PURL's Meta Tagging

5.0 Metadata Architecture

6.0 Exporting/Importing Metadata

7.0 Metadata Vocabularies and Automatic Population 8.0 Metadata Error Prevention

9.0 Users' Interaction and Workflow Content Upload & Management 10.0 Content Upload

11.0 Workflows

12.0 Object Management 13.0 File Management

(12)

Aggregation and De-aggregation 14.0 Multiple Elements Management Digital Rights Management

15.0 Copyright, Licenses and Sharing Presentation

16.0 Look and Feel Customization Integration and Interoperability 17.0 Integration and Interoperability Installation and Support

18.0 Community Support, Reporting and People Needed to Install

System Considerations and Specifications 19.0 User Management

20.0 Tracking and Reporting 21.0 Packaging and Specification Platform Profile

22.0 Software Infrastructure and Configurations Desktop Requirements

23.0 Desktop Requirements Training

24.0 Training Availability Documentation/Help

25.0 Help and Overview and Technical Documentation Scalability

26.0 Scale up Scale out and Architecture

Table1. Categories of Information Reported for Each Platform and Application

5. Digital Repository Platforms for LORs

5.1. DSpace

Primary website:

5.1.1. Background

Originally released in 2002, DSpace is arguably one of the best-known and widely implemented open source software packages used to create institutional and other digital repositories at educational institutions worldwide. Its use as a platform for learning object repositories, however, is significantly less common. Begun in 2000 as part of a joint project between the Massachusetts Institute of Technology (MIT) and Hewlett Packard (HP), DSpace was originally designed to function as a digital archive capable of handling the 10,000 articles produced annually at MIT. In 2003, eight research institutions volunteered for a one-year study to determine the feasibility of using DSpace at a broader range of organizations with varied needs, leading to the initial development of a community of DSpace users and collaborative developers. The year 2007 saw the launch of the DSpace Foundation, a non-profit organization to created provide support to the growing community of institutions that use DSpace and responsible for further development of the software. Since its inception, the major funding for DSpace has come from the MIT libraries and HP Labs.

DSpace continues to develop thanks to its large user base and has consistently released small updates annually since its original release. During this study, DSpace 1.5.2 was released that provided many smaller fixes and updates for translation and authentication as well as a new module to support SWORD 1.3 (a web service to provide cross-repository deposit of content). Additionally, development has already begun on the first major DSpace release since 2002. Known as DSpace 2.0, the development plan for this version calls for significant changes to the platform’s underlying framework focusing on improvements in key areas such as modularity, scalability, and digital preservation. In July 2008, the DSpace

Foundation announced its plans to collaborate with another well-known provider of open source repository software, Fedora Commons. In May 2009, DSpace and Fedora Commons joined forces in a

new organization called DuraSpace

projects.

5.1.2. Overview of Functionality

DSpace is designed to function primarily as a digital repository (i.e., to collect, preserve, index, and distribute research materials and publications in digital format) but with minimal modifications may also serve as a LOR. The basic content unit of a DSpace repository consists of bundles of bitstreams (files) and metadata (descriptive, administrative, and structural) about the bitstreams, with each bundle focusing on one aspect of the content unit (e.g., thumbnails from images, bitstreams, licensing information,

(13)

extracted text bitstreams for indexing, etc.). These basic content units are organized by content into collections, belonging to communities and/or sub-communities of users that typically reflect the organizational structure of the host institution, university, research center, etc.

The repository software itself is organized conceptually and logically into three basic layers, each consisting of a number of components that control all of the functions in the repository. On top is the application layer, which contains the components for importing and exporting as well as all other modes of external communication. The next layer, the business logic layer, contains the bulk of the system’s various components including content management, authorization and permissions, history recorders, administrative toolkits, storage plug-in, search engine, and workflow. The final layer is storage that contains the relational database, file system, and storage resource broker. Each layer only works with the layer directly below it, meaning that the application layer cannot directly bypass the business logic layer to access the storage layer.

In DSpace, most repository content is submitted in one of two ways: 1) via a web submission user interface (UI) or 2) through a batch ingest application. The web submission UI guides registered users through file upload, metadata creation, and selection of license agreement for each individual content item. Alternatively, the batch ingest application allows users to process content packages such as an external Submission Information Package (XML metadata document with associated content files) into the repository as well. DSpace defines as Simple Archive Format that contains the object, the metadata, and other information to use in the batch ingest mode. The use of either ingest method invokes the business logic layer to create an "in progress submission" object.

The DSpace repository's business logic layer is responsible for publishing, indexing, and maintaining the content of the repository as well as facilitating most administrative tasks. When an "in progress

submission" object is created, the repository assigns to the object's metadata the file names, provenance messages, and checksums necessary to document the object's audit history and provide evidence of data integrity. The object then proceeds through a simple three-step workflow process (optional and specified at a DSpace collection level) that allows the editors (registered users with editorial permissions) to verify that the content and metadata are valid and meet collection submission guidelines. The item installer assigns metadata for accession date, issue date, persistent identifier and a provenance message that includes the filename and checksums for the object. In addition, the item installer adds the item to the target collection, issues authorization policies, and adds the new item to the search and browse indices. If no workflow is specified for the collection, the content skips the workflow and proceeds directly through this same publishing process.

All metadata and text in DSpace repositories are indexed and fully searchable. DSpace currently comes with Dublin Core (DC) as the default metadata scheme as well as plug-ins for many crosswalks that can be used to convert other schemas to DC for ingest or back to another format for export. The current version supports a metadata registry that allows the declaration and definition of metadata elements from any metadata scheme. DSpace's Search API – powered by the freeware search engine Lucene – allows administrators to customize search and browse indices. DSpace also supports the Open Archive

Initiative’s Protocol for Metadata Harvesting (OAI-PMH) for harvesting and exporting of metadata. 5.1.3. Technical Specifications

DSpace 1.5.1 requires the following:

• Operating System: Unix-like OS (Linux, UP/UX, Solaris) or Microsoft Windows • Database: PostgreSQL or Oracle

• Web Server: Apache

• Applications Server: Apache Tomcat 4.x, Jetty, or Caucho Resin • Programming Language: Java, Perl

(14)

5.2. EPrints

Primary website:

5.2.1. Background

Originally released in 2000, EPrints is perhaps the first open source software designed specifically to create institutional repositories and was an early adopter of OAI-PMH. The original development of the software began in 1997 as part of the development of the Cogprints archive at the University of Southampton and has since become one of the most commonly implemented repository platforms worldwide. While much of EPrints' development has been funded through various JISC programs, 2004 through 2007 saw the establishment of the EPrints Services, a fee-based commercial operation that provides services such as hosting, training, and consultancy to EPrints users. Although this commercial service now provides the funding for further development, the software itself remains open source. While the EPrints development community itself exists primarily "in-house" at the University of

Southampton, current development is driven primarily by the needs of the wider institutional repository, open access, and preservation communities through the team’s engagement with a wide range of repository application projects. The most recent version of the software (EPrints 3.0) was released in January of 2007, with smaller update released 12 months later (EPrints 3.1). The next software release, EPrints 3.2, was scheduled to debut at the Open Repositories Conference in May 2009. Current

development focuses on increased support for use with other storage platforms (including both institutional and cloud-based storage), support for the SWORD 2 specification, support of the Open Archives Initiative Object Reuse and Exchange (OAI-ORE) import and export specifications, as well as additional workflow, edit lock, and branding capabilities.

5.2.2. Overview of Functionality

As mentioned previously, EPrints was designed to function as a digital institutional repository, but with minimal modifications may also serve as a LOR. The basic content unit of an EPrints repository is a data object, a member of a data set that has an extensible metadata schema. Each object consists of the files and metadata that make up the ’publication’, together with a number of document objects that contain the administrative data (e.g., metadata and file storage) for each digital object deposited in the repository. EPrints organizes these data objects by type in various database tables for efficient access and searching. Other data include users, history events, subject trees, and in v3.2 will include projects, institutions, conferences, and related information required for accurate research information management.

Similar to many repositories, EPrints provides registered users with a personal work area with web interfaces to facilitate the upload of content and creation of metadata. This interface walks the user through the process of uploading or importing files (primarily XML-based packages) from other sources. The platform also supports a customizable workflow process that includes selecting the document type, uploading files or pointing to an external file, specifying details (e.g., format, description, visibility, license, embargo), and entry of metadata. To facilitate the creation of new content, EPrints also provides

customizable auto-complete features and authority files to assist the user in providing metadata about the resource and prevents duplication of resources. Once complete, the object goes through a publishing workflow (customizable by content type and user), allowing editors or administrators to provide quality control before finally depositing the object in the repository.

In EPrints, administrative tasks are accomplished through a combination of an administrative interface within a user's (with administrative permissions) personal work area as well as manual manipulation of code and/or the database itself. The administrative interface provides a number of system reports and editors for modifying the text used on the deposit templates, managing select metadata fields, and modifying the subject classification tree. The administrator may view and edit many of the configuration files (most of which are XML-based), with the exception of those for workflow, metadata, and user administration. Any changes to these areas require hand-coding the configuration files as well as making

(15)

modifications to the database itself. Additionally, any bulk publishing of content to the repository can be achieved through the import infrastructure.

As mentioned previously, metadata makes up a significant portion of every data object in an EPrints repository. EPrints system metadata is responsible for controlling how a field is displayed, indexed, searched, etc. This enables many of the auto complete mechanisms provided during content creation. Additionally, each data object contains preservation metadata that serves as an audit trail, documenting all changes made to records from time of deposit onwards. EPrints supports the export of the repository's content, metadata, and access logs in XML format through OAI-PMH and through plug-ins for Metadata Encoding and Transmission Standard (METS), Metadata Object Description Schema (MODS), and Dublin Core. Additional plug-ins for export may be designed but require a working knowledge of the Perl

programming language. Finally, any number of metadata fields can be added, deleted, or configured either by hand coding the metadata configuration files and database or through the administrative interface (for selected data only).

In EPrints, users may both browse and search for materials in the repository. By default, the repository can be browsed by year (subdivided by month) and by subject. However, it is possible to customize browsing by complex criteria (such as by university structure). Additionally, EPrints provides basic searches (by year, author, or title) and advanced searches (limit by full text, title, creators, abstract, keywords, subjects, etc.), both with options to sort search results. The results of any search can be saved and exported as an RSS feed or in a number of formats for use in other websites or citations supported by plug-in (e.g., BibTex, ASCII Citations, EndNote, OpenURL, etc.)

5.2.3. Technical Specifications. EPrints 3.1 requires the following:

• Operating System: Linux, Unix-like OS (such as OSX), Vista or XP • Database: MySQL

• Web Server: Apache

• Programming Language: Perl

5.3. Fedora Commons

Primary website:

5.3.1. Background

First released in 2003, the Fedora (Flexible Extensible Digital Object Repository Architecture) Repository is a flexible platform designed for a wide variety of uses that include digital asset management,

institutional repositories, scholarly publishing, and digital libraries. The basic concept for the Fedora Repository was first developed through a U.S. Defense Advanced Research Projects Agency and the National Science Foundation funded research project at Cornell University (1997) and subsequently redeveloped in 1999 as a digital library prototype at the University of Virginia. However, full scale development of Fedora as a joint project between the two universities did not begin until 2002. In 2007, the project received startup funding that allowed for the incorporation of Fedora Commons, a non-profit organization that oversees the development of the Fedora software. Major funding for Fedora

development comes from the Gordon and Betty Moore Foundation, Cornell University Information Science Program, University of Virginia Library, and the Andrew W. Mellon Foundation.

Fedora Commons has a strong development road map and its community is tightly organized by project, with each project focusing on core components and services requested by the Fedora Commons user community. Three major projects to note are Islandora (a Drupal module that integrates the content management system Drupal with the repository), Muradora (a web-front end for Fedora repositories), and EduPak (a lightweight version of the Fedora-based platform used by the National Science Digital Library). Additional areas of development focus on ease of use (e.g., new web APIs and model driven content

(16)

management), re-use and interoperability (e.g., increased support of standards and protocols such as OAI-ORE), data curation and data archives, access and publication, and semantic technology (e.g., object-triple mapping and query technology, and Resource Description Framework (RDF)). As mentioned in the entry for DSpace, Fedora Commons and DSpace are now organizationally located within the recently established DuraSpace.

5.3.2. Overview of Functionality

Unlike many dedicated repository software platforms, Fedora is designed to function as a flexible back-end component that can be integrated into almost any larger system. Although capable of doing so, Fedora rarely functions as a stand-alone content server. Most Fedora implementations require additional software components to handle authoring and ingest, searching, workflow management, permissions and other security features in order to meet local repository needs. Additionally, Fedora's use as a back-end component implies that most end users will never interact directly with the repository without a third-party intermediary such as a content management system.

The repository software itself is organized into four layers: the client layer, the Fedora API layer, the service layer, and the storage layer. The client layer consists of a series of interfaces that allow the administrator/user to discover and access all disseminations of a specific object. These interfaces interact with the next layer, the Fedora APIs, which provides the actual operations/methods for accessing content. The third layer, services, consists of the additional web-accessible programs (often third-party) that provide access to the digital objects as well as produce dynamic disseminations of the digital content. The final layer, storage, is the relational database where all content is stored. The process of creating and disseminating the repository content involves each of these layers.

Through the use of a compound digital object, Fedora is able to combine one or more items into the same digital object. In this case, each digital object consists of a unique and persistent digital object identifier; a set of system-defined, XML-based, descriptive properties for object tracking and management purposes; and datastreams that represent the content itself. Each object can have one or more datastreams that record the object itself (if housed in the repository) along with useful attributes such as its audit trail, metadata, relationships and location (if it is stored outside the repository). Content versioning is optional and relies upon an audit trail that tracks changes to the object, rather than storing new versions.

In Fedora, new content is created via the administration interface. This interface walks the user through the process of creating the initial content container (the label and persistent identifier), defining

datastreams, and creating/editing metadata about the content. From this point, users may choose to upload additional versions of the object in different formats (e.g., html, pdf, txt). As an alternative to this, the Fedora software makes it possible to have a digital object with one datastream and then associate additional web services to it that are capable of transforming the source format into multiple output formats on demand. Since there is no workflow included in the software itself (i.e., it requires additional software), all steps beyond the creation of the initial container are optional and the object can be published directly to the repository without editorial supervision.

The Fedora software is very flexible in its support of different XML-based metadata schemas and allows each object to contain multiple metadata datastreams. At ingest, the repository software automatically encodes the object's persistent identifier and label in Fedora's native metadata schema, FOXML. The repository then uses this information to create a basic Dublin Core metadata stream for the object. Additionally, the Fedora software can support almost any other XML-based metadata, regardless of schema. Users simply create metadata in an external XML editor and import it via the administration interface to create an additional datastream. Alternatively, Fedora also makes it possible to use a single base metadata format as the basis for metadata crosswalks. When associated with an Extensible Stylesheet Language Transformations (XSLT) engine (used to transform XML documents into other XML or human-readable documents), this allows the system to derive metadata in additional formats as necessary. All metadata is available for harvest via Fedora's built-in support for the OAI-PMH harvesting and exporting of metadata.

(17)

As a back-end repository component, Fedora provides only basic indexing and searching capabilities that are built into the platform's service layer. GSearch, Fedora's generic search service, indexes an object's FOXML records as well as full text datastreams and allows for a basic search of the index. Additionally, this service provides plug-in support for several third-party search engines (currently Lucene, Solr, and Zebra). Perhaps easier for most users, Fedora also provides basic and advanced searching through a simple web interface known as Basic Search. This interface allows users to limit their search to specific fields and limit the maximum number of results returned.

5.3.3. Technical Specifications Fedora 3.1 requires the following:

• Operating System: Unix, Linux, OSX, or Windows • Database: MySQL, Oracle, or PostgreSQL

• Application Server: Tomcat 5.5.26 (included), can also be run on any application server that implements Servlet 2.4/JSP 2.0 or higher such as Jetty or Jboss

• Programming Language: Java

• Other Tools: Apache Any 1.7 or higher

6. Content Management Systems for LORS

6.1. Drupal

Primary website:

6.1.1. Background

Drupal is a content management system that allows users to publish, manage, and organize a wide variety of content for a website. Originally created in 1998 as an online message board for college students developing a local area network, the first Drupal installation attracted a lot of attention and received many requests for additional features based on emerging Internet technologies. In 2001, Drupal was released to the public with an open source license, allowing others to experiment and extend the code. From there, it developed as the interests and needs of its users dictated. In 2006, the Drupal Association was created to help manage the infrastructure, funding, and promotion of the Drupal project. As with many open source systems, the development community is at the heart of Drupal's success. The Drupal community relies on over 350,000 subscribed members that provide all coding, debugging, testing, and documentation for Drupal development. Current development on Drupal version 7 (release date not yet announced) includes support for RDF namespaces, additional support for PostgreSQL databases, additional API's to extend functionality, and additional streamlining of code.

6.1.2. Overview of Functionality

Although never designed to function as a digital repository, Drupal is a highly modular CMS used to create websites that can interoperate with a back-end repository such as Fedora. Although many

standard repository functions (such as preservation/version control, standardized metadata creation, and exposure for harvesting) are not available upon direct install, Drupal does provide feasible support for these functions via relatively simple – though extensive—customization. True to its CMS nature, Drupal also provides many highly usable web management interfaces that can be used to create and publish content, manage users, etc. Due to this, Drupal can function as part of a toolkit for creating a LOR that can be integrated within a larger web development project. For specifics on how to create a LOR out of

Drupal visit

The Drupal software itself is organized into five layers: templates, user permissions, blocks and menus, modules, and data. Templates make up the surface layer of a Drupal site and primarily consist of the XHTML, CSS, and PHP framework needed to generate dynamic web pages with the managed content

(18)

located in the correct places. Just under this is the layer for user permissions where the administrative interface is located. User permissions are the primary methodology used for control of content access. The third layer consists of configurable blocks and menus that direct the output from a module to specific locations within a template. The fourth layer consists of modules, a type of plug-in that expands the capabilities of a site by providing the framework and functionality for each type of content. The fifth and inner most layer consists of the content itself, known as nodes.

As its most basic unit, Drupal organizes all content as nodes, each with a unique, system-provided URL and basic metadata (includes author and title). Each node may also contain additional files (e.g., images, text, and multimedia) and taxonomic information, which is used for information organization purposes. In turn, each node belongs to a node content type that specifies the way in which its data are collected and displayed. Basic content types in Drupal include blog entries, book pages, forum topics, web pages, polls, and stories (e.g., new events and other pages of limited time duration). Additional content types can be added via the administration panel or through the installation of additional modules.

In Drupal, new content is created by using the Create Content section of the Administrative Interface. What users see in this section is dependent on their permissions. Although the specific workflow process and metadata required varies by the node's content type (each of which can be configured in many ways), node creation typically includes the upload files using a generic upload module and user input of appropriate information for title, author, etc. Additionally, users have the option to make their files publicly accessible by anyone or limit access to users with specific permissions. During the creation process, Drupal also assigns a unique and customizable URL and system metadata to each item.

Much of Drupal's functionality derives from its modules, most of which are optional to use, and are highly customizable. A very large number of modules for many different functions exist. Although this makes Drupal infinitely flexible for web development purposes, it makes it challenging to outline the software's basic functionality. The modules themselves handle content types (e.g., blog posts, files, etc.) and behaviors (e.g., email notification, aggregation, peer-to-peer publishing, etc.). Due to this, modules not only control standard features such as user access, user management, search and browse functions, and site statistics. They also can be used to expand a website's capabilities such as the creation of custom data fields, workflow, content translation, syndication, etc. Such features are added to a Drupal website simply by enabling existing modules or adding new ones from within the Administrative Interface.

As a content management system, Drupal is not obligated to conform to the same metadata standards as expected or required by most LORs. Therefore, Drupal's support for metadata is limited primarily to that needed for system administrative purposes. Standard metadata for an object consists of: type, title, publishing status, time node was created, time node was changed, comment, show node on the front page, stick node and place it on the top of a list, unique ID for node, and finally a unique revision ID. Additionally, Drupal supports the use of hierarchical content tagging – supporting both user-based

taxonomies(folksonomies) and administratively defined controlled vocabularies – via a taxonomy module. Metadata for specific schemas can be added using these taxonomies. However, support for OAI-PMH requires building a separate module to handle the OAI responses.

6.1.3. Technical Specifications Drupal 6 requires the following:

• Operating System: Unix, Linux, BSD, OSX, or Windows • Database: My SQL 4. 1 or higher, PostgreSQL 7.4 or higher

• Application Server:Any (Apache 1.3, 2.x, and Microsoft IISare recommended) • Programming Language: PHP 5.2 or higher

6.2. Plone

(19)

6.2.1. Background

Originally developed in 2000 as a simple usability layer to work with the Zope Content Management Framework (CMF), Plone is a CMS that has become popular among web consultants as a platform for the custom development of websites, intranets, document repositories, and other specialized web-based systems. There are currently over 300 such consulting firms world-wide, many of which also help fund Plone development through the Plone Foundation (the legal and promotional side of Plone) in addition to participating in Plone's development community.

Plone has a highly active development community that produces many update releases and add-on products annually. The most current, stable version of Plone, version 3.2, was released in February 2009 and focuses on improvements to designed to make future installations easier for users. This release was quickly followed by a beta release of Plone 3.3 the following month and other experimental releases are currently in development.

6.2.2. Overview of Functionality

Plone is a CMS that allows users to manage and publish selected content items to the internet via an easily customizable/extensible interface. Additionally, Plone provides services (e.g., authentication, search, and topology management) commonly needed in most business applications. Unlike Drupal, which typically functions as a front-end web interface for a repository, the Plone software is often used as the base code for custom LOR platforms themselves (e.g., Rhaptos/Connexions and eduCommons). Due to contributions of code from such projects, Plone now actually shares many common repository features and functionality (e.g., preservation/version control, standardized metadata creation, etc.), both natively and through the installation of add-on products.

The organization of the Plone software itself reflects an expansion of the code from other preexisting open source software. Plone's topmost layer consists of a series of polished interfaces for content entry and validation. Just below this layer runs the older CMF, a Zope add-on product that provides many tools and services for workflow and a framework for customization. Finally, at the heart of the Plone software is the Zope web application software, with its built-in transactional object database (for storing content and custom data), dynamic HTML templates, scripts, a search engine, security architecture, and the ability to integrate with another database using Open Database Connectivity (an API for using database

management systems).

Plone's basic content unit is a compound object consisting of persistent identifiers, metadata, and/or related files (e.g., images, text, and multimedia). Each object belongs to a specific content type that designates not only the characteristics of an item, but also how it is used and what tasks it is capable of carrying out. Content types include standard pages, news items and events (objects of limited time duration), images and files, links and favorites (both internal and external to the system). Plone also has two special content types used for organization, folders (used to organize related object into a hierarchical structure) and collections (used to consolidate related objects from multiple folders). Additional content types can be created using Archetypes, Plone's framework for storing data attributes on content items.

To create new content, registered Plone users and groups are provided with private workspaces based upon the permissions assigned to them. New content (page, news item, etc.) is created via a drop down menu located in this workspace. This creates a blank unpublished object within the user's workspace, and sets up basic administrative metadata. The user must then create the content and metadata using a java-based instant edit feature or the edit display. The instant edit feature allows the user to simply click on the title, description, or main text of an object (such as the title of a page) and edit that element in the object's metadata (although it does not function for all elements). Alternatively, the user can select to use the edit display feature, an interface that provides tools such as WYSIWYG editors, forms, and drop down menus to assist in content creation, metadata input, and file upload. The exact information to be entered differs based on the object's content type and includes default descriptive metadata (e.g., title, description, etc.), administratively defined categorization (e.g., location and language), dates, ownership and rights (e.g., Creative Commons or reserved), and settings that affect content behavior (e.g., allow comments or exclude from navigation).

(20)

Similar to many repository platforms, the Plone CMS is responsible for publishing, storing, and maintaining the content it hosts. When the user submits the item for publication, the object proceeds through a customizable workflow process for administrative and editorial review. At this time, objects may be published to the repository or rejected and sent back to the creator. When published to the repository the object receives public status, allowing it to be viewed by users of all permissions. Throughout the workflow process, Plone's workflow history logs all state changes made by users and provides this information to users and administrators via the State Menu. Plone also provides edit locking (preventing the alteration of items currently in use) and content versioning (allowing every version of an object to remain accessible).

Although many content management systems provide little support for metadata outside of what is needed for administrative tasks, Plone supports both descriptive and preservation metadata as well. For descriptive metadata, Plone provides editable schema to control and standardize all metadata entered into the system. By default, Plone uses Dublin Core for all descriptive metadata; however, this can be modified (either by manual modifications or through the installation of plug-ins) to support additional metadata schemas. Plone also supports the use and validation of administratively defined controlled vocabularies for content. For preservation purposes, Plone also maintains revision metadata for each object including version number, person responsible for revision, date and time revised, comments, and actions taken.

Plone provides several search and discovery features including both basic and advanced search

functions, as well as a Live Search feature. The basic search function is available via a search box at the top of every page and provides results ranked by relevancy. The advanced search feature allows users to limit by folder and date. Both search types support keyword, Boolean, and full text search of metadata fields. Plone's Live Search is a java-based search tool that uses the basic search function but the results of the search are shown as you type without navigating away from the original screen. Plone allows all searches, as well as folder and collection updates, to be published as RSS feeds. Plone does not support OAI-MPH metadata harvesting at this time (and add-on product is currently still in an experimental phase).

6.2.3. Technical Specifications Plone 3.2 requires the following:

• Operating System: Windows, Mac OS X, Linux, or Solaris • Database: Zope Object Database (built in)

• Application Server: Zope 2.10.x

• Programming Language: Python 2.4 or 2.5

7. Hybrid Platforms

7.1. eduCommons

Primary website:

7.1.1. Background

Developed in 2004 by the Center for Open and Sustainable Learning (COSL) at Utah State University, eduCommmons is open source content management software specifically designed to facilitate the creation and maintenance of OpenCourseWare projects (open access collections of educational materials used in formal courses). eduCommons builds upon preexisting open source code developed for other purposes – namely, Plone (a content management system) and its open source predecessor, Zope (an application server used to build content management systems). Although relying on the framework provided by Plone, eduCommons has been developed as a stand-alone repository platform that provides

(21)

additional workflow processes designed to guide users through the process of publishing digital learning materials in an openly accessible format. Since 2003, the William and Flora Hewlett Foundation has provided the primary funding for the development of eduCommons.

Currently in use by over fifty institutions worldwide, the eduCommons platform has seen wide implementation in part due to the large Plone-based development community. This development community is now the focus for future development planning as eduCommons transitions from being a funded project with a small pool of dedicated developers to a community-supported project. Future development plans focus on the creation of a new eduCommons portal for development support and technical information, installers to make setup and implementation easier, and other additional features to extend usability. Two new releases of the eduCommons software were currently scheduled for May and June of 2009.

7.1.2. Overview of Functionality

The eduCommons software is an adaptation of the Plone CMS designed to facilitate the creation and maintenance of OpenCourseWare projects. Although it shares many of Plone's basic technical features, functions, and underlying structure, eduCommons provides additional support for importing preexisting materials from course management systems, accessibility, and standardized metadata.

eduCommon's basic content unit is a compound object structured much like those in Plone, consisting of persistent identifiers, metadata and associated files. Unlike Plone however, eduCommons makes use of only a single content type, a course. Thus, course refers to both the actual content (e.g., files, folders, images, html and plaintext pages, etc.) and a container of contents. Each course is organized according to the department or other institutional division that it belongs to

eduCommons provides two main methods of creating content: through the direct import of existing IMS content packages, or the creation of a course within eduCommons. IMS is a set of standards to provide interoperability of learning content so that systems are able to access, read, and upload content without

data loss or errors. S

methods use the Course Builder widget, accessible from the user's private workspace. For direct import of IMS packages, the Course Builder assists registered users in assigning the IMS package to a division (LOR object), assigning basic metadata and or templates, and uploading the package itself.

eduCommons fully supports IMS content packaging specification versions 1.2 and 1.1.4 as well as the specific export packages created by MIT OCW, WebCT CE 6.0, and Blackboard 6.1/7.0. Alternatively, the Course Builder assists registered users in the generation of course pages though a series of forms. As in Plone, the user essentially creates a blank, unpublished object, containing only minimal administrative metadata. The user may also select to use standardized templates for commonly used pages such as course syllabus, course schedule, and faculty biography. The Course Builder then guides the user in assigning the object to a division, adding content, uploading files, and creating metadata.

In addition to the repository functions offered by Plone, eduCommons provides several tools and features to facilitate the publication and access to the content it hosts. Like many repository platforms,

eduCommons features a customizable multistage workflow process for administrative and editorial review. However, in eduCommons each object within a course must complete this process before the course as a whole can be published. eduCommons also supports the use of social bookmarking for content of any kind on sites such as del.icio.us, Digg, etc. Finally, eduCommons meets both Section 508 requirements and WAI-AA accessibility guidelines as well as provides built-in support for the multilingual translation of content via LinguaPlone.

eduCommons supports a variety of standardized metadata for courses, instructors, and divisions by default and through customization. By default, eduCommons metadata is an application profile of IEEE 1484.12.1-2002 Learning Object Metadata Standard (IEEE-LOM) and an application profile of ISO 15836 Dublin Core Metadata, both with extensions. Additionally, eduCommons can be modified (either by hand or through the installation of plug-ins) to support additional metadata schemas. By default, eduCommons also supports customizable rights management metadata (available as an add-on product for standard

(22)

Plone installations), to include several levels of Creative Commons Licensing. All metadata can be imported and exported using IMS content packages as well as exported via RSS feeds, typically using Dublin Core RDF binding.

7.1.3. Technical Specifications

eduCommons 3.1.1 requires the following: • Operating System: Linux or OSX

• Database: Zope Object Database (built in) • Application Server: Zope 2.10.5

• Content Management System (CMS): Plone 3.0.6 • Programming Language: Python 2.4.4

7.2. Rhaptos/Connexions

Primary website:

7.2.1. Background

Released to the public in 2005, Rhaptos is an open-source, web-based repository platform developed and used for the Connexions LOR at Rice University. Like eduCommons, Rhaptos also builds upon the Plone content management system. Although relying heavily on the framework provided by Plone, Rhaptos is currently being developed to function as a stand-alone repository platform that enables users to create, select, and assemble modular learning objects that can be reused and distributed. Since 2000, the development of both Rhaptos and Connexions has been funded in part through the William and Flora Hewlett Foundation, as well as the National Science Foundation and Rice University.

Although Connexions (a customized Rhaptos installation at Rice University) is alive and thriving, the Rhaptos platform itself does not appear to be widely implemented elsewhere. This is anticipated to change with the development of new installation scripts designed to automate the installation process, thus making it easier for developers to implement. Additional near-term development plans for the Rhaptos platform include the removal of Connexions customizations to create a more generic install for the repository platform, as well as a reduced reliance on a CVS Repository in favor of a PostgreSQL database.

7.2.2. Overview of Functionality

Created to facilitate the creation and publication (both digitally and in print) of learning materials and scholarly works, Rhaptos is designed to handle modular learning content that can be combined and reused in many different ways. The basic content unit (a module) consists of an XML file (defining content in this format allows it to rendered in various viewing and publishing formats), associated resource files (such as images, audio, applets, etc.), and links (pointing to resources both internal and external to the system). These modules can be combined into collections that can function as courses, books, theses, journals, etc.

To supply this content, Rhaptos provides persistent, private work areas (both for individuals and for groups) in which to create, edit, and publish modules and collections. New modules may be created in two ways: 1) in the workspace or 2) elsewhere and uploaded into the workspace. For the first method, Rhaptos provides JavaScript-based tools to provide graphical assistance in the creation and editing of the CNXML – Rhaptos' home-grown XML language that includes MathXML, BibTeXML, and QML – as well as an interface for the addition of supporting files (e.g., image, audio, etc.). For the second method, Rhaptos provides a number of options including the import of CNXML files generated in a client-side XML editor, a zip importer for bulk import of resource files, and an importer that converts OpenOffice.org and MS Word documents into CNXML. For the creation of collections, Rhaptos also provides a file system-like interface that allows users to build and organize resources into collections from the workspace, but does

Figure

Figure 1. Digital Repository LOR Implementation
Table 1 lists the first and second level categories of information compiled for the supplementary  document

References

Related documents

Experiments were designed with different ecological conditions like prey density, volume of water, container shape, presence of vegetation, predator density and time of

This essay asserts that to effectively degrade and ultimately destroy the Islamic State of Iraq and Syria (ISIS), and to topple the Bashar al-Assad’s regime, the international

It concludes that the current approach of addressing gully erosion in South Eastern States is driven by the federal government down to the states, while the local government

[25], simulate the ascent of 8 men to Everest with an hypobaric chamber (COMEX). On the other hand Takahashi et al. showed that elite climbers are characterized by their enhanced

Finally, HRM issues, even when strategic, are considered by top management to strategy implementation phase and not strategy formulation phase (Russ et al. , 1998) study

[r]

As a result, 19 taxa belonging to the genera Cymbella, Cymbopleura, Encyonema, Encyonopsis and Reimeria were found in the study area and Cymbella excisa ,

The objective of this study was to develop Fourier transform infrared (FTIR) spectroscopy in combination with multivariate calibration of partial least square (PLS) and