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

Transcription

1 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 December 2009 Texas Center for Digital Knowledge College of Information 1155 Union Circle Denton, Texas Phone: Fax: Web: Texas Center for Digital Knowledge is an official research center of the University of North Texas

2 Table of Contents 1. Project Overview Background and Purpose of the Study Project Methodology, Assumptions, Limitations Open Source Software Overview Freely Available Source Code Community-based Development Repository Overview Terminology Functions and Components Implementation Styles Organization of Report Digital Repository Platforms for LORs DSpace Background Overview of Functionality Technical Specifications EPrints Background Overview of Functionality Technical Specifications Fedora Commons Background Overview of Functionality Technical Specifications Content Management Systems for LORS Drupal Background Overview of Functionality Technical Specifications Plone Background Overview of Functionality Technical Specifications Hybrid Platforms educommons Background Overview of Functionality Technical Specifications Rhaptos/Connexions Background Overview of Functionality Technical Specifications Summary of Findings from Implementors Using OSS Platforms and Applications Factors Influencing Choice of OSS Common Advantages Specific to OSS Common Challenges Resources Needed Factors Influencing Choice of Software Platform Specific Findings from LOR Implementors Digital Repository Platforms DSpace Factors Influencing Choice of OSS Factors Influencing Choice of DSpace Texas Center for Digital Knowledge December 2009

3 Necessary Resources Advantages/Challenges/Precautions Specific to DSpace EPrints Factors Influencing Choice of OSS Factors Influencing Choice of EPrints Necessary Resources Advantages/Challenges/Precautions Specific to EPrints Platform Specific Findings from Implementors Content Management Systems Drupal Factors Influencing Choice of OSS Factors Influencing Choice of Drupal Necessary Resources Advantages/Challenges/Precautions Specific to Drupal Platform Specific Findings from Implementors Hybrid Platforms educommons Factors Influencing Choice of OSS Factors Influencing Choice of educommons Necessary Resources Advantages/Challenges/Precautions Specific to educommons Emerging Trends and Future Directions in OSS and LORs Summary and Conclusions References Appendix A: Technical Report Template to Record Specific Details Appendix B: Questions Guiding the Semi-Structured Interviews with Implementers Texas Center for Digital Knowledge December 2009

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 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 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. Texas Center for Digital Knowledge 1 December 2009

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) Texas Center for Digital Knowledge 2 December 2009

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 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, Additional information on 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. Texas Center for Digital Knowledge 3 December 2009

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 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 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. Texas Center for Digital Knowledge 4 December 2009

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 the installation 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, , 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 datamanagement 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 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 Texas Center for Digital Knowledge 5 December 2009

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 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 frontend 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 Texas Center for Digital Knowledge 6 December 2009

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 Figure 2. Content Management System LOR Implementation Texas Center for Digital Knowledge 7 December 2009

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 Texas Center for Digital Knowledge 8 December 2009

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: 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 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 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 which is now the organizational home for both projects 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, Texas Center for Digital Knowledge 2 December 2009

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 Technical Specifications DSpace 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 Other Tools: Apache Maven or later, Apache Ant or later Texas Center for Digital Knowledge 9 December 2009

14 5.2. EPrints Primary website: 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 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 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 Texas Center for Digital Knowledge 10 December 2009

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.) 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: 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 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 Texas Center for Digital Knowledge 11 December 2009

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 Overview of Functionality Unlike many dedicated repository software platforms, Fedora is designed to function as a flexible backend 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. Texas Center for Digital Knowledge 12 December 2009

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 Technical Specifications Fedora 3.1 requires the following: Operating System: Unix, Linux, OSX, or Windows Database: MySQL, Oracle, or PostgreSQL Application Server: Tomcat (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: 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 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 Texas Center for Digital Knowledge 13 December 2009

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., 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 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 IIS are recommended) Programming Language: PHP 5.2 or higher 6.2. Plone Primary website: Texas Center for Digital Knowledge 14 December 2009

19 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 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 javabased 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). Texas Center for Digital Knowledge 15 December 2009

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) 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 Hybrid Platforms 7.1. educommons Primary website: 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 Texas Center for Digital Knowledge 16 December 2009