Document Information
Status: Draft
Version: V1.00.20050101
Revision Date: 2005-01-01
"When I use a word," Humpty Dumpty said in a rather a scornful tone,
"it means just what I choose it to mean--neither more nor less."
"The question is," said Alice, "whether you can make words mean
different things."
Abstract
The term CORDRA™ has been used in many different and confusing ways. Different uses and meanings of CORDRA are described and defined.
CORDRA (Content Object Repository Discovery and Registration/Resolution Architecture): An open, standards-based model for how to design and implement software systems for the purposes of discovery, sharing and reuse of learning content through the establishment of interoperable federations of learning content repositories.
There is general confusion over the exact meaning of the CORDRA™ term. Is it a concept? An artifact? An activity? It's all three, and maybe more.
The fact that the acronym has been used informally, and in unclear and possibly confusing ways in various documents and presentations, has not helped. Indeed, there are many different legitimate ways in which the CORDRA term is used.
The situation has been further complicated because it isn't clear if the CORDRA term is a noun or an adjective, i.e., is there such a thing as the CORDRA. While we will take the view that CORDRA can be used as a noun (and may have a definition as shown above) and anticipate that it will often be used as a noun, it is properly an adjective.
Many of the confusing uses of CORDRA occur when the acronym should be used as an adjective, but the noun that it is modifying is omitted (often because there may not be a single, appropriate noun for the particular use, or simply through omission when the meaning was obvious to the author).
Further confusion arises when the CORDRA terms (see below) are used in conjunction with some conventional terms (e.g., implementation, instance, instantiation) in very specific and sometimes grammatically confusing ways.
Below we list a number of the different ways in which the CORDRA acronym is used. While official CORDRA documents should use the terms in the ways described, this document itself is not normative, but is simply meant to help others understand What's "CORDRA".
We will try to use CORDRA as an adjective in the remainder. We also fully qualify nouns with the CORDRA adjective in all appropriate uses rather than taking the shortcut of just using the unqualified noun.
The CORDRA acronym has multiple expansions.
Thus while we have seen different meanings, and the R has multiple expansions (and so may D), the CORDRA acronym should be expanded in one of these three ways:
CORDRA Project: The collection of activities that centers on defining and supporting the CORDRA model and building instances of federations of content repositories using the CORDRA model.
The CORDRA project is currently coordinated through the Advanced Distributed Learning Initiative.
CORDRA Model: An open, standards-based model for how to design and implement software systems for the purposes of discovery, sharing and reuse of learning content through the establishment of interoperable federations of learning content repositories.
The CORDRA model is formally defined via the CORDRA Reference Model.
The CORDRA model is only one possible model of federated content repositories. The repositories framework can be used to describe how the CORDRA model relates to other models of content repositories.
Note, the CORDRA model defines how to design and implement such a software system, i.e., the required features, abstract components, behaviors, underlying data models and specification. It does not define the actual software design and implementation. The CORDRA model must be specialized for a particular community, i.e., a CORDRA implementation, and that specialization must be mapped to an operational software system, i.e., a CORDRA instance.
CORDRA Reference Model: An application profile combining a collection of standards and specifications (defacto and de jure) and CORDRA model-specific documents that are the definitive human readable description and definition of the CORDRA model.
The CORDRA reference model defines the (abstract) components of the CORDRA model, their required features and behaviors, and their underlying data models.
There is only one CORDRA reference model.
CORDRA Semantic Model: A machine processable representation of elements of the CORDRA model. The CORDRA reference model defines how to represent the CORDRA model in a machine processable form.
Note, the machine processable form includes a semantic description of how to represent the semantic model itself, i.e., the semantic model is self-referential and defined in terms of the semantic model. Self-referential (recursively defined) models are a key aspect of the overall CORDRA model.
CORDRA Implementation: An application profile of the CORDRA reference model for a particular community of practice. A CORDRA implementation selects and specializes particular specifications and design choices from those alternatives that are defined in the overall formal CORDRA reference model.
For example, the CORDRA model includes metadata to describe content objects. The CORDRA reference model incorporates particular metadata specifications used to describe the metadata for the content objects. A particular community may decide which metadata fields are required, how certain fields are used, or may specify a particular collection of vocabulary terms for certain metadata elements. These choices are specific to the community, and while they define the characteristics and behavior of a CORDRA implementation, the range of possible choices is constrained by the overall CORDRA reference model.
The CORDRA implementation is defined both through a set of human readable documents and through a set of machine processable documents. The CORDRA implementation is realized as an operational software artifact, i.e., a federation of repositories, through a CORDRA instantiation. The machine processable representation of the implementation is part of the CORDRA instance.
It is anticipated that there will be many different, independently specified CORDRA implementations. But all CORDRA implementations are based on the single CORDRA reference model.
Editorial Note: There may still be confusion between the formal model that describes a CORDRA implementation and the general idea of a CORDRA implementation being an artifact. While we use the term CORDRA instantiation or CORDRA instance set for a collection of CORDRA instances built according to a CORDRA implementation model and their associated governance, the artifact generally is part of a larger operating or community environment that includes other features that are external to the CORDRA implementation. This collection of CORDRA instances and its overall environment, description, governance, operations, policies, etc., is generally given a specific name by its community, e.g., the ADL Registry. We currently do not have a formal name for this type of larger environment and associated artifact.
CORDRA Implementation Model: See CORDRA Implementation. While we have used CORDRA implementation (or CORDRA community implementation) in the past, CORDRA implementation model more precisely names the concept.
CORDRA Community Implementation: See CORDRA Implementation. We have used this term to reinforce that a CORDRA implementation is defined for a particular community of practice.
CORDRA Implementation Governance: A collection of operational and governance rules for the CORDRA instantiation that corresponds to a particular CORDRA implementation, e.g., rules such as which repositories may participate within a particular federation. The governance rules cannot be captured within the CORDRA reference model or CORDRA semantic model and cannot be enforced via a CORDRA instance.
CORDRA Instantiation: The operational federation (or federations) of repositories built according to the definitions from a CORDRA implementation and the CORDRA instance specifications. A CORDRA instantiation is an operational software artifact, i.e., it is a collection of software and hardware systems.
There is only one instantiation of a CORDRA implementation. Within the instantiation there may be multiple instances of a CORDRA implementation. The different CORDRA instances of the same CORDRA implementation (as elements of the CORDRA instance set) will provide the same functionality and behavior, but possibly different performance, underlying structure, or local operational procedures.
Different CORDRA instances within the CORDRA instance set are typically related, e.g., the production instance, the test-bed instance, the development instance, the public instance, the private instance. However, this is not a requirement, and different constituencies within the same community may have their own CORDRA instances. While these CORDRA instances would be built on the same CORDRA implementation model and have the same overall CORDRA implementation governance (and thus would offer the same functionality), they might be governed by different local (instance-specific) values for the rules and procedures within the CORDRA implementation governance.
CORDRA Operational Instantiation: See CORDRA instantiation. We have used this term to reinforce that the CORDRA instantiation is an operational artifact, not just a concept.
CORDRA Instance: A single operational federation of repositories (hardware, software, local policy rules) within a CORDRA instantiation. There is at least one CORDRA instance within the CORDRA instantiation.
If there is only one CORDRA instance within the CORDRA instance set for a particular CORDRA instantiation, the CORDRA instance, CORDRA instance set and CORDRA instantiation are isomorphic.
CORDRA Instance Set: The collection of all CORDRA instances within a particular CORDRA instantiation. Each CORDRA instance will have a different CORDRA instance specification.
CORDRA Instance Specification: The definition of the particular details of a CORDRA instance, such as machine domain names, hardware and operating system choices, models of hardware replication, selection of tools (e.g., DBMS or search engine choices), etc.
These details are independent of the characteristics of the CORDRA implementation or the CORDRA instantiation. For example, the specific hardware and software characteristics that follow from different choices still result in an operational federation with the same overall functionality and behavior, e.g., the test-bed instance might not be distributed or have replicated hardware components, but the production instance would.
CORDRA Federation: The collection of repositories and registries that participate in a CORDRA instance or CORDRA instantiation. As an operational software artifact, a CORDRA federation is a CORDRA instance.
CORDRA federations typically have their own formal designation, e.g., the ADL Registry. Such a designation may apply to all CORDRA instances within the same CORDRA instantiation and CORDRA implementation. The designation may also encompass more than the software system and may include various operation, policy and management features that are not captured within the operational software artifact.
Editorial Note: We do not have a way to differentiate from the federation at the individual CORDRA instance level, versus the larger concept of a federation for a community, at the CORDRA instantiation level, and encompassing more than just the software artifact. For example, does the ADL Registry as a federation denote only the production instance or both the production and test-bed instances, or the entire environment in which the various instances operate (instances, portal, help desk, etc.)? Thus we will use the federation term to denote the larger, community concept.
CORDRA Repository: A repository that is part of a CORDRA instance (or CORDRA federation). Additional qualifying terms are used to describe repositories that have a particular role in a CORDRA instance (or CORDRA federation) or within the CORDRA model.
Every repository that is part of a CORDRA instance is listed in the CORDRA repository registry for that CORDRA instance.
A CORDRA repository that is part of a CORDRA instance (or CORDRA federation) must abide by the rules of the instance or federation, i.e, both technical such as which services to provide, and operational or governance rules. These rules are specified in the CORDRA implementation model and CORDRA implementation governance model for the CORDRA instantiation.
CORDRA Registry: A registry or catalog within a CORDRA instance (or CORDRA federation). Additional qualifying terms are used to describe registries that have a particular role in a CORDRA instance (or CORDRA federation) or within the CORDRA model.
A CORDRA registry is a type of CORDRA repository, i.e., a repository used to store catalogs of items.
Editorial Note: There may be confusion over the idea of a CORDRA registry as a particular type of repository within a CORDRA instance (or CORDRA federation) versus the generic concept of denoting a CORDRA implementation/instantiation as a registry, e.g., the ADL Registry.
CORDRA Repository Registry: The registry of the repositories that participate in a CORDRA instance (or CORDRA federation), i.e., the list or catalog of all of the repositories that participate in the CORDRA instance.
Within the CORDRA model, a CORDRA registry is a type of CORDRA repository. Given the recursive, self-descriptive CORDRA model, the CORDRA repository registry, as a CORDRA repository, is listed within the CORDRA repository registry as one of the CORDRA system repositories.
Within the CORDRA model, the CORDRA repository registry is one of the CORDRA system repositories.
CORDRA System Registry: The CORDRA repository that holds all machine processable elements that define the CORDRA implementation for the CORDRA instance, i.e., the CORDRA repository that holds the specialized CORDRA semantic model for the CORDRA implementation.
Within the CORDRA model, the CORDRA system registry is logically instantiated for each CORDRA instance within the CORDRA instantiation. This, however, does not limit multiple CORDRA instances within the CORDRA instance set from sharing a single software artifact that is the CORDRA system registry.
Within the CORDRA model, the CORDRA system registry is one of the CORDRA system repositories.
CORDRA Master Catalog: The CORDRA repository that holds the collection of all metadata instances for all content objects that are registered within the CORDRA instance.
The CORDRA model is based on a federated metadata catalog, not distributed or federated search.
Within the CORDRA model, the CORDRA master catalog is one of the CORDRA system repositories.
CORDRA System Repositories: Within a CORDRA instance or the CORDRA model, there are three repositories: the CORDRA system registry, the CORDRA repository registry and the CORDRA master catalog.
The CORDRA system registry, repository registry and master catalog are abstract entities in the CORDRA model. The design of a CORDRA instance (the CORDRA instance design) will specify how these entities map to actual software and storage artifacts.
CORDRA Architecture: As an expansion of the CORDRA acronym, the term CORDRA Architecture is redundant. While we try to avoid the term architecture, it has been used to describe the overall software design of federated content registries using the CORDRA model.
CORDRA Instance Architecture: See CORDRA Instance Design
CORDRA Instance Design: The actual software design and software tool or component selection choices used to create a CORDRA instance. Note, the design is defined at the level of the CORDRA instance, not at the level of the CORDRA instantiation or the CORDRA implementation. Two different CORDRA instances of a given CORDRA implementation or CORDRA instantiation may have different software designs.
The CORDRA instance design differs from the CORDRA instance specification in that the CORDRA instance design specifies particular coding and software design details. An operational artifact built according to a particular instance design could have multiple instantiations, each described by an independent CORDRA instance specification. For example, there would be a CORDRA instance specification for a test-bed instance and a different CORDRA instance specification for the production instance, but both instances could operate the same code base from a common CORDRA instance design.
CORDRA Operations: The collection of operations (their definitions, interfaces and behaviors) that can be applied across all CORDRA instances within a CORDRA implementation.
The CORDRA reference model defines a common set of operations that should be supported in all CORDRA implementations.
CORDRA Applications: The collection of user and system applications that are built around and on top of all of the CORDRA instances within a CORDRA implementation.
The CORDRA implementation model defines a common set of applications that should be supported in the CORDRA instantiation.
CORDRA Components: The collection of elements (repositories, system repositories, applications, services, models, etc.) that are part of the CORDRA reference model.
CORDRA Services: The collection of services (e.g., web services) that an application or user agent may call to access the functionality of a CORDRA instance.
The CORDRA reference model defines a common set of services that should be supported in all CORDRA implementations.
CORDRA System: This term is currently not used.
Note, the term system is already overloaded with conflicting uses, e.g., the CORDRA system registry and CORDRA system repositories are artifacts within any CORDRA instance, while the CORDRA system implementation and CORDRA system instances represent larger concepts.
CORDRA System Implementation: A CORDRA implementation defined by the CORDRA project. The CORDRA system implementation is the source of the machine processable CORDRA semantic model. CORDRA repositories in the CORDRA system hold the CORDRA documents.
CORDRA System Instantiation: The CORDRA instantiation of the CORDRA system implementation.
CORDRA System Instance: An instance of the CORDRA system implementation.
The CORDRA system registry within a CORDRA system instance holds the CORDRA semantic model. The CORDRA document repository is registered with the CORDRA repository registry within the CORDRA system instance.
Federated CORDRA: A CORDRA federation where elements of the federation are themselves CORDRA federations, i.e., the federation of all CORDRA instantiations.
Within the CORDRA model, an instance of Federated CORDRA may not participate in another federation.
CORDRA Profile: This term is currently not used.
CORDRA Reference Implementation: A collection of sample software code, tools and machine processable data models (schemata, semantic models, vocabularies, taxonomies, ontologies) that can be used as the basis for creating a CORDRA instance.
The CORDRA reference implementation is not normative or definitive, but only an exemplar.
In this use, the term implementation should not be confused with the use of implementation within the term CORDRA implementation. Here a reference implementation is a software artifact, not the specialization of the CORDRA model for a particular community (albeit that the reference implementation does encapsulate a particular set of CORDRA specializations of the CORDRA model).
Editorial Note: We need the term that defines the CORDRA implementation that is the basis for the reference model. For now, we assume the CORDRA reference implementation corresponds to the CORDRA system implementation, but this need not be the case.
CORDRA Document: A document that formally defines a part of the CORDRA reference model.
CORDRA Document Repository: A CORDRA repository that contains all of the CORDRA documents.
CORDRA Identifier: A unique, persistent identifier assigned to a CORDRA document, an element of the CORDRA reference model or an element of the CORDRA semantic model. A CORDRA identifier is a HANDLE whose naming authority part is one of the valid CORDRA Handle naming authorities.
Additional qualifying terms are used for particular collections of CORDRA identifiers.
CORDRA Domain Name: The CORDRA project has registered several internet domain names, including the domain name cordra in various top-level domains (TLDs) (.com, .org, .net). While all of these domain names are valid, the preferred CORDRA project internet address is cordra.net.
CORDRA Web Site: The CORDRA project web presence is at http://cordra.net/ Other TLDs are valid.
CORDRA Trademark: The CORDRA acronym is a trademark. All official uses of the term should indicate that it is a trademark (™). As a trademark, it should be used as an adjective.
CORDRA Handle Naming Authorities: The collection of Handle naming authorities used by the CORDRA project.
The CORDRA project uses the Handle System for identifiers for CORDRA project resources, including CORDRA documents, elements of the CORDRA document repository, elements of the CORDRA semantic model, elements of the CORDRA system instance, and documents within the CORDRA web sites, e.g., the Handle H [hdl:2000/1]. resolves to cordra.net
Framework: An overall vocabulary (of services or components) used to model concepts and behaviors within an environment or to create a particular type of infrastructure (system or environment). Associated with the vocabulary is the grammar or language used to describe how the elements are combined or constrained to create systems and environments.
Repository Framework: An overall model that describes how a collection of repository and registry services could be described and specified. Repository and registry systems and artifacts are created by combining the various services that are described in the framework.
A repository framework is a particular type of overall framework. The vocabulary is the collection of models and services related to repositories and content or information management.
Editorial Note: The relationship between CORDRA and the overall elearning framework (ELF) and repository framework is described separately.
Reference Model: A collection of items selected from one or more frameworks (elements from multiple vocabularies). These items are combined according to a set of rules and constraints to meet the requirements for a particular infrastructure or environment.
Design: Specification of an artifact derived from one or more reference models. The design is created by selecting and specializing elements from the reference model, combined with the addition of constraints imposed by a particular community or from the technologies that will be used to create the resulting artifact.
Multiple different designs can be derived from the same set of reference models.
Pattern: See framework.
Pattern Language: The language or grammar used within a particular framework.
Artifact: An operational collection of software. Something which can be recognized as an entity.
The realization of a design. There may be multiple artifacts created from the same design, but all will share the same behavior.
Service: A definition of function and scope specified through statements of behavior and data representation.
Service artifact: A functional artifact used to realize the behavior and function for a service. The artifact will be have a collection of interfaces (data interfaces and control interfaces) used to access or invoke the service such that it performs its specified behavior in context. The interfaces are realized through a particular set of technologies specified as part of the design of the service artifact.
Application Profile: A customization of a single standard (defacto or de jure) or specification for a community of practice. The customization may be through both the specification of constraints on how features are used (or not used) and through the definition of extensions. It may also define how elements of the standard are interpreted and used for the community.
A collection of application profiles and additional components used to provide the vocabulary for a framework.
The following lists attempt to clarify which of the key CORDRA terms refer to CORDRA as an activity, a concept or an artifact.
Activity: The CORDRA project is the CORDRA activity.
Concept: The CORDRA model is the CORDRA concept. The concept includes, as key elements:
Artifact: There are different CORDRA artifacts. There is no single the CORDRA artifact.
The concepts and the resulting artifacts are related as described.
The CORDRA project covers several major activities.
| Version | ID | Date | Change Summary |
|---|---|---|---|
| 1.00 | H | 20041229 | Initial release |
| 20050101 | Editorial changes |