INTRODUCTION

In recent years, a variety of learning technology systems and interoperability standards (e.g., [16]) have been developed and adopted. All of these were aimed at increasing the reuse of "learning objects", reducing their development effort and providing interoperability of content across delivery and management systems. Additionally, there exists a diverse collection of both public and private content repositories and digital libraries containing these learning and content objects (e.g., [6,12,13,15]).

Reference models such as SCORM [16] have been proven effective in providing interoperability of content and course materials across delivery platforms. Metadata standards such as IEEE LOM [10] and the Dublin Core [4] provide an effective way to describe and catalog individual content objects. But content and system interoperability combined with content tagging and management are insufficient.

For example, the SCORM framework specifies how to develop and deploy content objects that can be shared and contextualized to suit the needs of the learner, and it provides the means to tag content for later discovery and access in a distributed environment. But SCORM is silent about how content discovery and access are to be implemented. Currently, discovering and accessing content for use, reuse or remix is ad hoc: you need to know where the content is stored and how to search and access it from individual repositories, typically in idiosyncratic ways.

While there are several ongoing efforts aimed at building federations of learning content and content repositories, e.g., [5,8] there is as yet no formal model of how to build such a federation, nor is there a common approach to creating a shared global infrastructure for learning content.

Thus, our goal is to develop a model of how to enable the next step in the evolution of e-learning, namely, how to solve the problem of seamless discovery and access to learning content. We approach this problem through the creation of interoperable registries of content and content repositories, i.e., establishing collections of repository federations, all conforming to a set of agreed-upon standards. Building upon existing technology from the worlds of learning content management and delivery, content repositories, and digital libraries, this model aims to identify and specify (not develop) appropriate technologies and existing interoperability standards that can be combined into a reference model that will enable learning content to be found, retrieved and reused.

CONTENT DISCOVERY and ACCESS PROBLEM

The technological and management problem we are trying to solve is that of how to provide access to learning content, under the base assumption that good learning requires ubiquitous content, which in turn implies the need for an operational content infrastructure. We recognize that while there is an existing body of content and a collection of content repositories, these do not interoperate in a seamless way. Furthermore, the successful adoption of the SCORM "reference model", i.e., a profile of a collection of interoperability standards targeted at a specific community of practice, illustrates that a similar approach could be used to provide an infrastructure aimed at the seamless discovery and access to content stored in the existing but diverse repositories.

We are motivated by a more direct problem. The government and military education and training sectors in many countries have begun to mandate the use of SCORM in the creation of learning content. They further require that organizations search for and reuse existing content when feasible and that they make existing content available for reuse. Thus, while SCORM provides the model for the content itself and the content delivery environment, it does not provide a model that can be applied to content or content repositories such that content can be easily discovered and accessed outside of courses. No model similar to SCORM is available for repositories, content discovery or content access.

Rather than simply mandating a specific architectural solution or system for content discovery and repository interoperability (in particular, how to combine repositories into an overall content infrastructure in an interoperable way), we promote the reference model approach. While the government and military sectors have some unique requirements, the general problem of content discovery, access and repository interoperability needs to be addressed across all education and training sectors. We posit that we can develop a general solution applicable and adaptable to all sectors.

We are taking a multipronged approach. We are building a set of specific implementations of federated content repositories for specific communities of practice. At the same time, we are developing and documenting a formal underlying reference model that can be applied and adopted broadly. Much of our actual work is derived from prior attempts (successful and unsuccessful) to build such federations, leveraging existing technologies and standards, and lessons learned [1,2,11,14,17]. Our broad goal is that this reference model can become the basis for a global content infrastructure.

As base requirements, we assume a content infrastructure must:

• support the discovery and access to content;

• provide content management;

• operate under the specific policies of the individual institutions, collections and repositories; • work "at scale"; • be robust and reliable; and • make business sense to those who will fund, develop and deploy it.

Within this infrastructure, we want to make content widely available, easy to find, independent of courses and seamlessly accessible. We want to enable reuse and remix, but maintain content in a managed environment, subject to appropriate rights management. We assume that existing systems and technologies must integrate or interface to be part of the overall infrastructure, i.e., the elements of the infrastructure will be built on diverse technology platforms that need to interoperate and integrate with other systems, but remain independent.

