Daniel R. Rehak, Ph.D.
Learning Systems Architecture Lab
Carnegie Mellon University
We are working on the problem of discovery of, and access to, learning content, i.e., "learning objects" that are typically stored within dedicated learning content repositories, learning content management systems or digital libraries. We assume the existence of collections of content in content repositories, each operating under its own rules and policies. We already have a set of accepted interoperability standards and specifications that describe the learning content objects themselves and provide interoperability across learning delivery and management systems. However, we do not have any common solution for discovery and access to the content from digital repositories.
Our overall solution is to create a federation from the existing content repositories. Through metadata federation in a central registry, we can provide a common point of access to the content collections for discovery. We are in the process of building different federations for different communities of practice, where each community's federation will need to define and operate under their own set of rules and policies (examples follow below). In addition, we are developing an overall model, denoted CORDRA (Content Object Repository Discovery and Registration/Resolution Architecture), to describe the work and enable others to build similar federations.
CORDRA, as a model, is an identified collection of interoperability specifications used to define how to design and build a repository federation. The model covers a range of topics, including content metadata descriptions, content exchange, search and discovery, security and access rights, service description, service composition, rights management, workflow, business and policy rules, etc. For a given community of practice, we create a profile of a set of these specifications covering these topics and provide guidelines for how a community may use the specifications in their operational infrastructure.
Rules and policies are required throughout our model to describe both how a federation is structured and how it operates, e.g., rules embedded or used within any of the various components or parts of the model and the rules used to govern the overall federation, its operations and description.
For example, to describe how a single repository will participate in a federation, we need to specify:
For example, the federation for a community may require that all of the constituent repositories make all of their content available for discovery. However, more likely, the community may wish to permit each repository to state its own policies. One repository may declare that all of its content is available for discovery, and there are no restrictions on access to the metadata for the content (there may be access restrictions on the content itself and further rights expressions on use). Another repository may permit discovery of all of its content, but may only want part of the metadata to be exposed to those looking for content (but other metadata may be used by the federation itself for management, index and discovery). A different repository may contain content where discovery is limited to users within certain restricted classes, e.g., within some indigenous cultures, there is content whose existence may only be discovered by certain members of the culture (some aboriginal tribes restrict access to and knowledge of certain cultural rights only to members of the tribe). We need to be able to describe all such cases so that the federation can provide a common discovery and access point, but can also properly maintain dissemination, access and control within its managed environment.
As another example, we need to control who might be permitted to "register" a content object within the federation (make it available for discovery). Within organization "a", only "approved" content may be exposed in the federation, but "unapproved" content may be in the repository. Organization "a" may be a hierarchy of suborganizations: "a.x" and "a.x.y". A separate organization, "p", may produce the content. "a" may delegate the authority for approval and registry to any of the suborganizations. "p" may produce content for both "a.x" and "a.x.y". "a.x" may permit "p" to act as its proxy, but this does not imply that "a.x.y" has permitted "p" to be its proxy in content registration. Furthermore, "p" may also work for organization "b", where the hierarchy of suborganizations and the management and approval controls are different.
There are other similar examples, including formal digital rights expressions for content use; access and authentication rules; workflow and service compositions rules; valid semantic mappings between data models; etc. Some of these appear to be more amenable to formal rule structures, but we wish to consider them all as examples of a broader category of rule and policy descriptions and behaviors applicable to the repositories, the federations, and any operations applied to the pieces or the whole.
As noted, we assume existing collections, existing repositories, and policy requirements. Some of these systems will already have established approaches for representing their rules while others will not. In building our model and federations, we will have to express rules in many places and will need to have interoperability of the various systems that process and manage the rules.
Thus, we have two overall key requirements:
We seek to understand what rule languages are appropriate to the various parts of this problem (we assume there is no universal language that will meet all of our needs), and how we can profile, extend or combine these into our model. It is our hope that adequate rule languages and related interoperability specifications exist; we wish to adopt and build upon existing work and to see appropriate existing solutions harmonized.
The CORDRA activities are being coordinated by the US Advanced Distributed Learning Initiative (ADL), the Corporation for National Research Initiatives (CNRI), and the Learning Systems Architecture Lab (LSAL).
This work has been supported by the US Advanced Distributed Learning Initiative. The views contained herein are those of the author and should not be interpreted as necessarily representing policies or endorsements, either express or implied, of the Learning Systems Architecture Lab, the US Advanced Distributed Learning Initiative, the Corporation for National Research Initiatives, or any project sponsor.