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 <[email protected]> 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

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 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. See for a list of IMS specifications. Both 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 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 Learning Object Metadata Standard (IEEE-LOM) and an application profile of ISO 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 Texas Center for Digital Knowledge 17 December 2009

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 Technical Specifications educommons requires the following: Operating System: Linux or OSX Database: Zope Object Database (built in) Application Server: Zope Content Management System (CMS): Plone Programming Language: Python Rhaptos/Connexions Primary website: 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 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 Texas Center for Digital Knowledge 18 December 2009

23 not provide import facilities for collections at this time. Once created, modules and collections are published to the repository. The Rhaptos repository is responsible for storing/managing content and accomplishes this task in a number of ways. When published to the repository, all new content receives a unique identifier and an initial version number. At this time the repository also automatically populates metadata fields for the object id, version, submitter, and a log for any changes made to the document. In a Rhaptos repository, no object is ever deleted (except under special circumstances which require administrative removal of content) and every version of a module or collection complete with all of its contents remains accessible from a URI within the repository. Since it stores the complete history of all published content, the Rhaptos repository is also responsible for all version control within the system. As any user may checkout and alter a content item, the repository includes safeguards to prevent multiple and out of sequence publication of new versions as well as restrictions on the publication of new versions based on user permissions. A final function of the repository is the provision of a common metadata search for content (for both modules and collections) and full text searching (modules only). In Rhaptos, metadata is created/edited in two ways, automatic population upon publishing (mentioned previously) and by the user manually filling out the metadata fields in a UI in the workspace. Rhaptos currently supports Dublin Core, IEEE Learning Object Metadata, and MDML (a local metadata schema designed for Rhaptos). In addition to being searchable from within the system, this metadata is available for export via two interfaces the OAI-PMH and with OpenSearch (both HTML and RDF outputs). By supporting these two protocols, external aggregators can harvest metadata and external search engines (e.g., Google) can search the repository Technical Specifications Rhaptos 2.0 requires the following: Operating System: Linux (Debian or Ubuntu) Database: PostgresSQL 8.2 and/or CVS Repository (to be phased out in future development) Application Server: Zope Content Management system (CMS): Plone 2.5 Programming Language: Python 8. Summary of Findings from Implementors Using OSS Platforms and Applications This and the following section report the findings from interviews with implementors who are currently using an OSS application or platform for a LOR implementation. Interviewing implementors provided both information and insights about OSS in general, specific platforms and applications, and other factors affecting the implementation of a LOR. One challenge we faced was locating implementors of the specific OSS applications/platform reviewed in this study, where the implementation was primarily a LOR. For most of the OSS platforms and applications, especially the digital repository type, there are hundreds if not thousands of implementors, but very few LOR implementations. For example, there are more than 700 implementations of DSpace listed ( but finding LOR specific implementations was very difficult. The following are the specific implementations about which we carried out telephone/skype interviews with one or more staff involved in the implementations. Joining Educational Mathematics [Drupal]: Language Box [Eprints]: Open Michigan Educational Resources [educommons]: Penn State s College of Earth and Mineral Sciences' Open Educational Resources initiative [Drupal]: Texas Center for Digital Knowledge 19 December 2009

24 Notre Dame OpenCourseWare [educommons]: Web-Based Information Science Education (Wiseplus) [DSpace]: We developed a standard set of questions that guided the interviews. Appendix B contains the list of questions that guided the semi-structured interviews. Most interviews lasted between minutes and were recorded (with the permission of the interviewees). Project team members reviewed and analyzed notes taken by the team members during the interviews and the recorded interviews. The analysis identified key themes and issues, some of which were common across the implementations, but many were often specific to an individual implementation. In the following subsections, we first summarize across the interviews on several key issues such general factors for choosing OSS, advantages, challenges, and resources needed related to OSS solutions. We then provide information about each implementer s specific platform and application based on the comments provided by the implementer Factors Influencing Choice of OSS Although many factors were discussed during the interviews with LOR implementors, funding emerged as a significant factor all had in common (in one respect or another). For some, the use of OSS was mandated by their grant providers, particularly (but not limited to) those receiving government funding. Additionally, the use of OSS often meant the reallocation of funds from software licensing fees to other important areas of LOR implementation. Moreover, the cost of software was an important concern for those working on exploratory projects or in need of a quick, low cost way to get started. OSS, since it is free to use, offered a good alternative to proprietary software in these cases. Another factor in the selection of OSS appears to be personal or organizational preference. Although several LOR implementers chose to outsource the hosting of their projects to avoid conflicts with OSSwary IT departments, several more expressed pride that their organization had embraced the challenge and have come to prefer the flexibility and community support inherent in OSS Common Advantages Specific to OSS The lack of an annual license or maintenance fee is often cited as one of the greatest advantages to using an OSS. However, many LOR implementors also felt that the OSS development communities and the accessibility of code were equally important advantages. Since the use of OSS typically means no vendor to contact when problems arise, many of the LOR implementors appreciated the availability of support from the development community and the wealth of documentation they typically produce (and frequently update). Access to the code, along with adequate documentation, can enable LOR implementors with programming skills to diagnose and troubleshoot problems more easily on their own. Access to a development community s discussion lists was frequently deemed valuable, enabling developers to find solutions to specific problems. Additionally, several LOR implementors chose to use OSS specifically because access to the code enabled them to create highly customized systems to meet the specific needs of their LOR projects and end-users. Finally, one implementer commented that because OSS development is driven by the wants and needs of the user community, it is actually possible to get the features and functionality one wants created something proprietary software developers do not always find profitable or capable of doing in a timely fashion Common Challenges The challenges encountered in implementing a LOR were often very unique and dependent on the platforms. What one platform may not support (metadata), another one fully supported and contained many add-ons for further customization. Additionally, one factor that all seemed to have in common is the need for customization in order to have the OSS fit their needs. While most LOR platforms and Texas Center for Digital Knowledge 20 December 2009

25 applications are able to work out of the box, some are very basic and require further customizations and with these customizations there always the challenge of altering the code, adding new code, or simply configuring the software whether that was done by the implementors themselves or through a third party. Additionally, the setup for all OSS requires multiple programs (the technology stack to be installed and working even if they use a basic install). LOR developers choosing to outsource the platform and application development or hosting are not faced with this difficulty. Another challenge that all LOR implementors face is the design and management of content within the repository Resources Needed For LOR implementors, the resources essential to the successful development of an LOR often varied by their chosen method of implementation. Each of the following methods has unique aspects: Outsourced: For those electing to outsource the hosting of the LOR, few resources are needed aside from someone to manage the collection and call the service provider for maintenance issues. Here it is assumed that the service provider supplies, maintains, and updates all hardware and software used in the technical stack. In-house, generic: For those using a relatively generic install of the chosen software, the LOR implementors recommended having at least one full-time person with some programming experience (Linux, PHP, the programming language required by the software, etc.) and occasional technical backup from an experienced system or database administrator. For any form of in-house development, it is assumed that the organization responsible for creating the LOR also provides, maintains, and updates all hardware and software used in the technical stack. In-house, heavily customized: For any sort of heavy customization, the LOR implementors recommended hiring a system administrator, developers with prior experience implementing, reconfiguring, and/or recoding OSS, interface designer, etc Factors Influencing Choice of Software Perhaps one of the most interesting discoveries of our research was that many LOR implementors tend not to choose a specific application/platform based on a project s needs or a comparison of software features and functionality. Based on the interviews conducted, prior experience with either the software or its programming language appear to be the most common factors in software selection. Other important considerations for the implementors were the health and stability of the software s development/user community and the preference of the grant provider. 9. Platform Specific Findings from LOR Implementors Digital Repository Platforms This section presents the ideas and issues the implementers discussed during the interviews on their specific platforms and applications DSpace Factors Influencing Choice of OSS For the DSpace LOR implementation, the implementer described both personal preference and financial priorities as the two primary factors in the choice to use OSS. The developer expressed a personal preference for the OSS development process specifically, the speed of bug identification, the strong documentation, and the availability of assistance via the development community. Additionally, the LOR implementer preferred the flexibility that OSS allowed for customization. Finally, the choice of OSS Texas Center for Digital Knowledge 21 December 2009

26 allowed the planning team to allocate as much of their grant funding as possible to the development of LOs rather than towards software licenses Factors Influencing Choice of DSpace Unlike most of the implementors interviewed, the DSpace LOR implementer was able to install and test several repository systems (both proprietary and OSS) before making the decision to use DSpace. By doing this, the implementer found that many of the OSS LOR options available work well but felt that DSpace, combined with Apache Tomcat (an application server), provided a more secure and stable development environment. Additionally, the developer felt that DSpace was easier to update than the other systems considered Necessary Resources The DSpace implementer described the importance of hiring someone familiar with digital library management, repository systems, or digital objects as being more essential than programming support to the development of a DSpace LOR. The implementer urged that this person should be familiar with formatting issues and format conversion issues. Otherwise, there are few resources needed beyond those for the technical stack Advantages/Challenges/Precautions Specific to DSpace The DSpace LOR implementer encountered many challenges during development phase and considers the project to be less than successful in many regards. However, the developer specified that the LOR s failure was not a result of the technology chosen but of the overall challenges of creating an LOR (e.g., motivating participants, collecting feedback, creating generic and modular objects, etc.). Additionally, the implementer experienced several challenges directly related to the use of DSpace as the development platform, the greatest of which was user frustration with workflow and unassisted metadata creation. The implementer also mentioned the software s lack of tools for creating LO s and difficulty handling certain object types as being secondary challenges. To address these issues, the implementer has chosen to migrate the LOR to a new platform (EPrints) for redevelopment EPrints Factors Influencing Choice of OSS Although several factors that influenced the choice to pursue an open source solution were discussed in the interview with an EPrints LOR implementer, the primary factor discussed was funding. The implementor described how government funded projects are highly encouraged to use OSS when developing their projects and any new software created for these projects should be made available as OSS as well. A second factor mentioned by the EPrints implementer was having the staff to customize and tailor an OSS to meet specific needs of the LOR Factors Influencing Choice of EPrints For the LOR implementer, the factors influencing the choice of EPrints as the development platform was simply based on familiarity with the software and its developers. In addition to having worked closely with the EPrints development team for many years, the LOR implementer had prior experience using the EPrints software on several projects, making him well aware of the strengths and weaknesses inherent to the software. Beyond his professional working relationship with the EPrints development team, the LOR implementer mentioned that EPrints also offered additional support via the EPrints Service Team Necessary Resources Aside from the resources needed for the technical stack, the LOR implementer explained that with the right support person a generic implementation of EPrints is fairly easy to setup and run in a short period of time. However, the implementer also mentioned that finding and/or recruiting the right person (e.g., Texas Center for Digital Knowledge 22 December 2009

27 someone experienced in Perl) can be challenging. Additionally, the implementer stated that the level of customization needed for his particular LOR required several fulltime personnel Advantages/Challenges/Precautions Specific to EPrints Many of the challenges encountered by the implementer related to metadata, both in the workflow and web interface. Perhaps the greatest of these were the users ability (or frustration) with creating the robust metadata needed to meet IEEE-LOM standards. The implementer found that many users experienced some level of information paralysis during the workflow process (e.g., when the decision making process becomes so hard, the users stop and do not complete the workflow). Additionally, the implementer found that the LOR users wanted an interface that revolved around the learning object itself (similar to Web 2.0 sites Flickr and YouTube), rather than being presented with the objects metadata. Addressing these issues required extensive customization to add in the Web 2.0 mechanisms requested by users and significant scaling back of the metadata required. A second series of challenges described by the implementer was created by the need to modify and customize the EPrints software to meet user requirements without continuously repeating the same work. Specifically, the EPrints LOR concept became popular enough that others wished to use the platform for other projects, thus requiring that the customizations to be replicated for each project. Additionally, there was no easy method to upgrade the EPrints platform without erasing many of the customizations specific to each LOR. At this time the LOR implementer has begun working directly with the EPrints development team to create new plug-ins (including tools for profiles, collections, and inline preview) that will enable others to create an EPrints LOR more easily with the inclusion of these customized features and functions. 10. Platform Specific Findings from Implementors Content Management Systems Drupal Factors Influencing Choice of OSS The factors influencing the choice to pursue an open source solution when developing their LORs were unique to each implementer. The implementors of one LOR described a strong grow it on your own ethos at their institution, especially in areas where funding is tight. This ethos combined with an administration accepting of OSS and an experienced local IT department for support, made the choice to consider OSS relatively painless. For another repository, the choice of OSS resulted from funding restrictions. Specifically, the grant provider mandated the use of OSS where possible and the decision to use OSS allowed for the allocation of funds for areas other than licensing and software fees Factors Influencing Choice of Drupal As with choice of OSS, the factors that influenced the choice of Drupal as the development platform for these two LORs were also distinctive. In one implementation, Drupal was already in use by their local IT department as well as other development communities within the same institution. Choosing to develop an LOR using Drupal allowed the developers to capitalize on the knowledge base and collective experience of local users. In a second implementation, the LOR implementors were primarily concerned with integrating the LOR with an existing web site/portal. The stability of the platform s development community and the availability of documentation were important secondary factors taken into consideration. Drupal provided the flexibility and the strong development/user community to meet their needs. Texas Center for Digital Knowledge 23 December 2009

28 Necessary Resources Beyond the resources necessary for the technical stack, implementors for both LORs spoke of the need for staff with previous programming experience specifically with PHP and Unix/Linux for daily support and as well as occasional technical assistance for database functions such as once a week maintenance functions (e.g., backups). Interestingly, one implementer also suggested that using Drupal for LOR development required staff with a willingness to try and fail. Perhaps due to this nothing ventured, nothing gained philosophy, it is unsurprising that this implementer has been instrumental in creating documentation and module modifications to assist others choosing to develop a Drupal LOR Advantages/Challenges/Precautions Specific to Drupal The Drupal implementors described several advantages and challenges associated with their choice of platform; the most commonly mentioned was Drupal s abundance of modules. The LOR implementors praised Drupal s use of modules to extent functionality as needed, often in a matter of hours (rather than the weeks or months required by traditional programming). However, the sheer number of modules can require a significant allocation of time simply to determine what functionality exists and/or to differentiate between modules offering similar functionality. Additionally, one implementer cautioned against attempting to please everyone by adding too many modules; such an attempt succeeds only in creating a system that is complex and ugly. A second significant challenge described by the LOR developers was how to overcome or compensate for Drupal s lack of out-of-the-box support for metadata. Due to the localized scope and intended audience for their LOs, one repository chose not to pursue additional support for metadata import and export, specific schemas, or harvesting. However, the implementors of this repository decided to submit metadata regarding their LOs to OER Commons for the purpose of sharing their resources with a broader community of users. In contrast, the implementor of the second repository chose to develop metadata support in XML for Drupal, as well as additional metadata import and export mechanisms. 11. Platform Specific Findings from Implementors Hybrid Platforms educommons Factors Influencing Choice of OSS For implementors using the educommons platform, factors that influenced the choice to pursue an OSS option primarily came down to funding. In one instance, an LOR implementer was encouraged to consider OSS by a grant provider highly interested in the development of open source solutions for open content programs. In a second implementation, the implementer routinely conducts pilot projects involving educational teaching technologies. Since this implementer often works with experimental projects, project failure may occur and costs associated with the creation of any project must take this into account Factors Influencing Choice of educommons For the implementors interviewed, factors that influenced their choice of educommons varied. For the first implementer, choice of platform was influenced by the preferences of their grant provider. Although the choice of educommons was not required, as an OSS funded by the same grant provider, its use was encouraged. For the second LOR, the implementors had prior experience with educommons, having used a test instance of the software prior to the start of LOR development. This second implementer refers to their choice of educommons as the path of least resistance. Finally, implementors from both projects also elected to outsource the hosting of their LORs (at least initially), rather than implement inhouse. Texas Center for Digital Knowledge 24 December 2009

29 Necessary Resources implementors from both LORs mentioned that outsourcing dramatically reduced the resources (IT staff, training, hardware, etc.) needed to support an LOR. With outsource hosting and the availability of the educommons user community, each development team found technical support to be necessary only occasionally (e.g., not daily or weekly). Recently, however, one of the LOR development teams transitioned to hosting their LOR in-house. According to the development team, in-house development of a LOR using the educommons platform requires technical staff system administrators and developers with prior experience in implementing, reconfiguring, and/or recoding OSS software, as all are necessary for a successful in-house customization Advantages/Challenges/Precautions Specific to educommons The educommons implementors interviewed described several challenges specific to the platform, perhaps the most important of which was the collapse of the educommons development community last year. For one LOR, the collapse of the educommons development community and the hosting services it provided necessitated locating and contracting with a second company to take over the site s hosting. For the second LOR, the collapse raised questions concerning the viability of the software platform itself. Both LOR development teams described the existence of a strong development/user community as essential to the life of any OSS project warning that if the community fails, there may not be anyone else to ask for help. A second important challenge described by one of the LOR development teams was educommons technology stack. Due to significant development changes between current and earlier versions of Plone and Zope (including a ground up-rewrite), educommons can only function with the earlier/outdated versions of the software (at least until the educommons software is updated to handle the upgrades in Plone and Zope). When creating an LOR in-house using the educommons platform, this requires recreating the aging/obsolete technology stack, which includes locating the specific Linux distribution as well as older libraries for both Linux and Python. Despite this, the LOR implementors claimed that the use of older OSS technology did have one significant advantage, namely that when there is a problem, the older technology tends to be well documented if one has the time to search for a solution. 12. Emerging Trends and Future Directions in OSS and LORs For potential implementors and users of LORs, there may need to be adjustments in thinking. These adjustments are based on a variety of issues ranging from broad questions regarding the definition of exactly what a learning object is and its worth to addressing the need to provide context (i.e., how a specific modular LO fits into the broader context of a lesson or course). Ultimately, the success of a LOR may depend less on whether it is based on OSS or proprietary software than on the extent to which the designers and implementors understand and respond to the needs and requirements of a LOR s potential users, and how those users can be informed of the potential benefits and advantages provided by a LOR. One of the questions asked during the interviews was on future development and trends for LORs. Combining responses to those questions along with other information and ideas provided by the implementors, and our own observations from this project, we present brief descriptions of a number of key areas related OSS and LORs. Change in the perception of OSS: Due to the success of a number of highly visible OSS applications such as Apache, MySQL, FirefoxFree, Drupal, Sakai and many others, organizations are rethinking their IT strategies to incorporate, where appropriate, enterprise systems that are based on OSS. Simply because the software is free does not mean it is junk or suspicious. More IT departments are becoming comfortable accepting the opportunities that come with OSS. Selection of OSS can be dictated by source of funding: This may be more true for European than U.S. government funding agencies and foundations which may specify that projects use OSS, or look fondly on proposals where the software developed with the funding is made Texas Center for Digital Knowledge 25 December 2009

30 available as OSS at the end of the project. This may potentially make the use of OSS more common for the management of LORs. Universities (and others organizations) will increasingly use OSS to meet their LOR needs: Several implementors indicated this sentiment because OSS can allow easier integration potential with other commonly used systems such as learning management systems and other enterprise systems. More importantly, OSS offers the potential for additional functionality that may be required but not available in proprietary systems, thus making it easier to adapt to changing requirements than proprietary systems. In fact, OSS may drive future development of LORs since the user requirements for LORs are still evolving and proprietary solutions may only be responding to user requirements as they are currently understood rather than being able to evolve with the changing user and content requirements. Educational institutions, especially colleges and universities, are very amenable to open source because the available of students and staff who have technical knowledge and skills needed. Trend towards modular development: The hallmark of many current web-based applications is modularity: separately developed components that can be plugged in as needed for a particular implementation. Further development, when based on a modular approach, yields more benefits and potentially broader use. Monolithic systems may not be the path of the future since modular development especially in a well-articulated development framework can enable focused work on specific features and functionality that can be then integrated into a larger application. Development time when using a modular approach may also be reduced. Drupal module development may be a model to aspire to. The marriage of CMS and repository software: Often the use of a CMS for a LOR provides out-of-the-box functions and features not specific to those typically in a LOR. In the case of Drupal and Plone, modules that provide community building through discussion boards, blogs, and other Web 2.0 features enhance the LOR without major custom programming. Embedding LORs in larger systems rather than building stand-along LORs will be a trend to watch. Success of LORs may depend on strategies to counteract existing attitudes: One of the concerns of LOR implementors is the reaction against or lack of interest in reusing learning objects. Educators may feel that they can do it better or may be more interested in finding commercial products, possibly due to distrust of unknown LO creators. While educators may accept the use of a textbook (created by a third party), they may not be as willing to use LOR content. Instructional designers or those running/managing a repository may be needed to act as liaisons and facilitate communication between knowledgeable people creating LO s and educators who might use them. A tendency to move away from the use of robust metadata: There are a variety of metadatarelated issues in LORs, including the utility value of metadata presented, and whether users want to see metadata prior to encountering the object itself. Additionally, there are open questions as to the metadata needed by the users and the managers of the LORs these are distinct user groups. However, implementors see the value of robust metadata and suggest it is needed. They also suggest that this needs to be balanced by the cost of creating the metadata. Changes in technologies, tools, and workflows may allow more cost-efficient metadata creation in the future. Ultimately the choice and extent of metadata requirements will be based on the needs of the users (end users and managers of LORS). Simultaneously, implementors recognize the power of metadata to make visible the LOR content (e.g., through harvesting, federation, etc.). In addition, metadata can provide support to enable disaggregation and re-aggregation of tools and content, personalization, and showing relationships among related resources. Use of LOR s in conjunction with mobile technology: One area to be explored is the delivery of LOR content through mobile technology. This may be particularly important if a LOR is Texas Center for Digital Knowledge 26 December 2009

31 intended to serve students and learners directly. Web 2.0 and 3.0 users are coming to expect access to content through a various modes and technologies. 13. Summary and Conclusions This review of OSS platforms and applications than can be used in the context of learning object repositories reveals an unsettled landscape of LOR implementations. The variety of OSS types and methods of implementation demonstrate a vibrant exploration of options for capturing, storing, and making accessible high quality learning materials. The focus of this review was on OSS alternatives for LORs, but in the process of conducting the reviews, especially through the interviews with implementors, many issues of developing, populating, and using LORs emerged. This review can only be seen as a snapshot in time (Spring and Summer 2009) of the LOR implementation landscape. OSS platforms and applications are organic creations, and they are rapidly evolving. For example, during the review period, several OSS platforms and applications released or were preparing to release new versions and/or significant updates. DSpace and Fedora Commons, two major repository platforms, were reorganized under a new umbrella organization called Duraspace. educommons, a significant application for the OpenCourseware initiative is transitioning from a funded project with a small pool of dedicated developers to a community-supported project. The Rhaptos application use in Connexions was being readied for release as a stand-alone OSS LOR solution. To say the landscape is fluid may be an understatement. The compilation of information for this review was based on publicly available information. Unlike the vendors of proprietary software that may have specific sales people who can provide the technical specifications, lists of features and functionalities, and other authoritative information, OSS platforms and applications typically have no such people and information is less centrally available. The documentation available often is directed more at developers than users of the platforms and applications. Yet, we think the compiled information (see the supplementary document, Technical Specifications Report) provides a basis for interested parties to start with. The detailed specifications that accompany this report for each of the reviewed platforms and applications are based on what we believe is a useful structure (see Appendix A) that can be used by others to refine and complete as they consider specific platforms and applications for their LOR implementations. Finally, as is so often the case, the technology aspect any system may be the most tractable to address. The implementer interviews, while intended to get a specific aspects of the technology, often led to discussions of policy, people, potentiality, and pitfalls regarding LORs. From those interviews, it is clear that OSS platforms and applications offer robust alternatives to proprietary offerings for LORs. Yet it was the insights and ideas of the implementors based on their experience of developing and implementing their individual LORs that suggest to the project team that additional research is likely needed at this stage of LOR development. Specifically, a series of in-depth case studies of existing LORs may be the next valuable undertaking. Texas Center for Digital Knowledge 27 December 2009

32 References Allinson, J. (2009, March 3). SWAP. Retrieved March 22, 2009 from the JISC digital repository wiki: Aspeli, M. (2005). Plone: A model of a mature open source project. Retrieved March 11, 2008 from: Aspeli, M. (2007, September). Professional Plone Development. Birmingham, UK: Packt Publishing Ltd. Barton, M. R., Waters, M. M. (2005). Creating an institutional repository: LEADIRS workbook. Retrieved January 26, 2009, from the DSpace website: Camara, G., Fonseca, F. (2007). Information policies and open source software in developing countries. Journal of the American Society for Information Science & Technology, 58(1), Retrieved August 24, 2009 from: Carr, L. (2008). EPrints 3.1. In: Third International Conference on Open Repositories 2008, 1-4 April 2008, Southampton, United Kingdom. Retrieved March 25, 2009, from the OR2008 Publications website: Caswell, T, Johnson, C.J. (2009, February 26). The social sourcing of educommons: Creating community around social source software. Retrieved March 31, 2009, from: Center for Open and Sustainable Learning. (2009, March 19). Center for Open and Sustainable Learning (COSL) website. Retrieved March 26, 2009, from: Charles, J. (1999, May). Middleware moves to the forefront. Technology News. Retrieved March 2, 2009 from the IEEE Explore website: Coar, K. (2006). The open source definition. Retrieved August 24, 2009 from: Colford, S. (December, 2008). Explaining free and open source software. Bulletin, December 2008/January Retrieved August 24, 2009 from the ASIS&T website: Connexions. (n.d.) About us: Project history. Retrieved March 10, 2009, from Connexions web site: Connexions Development Team. (n.d.). Rhaptos: Connexions' software and development site. Retrieved March 10, 2009, from: Connexions Development Team. (2004, December 8). Repository. Retrieved March 10, 2009, from Rhaptos: Connexions' software and development site: Connexions Development Team. (2007, March 12). Chuck s CNXBlog: Handling the translator role in IMS metadata and Dublin Core. Retrieved March 10, 2009, from Rhaptos: Connexions' software and development site: Texas Center for Digital Knowledge 28 December 2009

33 Connexions Development Team. (2007, October 18). Editing environment. Retrieved March 10, 2009, from Rhaptos: Connexions' software and development site: Connexions Development Team. (2008, October 22). Milestone performance improvement: Inception and discussion. Retrieved March 10, 2009, from Rhaptos Trac: Connexions Development Team. (2009, February 27). Rhaptos installation inception documentation: Issue list. Retrieved March 10, 2009, from Rhaptos Trac: Connexions Development Team. (2007). Technical plan December 2007 to December Retrieved January 26, 2009, from Rhaptos: Connexions software & documentation web site: Cooper, J. (2007, October 25). Rhaptos/Connexions architecture overview. Retrieved January 26, 2009, from Rhaptos: Connexions software & documentation web site: Davis. D. (2008, August 8). Fedora Commons versioning. Retrieved March 24, 2009 from the Fedora Commons wiki: Davis. D., Wilper, C. (2009, February 20). Fedora Commons installation and configuration guide. Retrieved March 24, 2009 from the Fedora Commons wiki: Drupal Association. (2009). Retrieved April 3, 2009 from: Drupal.org. (2009). Retrieved April 3, 2009 from: DSpace Foundation. (n.d.) DSpace: FAQ. Retrieved March 17, 2009 from the DSpace website: DSpace Foundation. (n.d.) DSpace.org. Retrieved March 17, 2009 from: DSpace Foundation. (n.d.). DSpace.org: Repositories. Retrieved March 22, 2009 from: DSpace Foundation. (2008). DSpace manual. Retrieved March 17, 2009 from: DSpace Foundation. (2008, July 29). DSpace press release: DSpace Foundation and Fedora Commons form working collaboration. Retrieved March 22, 2009 from: DSpace Foundation. (2008, November 11). DSpace press release: DSpace Foundation and Fedora Commons receive grant from the Mellon Foundation for Duraspace. Retrieved March 22, 2009 from: DSpace Foundation. (2009, February 16). DSpace 2.0. Retrieved March 22, 2009 from the DSpaceWiki: Easysoft (n.d.). ODBC, JDBC and XML Drivers, Bridges and Gateways Retrieved May 5, 2009 from Linux/UNIX ODBC: Texas Center for Digital Knowledge 29 December 2009

34 educommons Development Team. (2006, June 20). Draft: Metadata specification for educommons. Retrieved March 31, 2009, from the Center for Open and Sustainable Learning (COSL) website: Metadata-0.99e-1.doc educommons Development Team. (2007, June 11). educommons: A guide to getting started. Retrieved March 26, 2009, from the Center for Open and Sustainable Learning (COSL) website: educommons Development Team. (2009). educommons website. Retrieved March 31, 2009, from: EduTools. (2009). CMS: Feature Definitions. Retrieved April 16, 2009 from EPrints.org. (n.d.). EPrints Manual. Retrieved March 25, 2009, from the EPrints wiki: EPrints.org. (n.d.). EPrints website. Retrieved March 25, 2009, from: EPrints.org. (n.d.). EPrints Wiki. Retrieved March 25, 2009, from: Fedora Development Team. (2007, August 1). Introduction to Fedora object XML (FOXML). Retrieved March 24, 2009 from: Fedora Development Team. (2008, April 2). Fedora Commons Technology Roadmap V0.9 (draft). Retrieved March 24, 2009 from: Fedora Development Team. (2008, July 23). Fedora tutorial #1: Introduction to Fedora. Retrieved January 23, 2009 from: Fedora Development Team. (2008, July 23). Fedora tutorial #2 getting started: creating Fedora objects using the content model architecture. Retrieved January 23, 2009 from: Fedora Development Team. (2008, July 29). Fedora 3.0 release notes. Retrieved March 24, 2009 from: Gonzalez-Barahona, J. M. (2004). A brief history of open source software. Retrieved August 24, 2009 from: Hitchcock, S. (2007, November 22). Taking EPrints to the next level: Breakthrough new version software and reaching out to users with support services. Retrieved March 25, 2009, from: IMS (2009, April 28). Welcome to IMS. Retrieved May 6, 2009, from: JISC and EPrints.org. (2004, June 23) Putting EPrints software into the user community: Program and proceedings.. Retrieved April 3, 2009, from: Johnson, C. J. (2009, February 26). Social sourcing educommons. Retrieved March 31, 2009, from the OCW Consortium Wiki: Texas Center for Digital Knowledge 30 December 2009

35 Lewis, S. Yates, C. (2008, August 13). The DSpace Course. Retrieved March 17, 2009 from the Cadair Online Research Repository: Kimpton, M. (2008, April 8). Proposal for funding DSpace 2.0. Retrieved March 22, 2009 from the DSpaceWiki: Mercer, D. (2008). Building powerful and robust websites using Drupal 6. Birmingham, UK: Packt Publishing Ltd. Open Courseware Consortium (OCWC). (2009). About us. Retrieved April 16, 2009 from: Open Society Institute. (2004, August). A guide to institutional repository software. Retrieved January 26, 2009, from the EduForge website: Plone Foundation (n.d.) Plone.net. Retrieved March 24, 2008 from: Raymond, E. S. (1998) The Cathedral and the Bazaar. Retrieved August 24, 2009 from: (accessed 20/5/2003). Thierstein, J., Baraniuk, R. G. (2007, May). Connexions overview. Retrieved January 26, 2009 from Connexions web site: Tiemann, M. (2006). History of OSS. Retrieved August 24, 2009 from: Wyles, R. (2006, September 13) Technical Evaluation of selected Open Source Repository Solutions (v 1.3). Retrieved January 26, 2009, from the EduForge website: Texas Center for Digital Knowledge 31 December 2009

36 Appendix A: Technical Report Template to Record Specific Details This is the common reporting form used to record detailed information about each of the reviewed platforms and applications. Legend NS: Not supported S: Supported without customization M: Requires minimal customization E: Requires extensive customization U: Unknown X: Provide short answer in Notes/Additional Information column Discovery 1.0 Users' Options for Browsing the Repository 1.1 Browse categories drawn from metadata fields 1.2 Repository browseable by categories generated by system usage 1.3 Expand/collapse classification (e.g. broader terms) 1.4 Customize categories for browsing 1.5 Repository items assignable to multiple categories or subject classification 2.0 User Options for Searching the Repository 2.1 Relevancy ranking algorithms used to show search results 2.2 Sort search results 2.3 Users can customize their own display of search results 2.4 Simple search criteria created and modified by system administrators 2.5 Advanced search with scope and display preferences 2.6 Repository searchable by keyword anywhere in the metadata record or field 2.7 Users can select a specific metadata profile for an advanced search 2.8 Full text searching List file types indexed 2.9 Boolean operations in advanced search 2.10 Refine searches by limiting results Type Subject Author Date Collection Other 2.11 Refine using a drop down list 2.12 Search within previous search results 2.13 Provides links to objects directly from search results 2.14 Federated search of metadata from other repositories or portals 2.15 Users alerted when a specified object is added/updated 2.16 Alerts available RSS Personal message Other 2.17 Choice between new versions of content vs. previous versions List additional relevant functions for discovery Personalization 3.0 Users' Options for Personal Customization 3.1 Personal repository space Notes & Additional Information Texas Center for Digital Knowledge 32 December 2009

37 3.2 Quick links to favorite objects 3.3 Rename quick link items (similar to services such as del.icio.us) User applied tags can be added to object's tags appropriately 3.4 Users can update personal information 3.5 Users can set privacy options for fields in profiles If yes, list which fields List additional relevant functions Community and Evaluation 4.0 User Grouping, Evaluation and PURL's 4.1 Persistent/stable URLs 4.2 Limit access to URLs 4.3 Links of favorite objects and tags are shareable 4.4 Users can attach evaluations and annotations to learning object records Global Grouped User-specific 4.5 Creation of secure groups Members can contribute resources Members can retrieve resources List additional relevant functions Meta Tagging 5.0 Metadata Architecture 5.1 Identify all supported metadata schemas IEEE-LOM Dublin Core MARC MODS METS IMS Other 5.2 User defined metadata fields 5.3 Multiple metadata schemas applied By item 5.4 Crosswalks for Schemas Dublin Core MODS METS IMS Other 5.5 Each metadata schema is customizable If yes, describe any limitations on its extensibility 6.0 Exporting/Importing Metadata 6.1 Describe how the system identifies its resources to other repositories outside of itself 6.2 Export metadata to outside collections (e.g. OAI-PHM Harvest, XML Gateway) 6.3 Harvest metadata from outside collections (e.g. OAI-PHM Harvest, XML Gateway) 6.4 List the standards and functions that are supported 7.0 Metadata Vocabularies and Automatic Population 7.1 Controlled vocabularies importable and editable 7.2 Use different controlled vocabularies for different resources 7.3 Describe the process for adding and editing controlled vocabularies 7.4 System administrators can create and modify drop-down vocabulary lists 7.5 Describe the ability of the system to create drop-down lists, radio buttons, check Texas Center for Digital Knowledge 33 December 2009

38 boxes, etc. 7.6 System administrators set up preferences (e.g. mandatory metadata fields) 7.7 Automatic metadata population User field Role field Date field Other 7.8 Automatic population customized through templates 7.9 Self-guide or wizard interface for entering metadata Describe if and how these self-guides, templates, and preferences are customized Describe which roles have access to these customization tools. 8.0 Metadata Error Prevention 8.1 Required fields enforcement 8.2 File size limit enforcement 8.3 Automatic checks on metadata fields are customizable Control what messages are delivered to the contributor Control how messages are delivered Describe the types of customization and delivery possible 9.0 Users' Interaction and Workflow 9.1 Selectable metadata profiles to use when cataloging resources 9.2 Users can create personal template for entering metadata 9.3 Metadata entry available through a web browser 9.4 A workflow to define routing of metadata through multiple people or processes 9.5 Metadata-related workflows are created by system administrators List additional relevant functions Content Upload & Management 10.0 Content Upload 10.1 Upload an individual file or multiple files to the repository List user roles that can upload materials and file formats Describe the process users would follow to upload a single object 10.2 Existing metadata records imported into the repository Batch uploaded Describe the process 10.3 Existing content packages imported into the repository 10.4 Link to resources not stored in the repository for reference Assign metadata to those resources 10.5 Individual assets or content packages can be uploaded or imported in batch 10.6 During batch uploads, metadata is assigned to multiple assets with one command 10.7 Describe the process for uploading a batch of objects 11.0 Workflows 11.1 Authoring and publishing workflows 11.2 Workflows support an observer role 11.3 Describe which user roles in the system can create workflows and the permissions of these roles 11.4 Workflows can be defined by item type 11.5 Groups can create a workflow for all contributions from their group, regardless of the content type (e.g. if an asset is contributed to X group, it must go through Y workflow designated by the group) 11.6 Workflow processes can be branched according to metadata attributes (e.g. content related to Math goes to Group A; content related to Business goes to Group B. Within Group A, content related to Math - Physics goes to one workflow group; content related to Math - Algebra goes to another) Texas Center for Digital Knowledge 34 December 2009

39 11.7 Describe the capacity of the system to create multiple sub-workflows with a group workflow 11.8 Describe any other ways workflows may be defined 11.9 Route content through a workflow to a specific role Workflows can prevent publication of resources that have not met certain requirements During workflow, evaluators can check that functions work properly 12.0 Object Management 12.1 When resources are edited Versions are controlled Previous versions are kept 12.2 Recall a resource in use 12.3 The system support's XML content as XML 12.4 Tools to author new learning objects Describe the tools 12.5 Communication tools are available to support collaborative work (e.g. instant messaging) List the tools available 12.6 Integration with external authoring packages List supported integrations 12.7 Tools to help with lifecycle management of content (e.g. mechanisms to archive and content) Describe these tools 12.8 Tools to help detect duplicate assets in the repository 13.0 File Management 13.1 File conversion capabilities Converting one file format to another Generating and saving multiple derivative versions 13.2 File conversion done upon Ingest Request 13.3 Capabilities to deal with audio and video content directly Describe these capabilities Integrate with existing audio and video tool suites Describe supported audio and video tool suite integrations 13.5 Transcribe audio/video files List additional relevant functions Aggregation and De-aggregation 14.0 Multiple Elements Management 14.1 Manage objects made up of numerous elements Describe the types of packages can it manage 14.2 Users can create new aggregate objects made up of multiple existing resources within the repository 14.3 Automated de-aggregation (e.g. creation of learning objects from a course located on Blackboard) List additional relevant functions Digital Rights Management 15.0 Copyright, Licenses and Sharing 15.1 Digital rights languages 15.2 Create wording for licenses 15.3 Contain multiple licenses (e.g. various levels of Creative Commons licenses) 15.4 Restrict use of a license by user type 15.5 Display to depositors the rights the system provides 15.6 Display to users the permissions they have for use of the materials Texas Center for Digital Knowledge 35 December 2009

40 15.7 Online acknowledgement by end-users 15.8 Record users acceptance of use of a licensed object 15.9 Permit users to pay for copies of or access to resources Publishers can fulfill content requests through non-digital means Users may purchase resources and pay for them all at one time (e.g. shopping cart) Allow users to review the full terms of a license Search by license condition The product carries an Open Source License List additional relevant functions Presentation 16.0 Look and Feel Customization 16.1 Complete Section 508 compliance 16.2 Individual customized look and feel (beyond browsing and searching) Describe these customization features 16.3 Internationalization (e.g. different character sets from different languages) Translators to assist reading foreign language content 16.4 Branding text and graphics customizable List additional relevant functions Integration and Interoperability 17.0 Integration and Interoperability 17.1 Published API(s) for extending the application s core feature set 17.2 Published API(s) for integrating user or group data 17.3 Plug-ins 17.4 Repository can be included in a search done through another repository 17.5 Display resources directly within learning management systems (CMS/LMS) 17.6 List all CMS/LMS's the repository interfaces with 17.7 Describe this product's development record for integrating with new technologies to deliver/develop resources 17.8 Describe how easy the system can be upgraded List additional relevant functions Installation and Support 18.0 Community Support, Reporting and People Needed to Install 18.1 List all staff role types (e.g. System Administrator), likely duration and percentage of time required to support the implementation of the repository 18.2 Describe how the community of developers functions (i.e. list serve, discussion boards, wiki) 18.3 Describe the helpfulness and timeliness the developers take to answer questions 18.4 The system has an end-users accessible knowledge base 18.5 The platform provider gives reports on Usage level Question types Resolution statistics Time required for resolution Tracking of unresolved inquiries by institution Other 18.6 List known commercial support providers 18.7 Describe the procedures for bug reporting and client recommendations 18.8 Describe the best practice requirements used to keep the software code clean 18.9 Describe the level of effort and programming skill needed to modify and install the system Describe the number of known users and institutions globally using the product Texas Center for Digital Knowledge 36 December 2009

41 List additional relevant functions System Considerations and Specifications 19.0 User Management 19.1 CMS/LMS platform independent 19.2 Administrators can add, edit, and delete User accounts User and group roles Permissions from a role(s) within the system 19.3 Creation, editing, and deletion of user groups 19.4 Users or groups can be assigned more than one role 19.5 Administrators can customize permissions by role 19.6 Describe the types of permissions administrations can assign to users 19.7 Describe the batch tools used for creating, editing, & deleting user accounts 19.8 User accounts can be set to inactive Administrators can set accounts to become inactive based on a date and time 20.0 Tracking and Reporting 20.1 The system tracks and reports resource use 20.2 The system reports Who is currently logged into the system, time they logged in and session duration The last time a user logged in Account History Total number of published resources Total number of resources in an individual classification area Status of resources (e.g. number of resources at various publish stages) User details Institution Users current rights and privileges Logs of search terms used Error logs 20.3 Describe any additional reports available within your system Packaging and Specification 21.1 IMS content packaging specification List the version(s) 21.2 Incorporation of older content packages 21.3 SCORM standards List the version(s) 21.4 OAI functionality 21.5 Complies with IEEE-LOM standard List additional relevant functions Platform Profile 22.0 Software Infrastructure and Configurations 22.1 List the software the repository is compatible with Operating system Database management system Web server Browser Other 22.2 Describe the recommendations for the repository's platform to have operating system and database updates applied 22.3 Describe the firewall, server and other network changes required for the software to function normally 22.4 Software can be configured to use ports and settings other than the default Texas Center for Digital Knowledge 37 December 2009

42 22.5 Online back-ups 22.6 Is the software limited to a specified configuration? 22.7 List the latest version of the software 22.8 List which programming languages are used List additional relevant functions Desktop Requirements 23.0 Desktop Requirements Identify the minimum and recommended desktop specifications for users to be able to engage successfully with the repository application. Expand where necessary List for all OS versions CPU Model/Speed RAM Disk Space Other desktop considerations that impact interaction with the software List additional relevant functions Training 24.0 Training Availability 24.1 Types of training or instruction you think are required for: Basic repository users Advanced repository users (e.g. system administrators) 24.2 Describe the delivery method for this training 24.3 Describe the availability of this training List additional relevant functions Documentation/Help 25.0 Help and Overview and Technical Documentation 25.1 User and technical documentation available An overview of the system Step-by-step guides for typical user tasks Installation/configuration information System and database administration Technical information on jobs or modules executed Data element documentation Description of tables and views and the relationship of database entities Context sensitive help White paper Other 25.2 Describe the helpfulness of the documentation 25.3 List the formats in which documentation is available 25.4 Describe the date of the latest revision of the documentation List additional relevant functions Scalability 26.0 Scale up Scale out and Architecture 26.1 Describe if there are any limitations to the software's ability to add capacity (e.g. cpu, ram, etc.) 26.2 Used to scale out Caching Adding more instances Mirror sites List any other mechanisms used 26.3 The repository can be hosted over several different servers 26.4 List any limits on the maximum number of users the system will accommodate List additional relevant functions Texas Center for Digital Knowledge 38 December 2009

43 Appendix B: Questions Guiding the Semi-Structured Interviews with Implementers The following questions were the basis for the questions used in the semi-structured interviews with LOR implementers. During the interviews, the order of questions might change, and not all questions were able to be asked in the time available for the interviews. 1. Please talk to us about the reasons that led you and your organization to choose an OSS solution? 2. How did you arrive at a decision to use [the OSS platform/application]? What was your evaluation process like? 3. What are some of the challenges you have experience with implementing and using [the OSS platform/application] for a Learning Object Repository? 4. To whom would you recommend the use of OSS for the creation of a Learning Object Repository as opposed to using a proprietary system? 5. What cautions would you offer to those who are considering the use of OSS? 6. What do you need or recommend having in place to adopt and run an OSS solution, or more specifically [the OSS platform/application]? 7. In what ways have you come to appreciate using OSS because of your work with [the OSS platform/application]? 8. What do you see as possible future trends and directions for development of Learning Object Repositories? 9. In what ways do you think OSS will influence the development of Learning Object Repositories in the future? 10. What do you think about Learning Object Repository implementors sharing or exchanging technical staff to enhance the overall operation/functionality of OSS platforms for Learning Object Repositories or specifically [the OSS platform/application] for Learning Object Repositories? 11. Is there is anything else you would like to share with us about your experience with using OSS in general, and [the OSS platform/application] in particular, in the context of a LOR? Texas Center for Digital Knowledge 39 December 2009