Thus, we are developing a model for a content infrastructure centered on the broad problem of content discovery and federated repository integration. Such a federated repository model addresses not only the problem of allowing the participants to remain independent except for their agreement to minimal "interfaces", but also provides a common, centralized method for discovery and access. The resulting model must support a set of core capabilities:

CORDRA 3.1 Framing the Model

• "published" content will be widely available;

• content can persist outside of the context of a single course or other learning structure or delivery paradigm; • content can be easily discovered; • there will be standard mechanisms for content access; • content can be managed (ownership, rights, access, provenance, persistence); • operations are tailored to meet the needs of the participating organizations and institutions; • use open standards-based interoperability; and • support integration of and with current systems for repositories, management and content delivery.

Additionally, since we are attempting to model and build a large infrastructure, it is important that we consider some of the attributes of successful infrastructure development. By observing how infrastructures have evolved in the past, we hope to minimize problems. History has shown that successful infrastructures [7]:

• evolve from local to global. They start with a local system for local uses and users, and then connect with other local systems to build the broader network. • grow in size and importance with demand. There is a cyclic feedback loop: more demand increases use and size, which increases demand, attracting more users, ….

• use primarily core, scalable, reliable, existing technology. Existing technology is refined, extended and adapted to build the infrastructure. No core technologies are created directly for the sole purpose of creating the infrastructure. • have open connections and interfaces specified through minimal interoperability standards. Anyone who meets the stated interoperability requirements is permitted to join the network. Interconnection requirements are limited to only those essential for successful operations. • seamlessly connect from source to sink. Provide a single model and approach for the user, eliminating technological impedance barriers between the interconnected elements and automating the flow of information or payload from its origin to its final destination. • enable value-added services. Provide only core features in the common infrastructure, and support mechanisms for others to independently add their own services and features under their own business models. • provide separate levels of functionality.

Maintain independence, both in technology and management, of features such as generation, transport, delivery, and management.

• focus on the right users. Know who from the user community (developers, end-users, managers, individuals, businesses, etc.) are key players and provide the functionality that they need. • handle peak demand and fractional use. Know what the peak demands are, and build a system to support those, but understand that individual users have smaller demands. Users will need only a fraction of the power of the infrastructure at any time. • enable local operations and policy. Allow the participants in the infrastructure to operate under their rules and policies. • provide differentiated services. Identify when a single level of service or model will not suit all users and provide appropriate different models for different groups, possibly at different costs associated with the level of service. • apply appropriate policies and governance. Both local and global management of the infrastructure are critical. • make appropriate business decisions. Participants will all have different value propositions, and the solution must be attractive to both providers and consumers. • move to ubiquitous or universal service. Provide a system that can provide a minimal level of service to all users. • build systems, not components or payload. Focus on the infrastructure itself, both as technology and management.

Enable and rely on others to build the tools and components of the infrastructure and to provide the payload, data or information that moves through the network.

Moving from this historic background and through the requirements, we highlight five key assumptions underlying the development of CORDRA:

• there are sufficient interoperability standards. We assume the core standards exist, and that while they may need to be adjusted and extended, we do not need to first define a new set of core standards before we can begin to define the model and build operational systems. • the core technology is stable. Again, we assume that the available digital library or repository, internet, and learning technologies are sufficiently stable for us to begin.

• there is sufficient demand, i.e., we are not premature in developing a solution to the problem. • we can capture and express the key requirements and properly include these into the overall solution.

• the policy problems are solvable. Our experience in developing and deploying digital library and learning technology systems tells us that solving management and policy issues is critical, often overriding the technical issues.

More importantly, while we understand that there have been unsuccessful attempts to build major repository federations in the past, and that many of the digital library systems have not fulfilled the promise, we hope we are now at a new tipping point: demand, technology and standards have matured such that we can now be successful.

The amalgamation of assumptions, requirements and historic background together forms the basis for CORDRA. CORDRA itself is a label for three different items:

• a model of how to create local federations and a global learning content infrastructure; • a project working to define and document the model with sample tools and implementations; and • a working system -a global federation of content registries.

We describe each of these below, focusing primarily on the overall formal reference model.

CORDRA Model

CORDRA is designed to support the federation of existing content repositories where these are combined into a single source for content discovery and access.

The formal model (the CORDRA reference model) can be used to design and implement such federations of repositories.

The overall CORDRA model for a single content federation is illustrated in Figure 1.

• Learning content remains in existing (local) content repositories that are managed and operate under their own local rules. • Repositories and content (i.e., content metadata) are registered within the federation to enable discovery, access and management. • The federation registry is a collection of system repositories that maintains a master catalog of all learning content metadata, the repository registry listing all repositories within the federation, and an additional repository with system data, models, etc. • Content is located by searching against the master catalog.

The catalog may also maintain additional indexing information, usage data, context, etc., that are used to rank and identify the most appropriate results to satisfy a discovery query. The other system repositories contain declarative and semantic models used in CORDRA operations. • An identifier system provides an infrastructure for object identification, registration and resolution. • A common services infrastructure provides the core technical and administrative services and overall software design paradigm used throughout a federation (authentication, security, rights management, business rule processing, etc.).

• End-user interfaces and application systems (search, discovery, authoring, personalization, customization, delivery, etc.) are used to catalog, find, manage and deliver learning content and content objects. These are built as value-added services on top of the core federation structure.

The CORDRA model is based on key characteristics, consistent with the requirements and background as illustrated in Figure 1: • persistent, actionable (content) identifiers;

• individual content repositories;

• federated metadata;

• single point of search;

• service-oriented design;

• core, common services;

• a scalable infrastructure / technology base;

• value-added user services and applications; and

• open standards.

Within the model, a repository is defined as a persistent, managed store of content with a set of defined service interfaces used to integrate and interface it with the federation. There are no other stated technology requirements, i.e., we are silent on how to implement the repository or indeed if it is a software system, physical, or virtual. All repositories are registered as part of a CORDRA implementation.

The content repositories that participate in the federation are operated and maintained independently of the federation itself.

Within the model, in addition to the individual content repositories, a federation has three system repositories:

• the master catalog or content registry, containing metadata instances of content from the individual contributing repositories used for all search and access; • the repository registry, containing the descriptions (metadata, policies, access information, etc.) of all repositories in the federation; and • the system registry, containing the machine processible descriptions of the CORDRA model and its implementation within the federation. All of these repositories are registered in the repository registry, enabling a self-descriptive system.

Figure 1: Model of a CORDRA Federation

A key concept of the CORDRA model is the federation of metadata from the individual source repositories into the single federation metadata registry. Based on prior work, we believe that such a model is scalable and provides robust, reliable quality of service and uncouples discovery from any idiosyncratic features of individual repositories. It also provides the means to easily build independent value-added services.

The model relies on a formal identifier infrastructure used to provide a persistent, unique "name" or label for each item. Identifiers are actionable, with multiple resolution, providing a mapping from the name to a set of information used in processing. There are collections of namespaces for identifiers; content collections use their own namespace; each federation has a namespace for elements used to define and operate the federation; and there is a CORDRA namespace for elements of the CORDRA model itself.

A set of common services are used to build a federation; e.g., identification, authorization, authentication; digital rights expression and management; policy and rules processing (workflow); search and harvest interfaces; identifier resolution; security. All of the service definitions are stored within the system registry. The overall model is based on a service-based approach (not necessarily a Service-Oriented Architecture [SOA]), defining operations and behaviors as services.

The applications and value-added services are built on top of the common services and the federation infrastructure. They provide a collection of service-oriented models with user interfaces or user agents to provide features such as content search, content registration, content harvest, repository registration, content delivery, and content assembly and customization. Since these services can be defined and built independently of the federation, we do not attempt to define or limit what someone may want to build, but rather try to enable a range of add-on features.

In the above, we described the model of a single content federation, i.e., a single collection of repositories. However, we want to enable the creation of many federations, each containing a different collection of repositories. More importantly, as noted above, we expect that each of these federations will need to operate under a different set of rules and policies, be implemented on a different technology base or platform, and use a different set of interoperability standards. For example, one federation may be public and one may be private; one may be built assuming content metadata is harvested from the repositories and another may require an active deposit and registration process. Likewise, one federation may rely on LOM metadata, and another may use Dublin Core to describe all content objects. Thus, we need to define CORDRA as a model to permit the development of federations under a collection of different technology, policy and management schemes. Thus, the CORDRA model is defined at three discrete levels as illustrated in Figure 2.

• The Core CORDRA Reference Model defines the structure, features and capabilities of CORDRA without defining how to implement it within a particular community of practice. The core model includes the system vocabularies, rule representations, system data models and schemata, service models and their definitions, and the CORDRA metadata. These items are defined both in human-and in machineprocessible forms, and are assigned identifiers from the CORDRA namespace. The core model is independent of any implementation or federation, but is used to define and describe each of the implementations and their instances. • A Community Implementation describes a particular implementation of the CORDRA model. It specifies the set of data models, taxonomies, business rules, system structures, interoperability standards, etc., for a particular community. These models are defined in terms of the description and modeling features of the core CORDRA reference model. We anticipate many different implementations, and describe the initial ones below. At this level in the overall CORDRA model, the description of the federation does not specify operations or mapping to an operational infrastructure, i.e., the implementation defines what a federation does, not how to create and operationalize it. • An Operational Instantiation defines the characteristics of a single running instance of an implementation for a particular community. These include the choice of binding of components to actual network names, namespaces, operational policies (backup, mirrors, etc.), hardware, software and operating system choices, etc. Any implementation may support any number of instantiations, e.g., production versus development systems. The characteristics of the instantiations are defined by the implementation and its community; they are not part of the CORDRA reference model.

Federated CORDRA: Federation of Federations

As described above, we have developed a model of how to create individual federations of content repositories, each federation being built to meet the needs of a specific community of practice. We expect that many communities will want to create their own implementations. However, creating multiple implementations still does not meet the goal of seamless access to ubiquitous content. Users still need to be aware of the different federations and need to directly access the appropriate registries for content discovery.

Rather, we desire a single point of access to all content, independent of repository or federation. Thus, the overall CORDRA model includes the concept of a federation-offederations, denoted as Federated CORDRA.

As illustrated in Figure 3, Federated CORDRA is the collection of CORDRA community-specific implementations. It is defined through a registry of the corresponding CORDRA registries, i.e., a registry-of-registries (RofR). The central federation registry also includes within its system repository the definition of the various CORDRA system objects that are independent of any individual implementation.

Following our overall approach of building self-descriptive systems, the federation-of-federations registry is just another CORDRA implementation and follows the overall approach and reference model. Here the community is the global community of all other federations, and the implementation defines how all of the federations register their registries into the overall federationof-federations registry. We do, however, limit the model to a single level of federation, believing that for reliability and performance, the user should never be more than two steps away from content: federation-offederations registry to an individual federation registry, and then from the federation registry to the content repository.

Figure 3: Federated CORDRA

We currently have not determined what will go into the registryof-registries. Should we store all the metadata for all the objects in all the repositories in all the registries in all the federations? Or just the total list of all the repositories or just the list of registries? The primary function of the RofR is to be a single starting point for access and discovery. Starting at the root, how do you get to an individual content object? One can imagine searches being mapped from one federation to another; one can imagine search results that just summarize what you might find in the different federations; one can envision dispatching mobile agents across an array of identified federations to gather search results or even samples of content, etc. The ability to build various applications and searches on top of the RofR will depend on its content, but much of the functionality can be abstracted from the implementation details. The design and implementation will evolve as the infrastructure evolves, and as we learn what will or will not work.

CORDRA Project and Status

Work on the project has been underway since 2003. Our initial goal was to create a single instance of a federation of content repositories for the US military, operated by the Department of Defense (DoD). The primary objective of this federation was to support the discovery and access to SCORM-based learning content.

As we developed the initial design and plans for this federation, we recognized the need to separate the underlying model from the actual implementation, and further recognized that one single federation will not meet everyone's needs. Different communities will have different specific requirements, but it should be possible to create a general model, and develop specific versions of that model (profiling the generic profiles) for specific communities. Thus, we differentiated CORDRA as the general model and the project description from the specific implementations. The US DoD implementation of CORDRA is now designated the ADL-Registry (ADL-R).

The ADL-R has been in development and testing since mid-2004. Elements of the system are based on prior work on systems such as Fedora and Cross-Ref [1,2]. The ADL-R uses the Handle System [9] as a core component, and incorporates other off-theshelf software, including commercial products such as database management systems, LDAP directory software, XML processors, etc., with elements from open source projects such as the Apache Project (Lucene, Apache Web Server). We currently anticipate that the ADL-R will go into production operations around mid-2005.

The ADL-R incorporates a set of core capabilities, focusing on the central content metadata and repository registry:

• content and metadata instances are identified with Handles;

• repositories and their core management policies are described and registered within the central registry; • metadata instances, described using LOM, are deposited in the registry; • simple and extended search operations are available to discover content and its metadata from the registry; • search and query operations are available to discover policies and information about the repositories that are part of the federation; • internationalization is supported throughout; and • operational and status data are available.

In addition to the operational registry, we are developing a user portal for search and discovery. Other supporting elements include a test harness and test data; help desk support; system documentation; and the development of operational policies for the registry, the participating repositories and the organizations that deposit and manage content.

The ADL-R has multiple operational instances: a development environment with prototype system that includes developmental and test bed instances; and a production environment with primary and backup systems. Quality of service, performance monitoring, replication, backup, etc., are key aspects of making the ADL-R a robust, reliable, operational system.

We are beginning the development of a second CORDRA implementation for a different sector within the US Government. We aim to address a number of different topics in this work:

• understanding how to move from the existing ADL-R implementation to a new community; • how to both capture the community's requirements and modify the core system to include their needs; • developing web service interfaces;

• exploring access and rights management issues;

• exploring models for harvest, indexing and advanced search; • developing an approach to capture and process local repository and registry policy and business management rules; and • demonstrating value-added services for content creation, management and delivery.

As with the ADL-R, this implementation will demonstrate the overall model in a production environment and will help shape and refine the model. We anticipate that the results from this second implementation will eventually be folded back into the ADL-R.

We are also in the planning stages for other CORDRA implementations for other communities. Once we have a few operational implementations of federated registries based on the CORDRA model, we will begin the development of Federated CORDRA, the federation of federations.

Our approach is thus multipronged as stated above. We are developing and building operational implementations of CORDRA for specific communities in order to understand requirement and needs and to test our concepts. We take the results of this work to define and shape the overall model, allowing us to produce and refine the formal description of the CORDRA model.

The CORDRA project is thus the collection of all of these activities: defining the model, coordinating the various implementations, and providing a way to build the federation of federations. The project includes the dissemination of the CORDRA documents and outreach activities. Sample code, tools, test data, etc., will also be released to the community as part of the project.

Beyond the technical work, we continue to explore how to move CORDRA, as an idea, beyond its roots in specific projects. The long-term plan is to move the work on the model itself and the operations of the federation of federations to appropriate governance and stewardship bodies.

SUMMARY

Key requirements and how the work meets them can be summarized as:

• users want to easily discover learning content and want their content to be found: provide a "one stop" search interface; • users want to find the right content in context: use appropriate indexing and ranking data and algorithms in conjunction with search; • searchers want precision of search results, returning only what they need: use proper classification and good metadata; • we need flexibility and an approach that will scale, and forcing new or rigid information, service and protocol models is unpalatable: use self-descriptive and semantic modeling; • integration and interoperability with existing systems and applications are required and we cannot foresee all of the required capabilities: use a service-oriented approach; • providing tailored operations for communities of practice to enable local policies and business rules, not define them: include discoverable and machine-processible policies; and • ease of use is essential: develop supporting tools and user support and guidance.

CORDRA is an overall reference model that attempts to meet the goals, requirements and assumptions described herein. It defines how to build federated repository systems to support the discovery and access to learning content that operate through the federation of metadata from the contributing repositories. The CORDRA model and implementations of it are built on existing technologies, and the reference model is formally defined and represented through a profile of a collection of existing technology standards and specifications. In short, the CORDRA reference model is just a profile of interoperability standards and the additional glue needed to join them into a cohesive whole that can be successfully applied and implemented.

A community of practice selects a set of policies, rules, technology choices and decides on appropriate specifications for their needs. These choices are then reflected in the specific federation of repositories built for their needs. Each community then has its own federation registry used for content discovery and access (perhaps with multiple operational instances).

These individual community federations are then integrated into a global federation of registries, the federation-of-federations, that also follows from the overall CORDRA model.

Together, these elements define a model for a global operational learning content discovery and access infrastructure.

We are developing this overall infrastructure and model by working from individual implementations, testing and refining our work as we proceed. We combine our results into the formal model, open source tool set and documentation being released to the community.