CORDRA: Content Object Repository Discovery and Registration/Resolution Architecture

The Appropriate Version Problem:
Separating Learning Designs and Course Structures from Learning Object Versions, Variants and Copies

Daniel R. Rehak
Learning Systems Architecture Lab
Carnegie Mellon University
Web: http://cordra.net/
Email: cordra@cordra.net

Document Information

Status: Draft
Version: V1.00.20050205
Revision Date: 2005-02-05

Abstract

Current models for representing learning structures, learning designs, resource collections or aggregations and course structures, e.g., IMS Content Packaging, focus on specifying particular learning objects or learning resources, often a specific copy or instance of the resource. The designer or author of the learning experience may not need to specify a particular instance of a resource and may want the learner to experience the most recent version or edition of the content. In other cases, the designer may be indifferent to how the material is represented, e.g., which file format is presented to the learner. Hardwiring the link to a particular version of a resource is counter to these needs.

This report outlines requirements for representing and specifying content versions and variants in learning design and course representations. Adapting the FRBR model (Functional Requirements for Bibliographic References), it presents a model used to represent content versions. The model's focus is on how to specify the appropriate resource in the content description so that a learning delivery system can select, locate and deliver an appropriate instance of the learning resource to the learner. While the initial model described herein is targeted a structured content representations and content delivery, it is equally appliable to content versions maintained within repositories and digital libraries.

Introduction
- Problem Motivation: Auxiliary Resources in SCORM
- Problem Motivation: Beyond Auxiliary Resources
Representing Versions and Variants
Specification of Versions and Variants
Delivering the Appropriate Version
Linking to Content Packaging and a Content Delivery Process
- Resource Syntax
- Authoring and Delivery Process
Miscellaneous Discussion Points
References
Complete Model

Our work on the versioning problem was motivated in part by the need to provide support for representing versioned scaffold content in learning designs, particularly via the auxiliary resource feature of SCORM. After describing the problem from this view, the discussion will be expanded and generalized to cover other types of content within a learning experience.

Problem Motivation: Auxiliary Resources in SCORM

Learning content often includes supporting materials or scaffolding content -- content that is not part of the main delivery thread in the learning experience but is used ad hoc by the learner. Scaffold and support content includes items such as manuals, glossaries, references, job aids, IETMs (Interactive Electronic Technical Manuals), data files, maps, etc.

In current practice, this scaffold content is authored independently of the main learning content: it may exist in many different versions, variants (e.g., language variants, platform-specific variants), and may be stored and managed separately from the core learning content of the course.

Content Association and Versioning Problems: Basic support for scaffold content is included in SCORM 2004, via auxiliary resources included in Simple Sequencing. The auxiliary resource feature of Simple Sequencing provides a way to associate scaffold content with the main delivery thread, simply specifying the identifiers or locators for the scaffold content associated with each part of the course.

Since the auxiliary resources may change independently of the core learning materials (e.g., a new version of a manual might be produced), there is a need to uncouple the versioning of the auxiliary resources from that of the learning content. It should not be necessary to update the learning content whenever an auxiliary resource changes, i.e., to produce a new content package describing the entire course that differs only through the incorporation of the newer version of the support materials.

Since the learning content may be dependent on a particular version of an auxiliary resource, the content designer needs to be able to specify which versions and variants of an auxiliary resource are appropriate, and which versions are inappropriate.

Similarly, different versions of the same resource may exist for different audiences or different needs, such as accessibility. It should not be necessary to replicate the entire content collection for different uses just because each use references a different version of a resource. However, a detailed discussion of personalization is beyond the scope of this discussion.

Repositories and the Appropriate Copy Problem: Auxiliary resource content may reside in existing repositories and digital libraries, separately from the main learning content. The same version of the content may be stored in multiple repositories.

Just as versions should not be hardwired into a course design, locations should not be hardwired to a particular repository. It should not be necessary to update the overall course structure if resource content moves from one repository to another. Likewise, content delivery should not fail if a content repository is unavailable when there are other sources of the content. Resource content should be delivered from the most appropriate source (e.g., using the closest server, load balancing among different sources). A learning technology system should not be constrained to access content from only one repository.

While much of the repository and appropriate copy problem can be addressed by describing content by name rather than by location and using a resolution service to map the names to the locations, these considerations impact the total solution being described herein and are thus included in the discussion.

Problem Motivation: Beyond Auxiliary Resources

While this work was triggered by the need to handle auxiliary resources, there same need applies to any type of content, learning object or learning resource within a course or learning design. There may be different versions of content, different forms, and different copies in multiple locations. The learning experience designer should be able to specify the learning objects and resources used in the learning experience without specifying a particular instance of the resource with a content structure or packaging representation, or without specifying a specific copy in a particular repository. Furthermore, the designer needs to be able to specify the appropriate version of the content, i.e., when it is acceptable to use any version of a resource versus when only a particular version or copy is required.

Thus, the concise problem statement follows.

How to specify the appropriate version of a learning object.
- What is a general model for representing versions and copies of learning objects.
- How to describe the specification of the appropriate version so that a content delivery process may select, locate and deliver the appropriate content to the learner.
- How to embed an encoded specification for the versioned learning object into a content structure such as a content package.
How a delivery system should resolve the specification of a version of a learning object to a specific object copy for delivery to the learner.

Note, we assume we are dealing with intentionally-created collections of learning materials. We further assume that the developer or designer of the learning experience has selected the appropriate versions of learning resources for inclusion. Thus, we are not dealing with a problem of search or discovery, but only one of identifying and locating the appropriate instance.

Representing Versions and Variants

The model used to represent learning object and resource versions and variants is adapted from the FRBR model (Functional Requirements for Bibliographic Records). FRBR identifies four different representations for a resource (our notation loosely follows the FRBR relation notation).

w: designation for a work -- the conceptual learning resource or learning object.
e: designation of an expression -- a realization of a work (w:)
m: designation of a manifestation -- an embodiment of an expression (e:)
i: designation of an instance -- a copy or instance of a manifestation (m:)

Versions and Variants in FRBR

A work is a conceptual item, e.g., a particular learning resource. (We will use the term resource or learning resource interchangeably throughout the remainder). There may be multiple different expressions of a work, e.g., editions, versions, translations. Manifestations are different forms or formats of the identical expression or version of a work, e.g., different file formats that are the identical content and only differ in presentation. This document uses the terms version and variant generically for expressions or manifestations of a work, for each of which there may be multiple instances or copies.

In our model, any change in a work is a new expression (e:X) of the work (w:X). Thus each different version (v:X₁, v:X₂) is a different expression (e:X₁, e:X₂). However, there are no hard and fast rules about what is a work versus what is an expression of the work. Much of the FRBR-like classification of a resource is dependent upon its original classification, e.g., different versions (v:X₁, v:X₂) could be treated as different works (w:X₁, w:X₂) rather than different expressions (e:X₁, e:X₂) of the work (w:X).

While the model permits such different initial classifications, there is no mechanism to unify the treatment of actual resources which are inconsistently classified. More importantly, differing initial classifications do not impact how the model is applied or structured.

Relationships are typically between the different representations, i.e., a work (w:) is realized through an expressions (e:). While works (and other representations) are generally independent, there may be work-to-work (w:w) relations, e.g., w:x.abstract is an abstract of w:X, w:x.annex.a is an annex to w:X.

Details of the model follow in separate sections. A combined semantic model of the various relationships follows in the appendix to this document.

Labels for parts of the model appear in lowercase bold, and include a colon (:).
Labels for resources or content elements appear in bold and italics. Generic resource names (placeholders) are in uppercase.
Names of relations appear in italics.
Attributes associated with an element of a model are represented by a slash (/) separating the attribute name from the name of the part of the model.

w: designation of a work or resource
e: designation of an expression of a resource
m: designation of a manifestation of a resource
i: designation of an instance of a resource
v: designation of a version or variant of a resource, specifically a different edition, issue, version number, etc.
l: designation of the language of the resource
f: designation of the technical format of the resource
a: designation of the accessibility form of the resource
r: designation of a repository
p: designation of a part of a resource
id: designation of an identifier of a resource
X designation of a placeholder name for a resource, it may be the work w:, expression e:, manifestation m: or instance i:.
N designation of a placeholder name for a version v:, e.g., v:N.
Y designation of a placeholder name for a technical format f:, e.g., f:Y.
Z designation of a placeholder name for an accessibility form a:, e.g., a:Z.
Q designation of a placeholder name for a repository r:, e.g., r:Q.
H designation of a placeholder name for an identifier id:, e.g., id:H.
Multiple occurrences of a resource X are denoted with subscripts, e.g., X_i, X_j.
Designated subparts of a resource are denoted by dotted names, e.g., X.part_i.subpart_j.

The following is a simple example illustrating the key concepts of the model. The full model notation is not used in this simple illustration.

This document, as a general concept, The Appropriate Version Problem, is an example of a work (w:The Appropriate Version Problem).
The document has gone through several iterations and versions during its development, each of these being different expressions (e.g., version 0.30 as e:0.30 or version 1.0 as e:1.00).
Some of these expressions appear in multiple file formats, each of these being different manifestations (e.g., the xhtml file m:xhtml or the PDF file m:pdf).
Finally, there may be different copies or instances of the file (e.g., the file on the production web server i:http://lsal.org/filename, the file on the local file server i:http://localhost/filename, or the file in the web browser cache).

Note, the relationship between works, expressions, manifestations and instances are represented via the relationships between the items, not in the names themselves, e.g., the name m:xhtml does not tell you that it is a manifestation of the named expression e:1.00.

Resource Relations

Relations Between Different Entities. The relationships between works, expressions, manifestations and instances follow.

Work-to-Expression Relations
- is realized through, e.g., w:X is realized through e:X
- is realization of, e.g., e:X is realization of w:X
Expression-to-Manifestation Relations
- is embodied in, e.g., e:X is embodied in m:X
- is embodiment of, e.g., m:X is embodiment of e:X
Manifestation-to-Instance Relations
- is instantiated by, e.g., m:X is instantiated by i:X
- is instance of (is copy of) , e.g., i:X is instance of m:X

Relations Among Entities of the Same Type. We do not model any particular relationships between entities of the same type, e.g., work-to-work or instance-to-instance relationships, except for the whole-part relations described below.

Whole-Part Relations. The relationships between parts of a resource and its whole follow.

is part of
has part

These relationships can be applied to any type of resource, e.g.,

w:X.p_i is part of w:X
w:X has part w:X.p_j
e:X.p_i is part of e:X
e:X has part e:X.p_j
m:X.p_i is part of m:X
m:X has part m:X.p_j
i:X.p_i is part of i:X
i:X has part i:X.p_j

For example, the whole-part relationship can be used to express the composition of a web page and its embedded images. An instance (copy) of a learning resource, e.g., an instance (copy) of an image, is a part of the entire instance (copy) of the web page.

Modeling Versioned Learning Resources

In modeling learning objects and resources, the appropriate version is described by five key attributes of the object. These are:

The version (v:), i.e., the edition of the learning resource (edition name, version number, issue number, release number, report number, etc).
The language of the resource (l:).
The technical format of the resource (f:).
The accessibility form of the resource, e.g., is it designed for reading, for viewing, for listening (a:).
The storage location of the resource (r:).

These are represented in our adaptation of FRBR through the representations of the works, expressions, manifestations and instances. While there may be other attributes that describe versioned resources, these five form a key initial set of attributes used to describe versions and copies, and appear to meet the initial requirements for modeling learning experiences so that the creator of the learning experience need not specify only a particular instance of a resource in the description of the learning experience.

As noted below, the model could be extended to include additional selection criteria or attributes such as those listed. In particular, selection of the appropriate version based on rights management is excluded from the model. As described, the model is targeted at designed learning experiences (not for discovered learning). Thus, we assume that the learning experience designer has selected appropriate resources considering issues such as rights, costs, etc., and specification of the desired manifestation or expression of the content is independent of any rights associated with the content. If there are different rights associated with different instances, rights-based selection could be included in the processing of selecting an appropriate repository for the selected instance of the resource, once that instance has been determined from the other selection criteria.

In the generic model, there is no particular representation of languages, forms, formats, etc. Specific representations will be introduced as part of the detailed specification of these attributes of resources.

There are no special characteristics or attributes of works in the model. Each work (w:) has an identifier (w:/id:). The relationship between a work (w:) and its expressions (e:) must be represented through the relations in the model.

Modeling Expressions

Versions or variants of a resource are modeled as different expressions (e:X) of a work (w:X). Each expression (e:) has an identifier (e:/id:).

Versions or variants include translations of expressions of the work into different languages (l:). Versions or variants include the specification of the version or edition, e.g., the issue, version number, edition number, etc (v:N). The model does not define what is a version (v:N), only that changes in the expression of a work that are not language translations are different versions of the work, while expressions in different languages are generically different versions or variants. We recognize the problem of using the term version generically and as a part of the formal notation for the model.

The model treats the version identification and the language of the expression as attributes of the expression. A resource may have both a version attribute (v:) and a language attribute (l:). For consistency in identifying the appropriate learning resource, a default language (l:) and version (v:) attribute must be associated with each expression (e:) of the learning resource.

Expression Attributes

While each different version (v:) and different translation or language representation (l:) of a learning resource is a different expression (e:) of the work (w:), the model expresses the work-to-expression relation and the expression attributes separately.

Version identification attribute relation
- is version of, e.g., e:X/v:N is version of e:X
- has version, e.g., e:X has version e:X/v:N
Language (translation) identification attribute relation
- is translation of, e.g., e:X/l:fr is translation of e:X
- is language of, e.g., e:X/l:fr is language of e:X
- has translation, e.g., e:X has translation e:X/l:fr
- has language, e.g., e:X has language e:X/l:fr

Note, these appear to be expression-to-expression relations. The actual model is one of attributes associated with the expression, not relations between expressions.

Composite attributes are permitted, e.g., e:X has version e:X/v:N has language e:X/v:N/l:fr

Modeling Manifestations

Forms and formats of a resource are modeled as different manifestations (m:X) of an expression (e:X). Each manifestation (m:) has an identifier (m:/id:).

Forms or format may be technical formats, e.g., file formats or data representations (f:) or may be different manifestations for accessibility and use of the content, e.g., formatted for readability, for listening (a:). Thus we differentiate between the technical format and access format of the learning resource.

The model treats the form and format identification of the manifestation as attributes of the manifestation. A resource may have both a technical format (f:) and an accessibility form (a:). For consistency in identifying the appropriate learning resource, a default format (f:) and form (a:) attribute must be associated with each manifestation (m:) of the learning resource.

Note, the technical format attribute (f:) is designed to explicitly represent data formats, independent of resource content or rendering. The accessibility form attribute (a:) may be used to represent any different rendering, use or accessibility form of the resource. While called the accessibility form, the attribute is not limited to describing accessibility, but should not be used to describe different technical encodings of similar representations of an expression, such as file formats.

Manifestation Attributes

While each different technical format (f:) and different accessibility form (a:) of a learning resource is a different manifestation (m:) of the work (e:), the model expresses the expression-to-manifestation relation and the manifestation attributes separately.

Technical format identification attribute relation
- is format of, e.g., m:X/f:Y is format of m:X
- has format, e.g., m:X has format m:X/f:Y
Accessibility form identification attribute relation
- is form of, e.g., m:X/a:Z is form of m:X
- has form, e.g., m:X has form m:X/a:Z

Note, these appear to be manifestation-to-manifestation relations. The actual model is one of attributes associated with the manifestation, not as relations between manifestations.

Composite attributes are permitted, e.g., m:X has form m:X/a:Z has format m:X/a:Z/f:Y

Modeling Instances

There are no special characteristics or attributes of instances or copies in the model. Each instance (i:) has an identifier (i:/id:). Instances (copies) of a resource are modeled as a different instance (i:X) of a manifestation (m:X).

As noted below, identifiers are names, and each has associated attributes. Thus, the locator for the instance can be determined from the identifier. Locator information may include the designation of the repository (r:) where the instance is stored.

Modeling Repositories

There is no explicit representation of repositories (r:) in the model. Repositories are associated with instance (i:) location data.

As noted above, resources described at any level -- work (w:), expression (e:), manifestation (m:) or instance -- (i), have an identifier (id:). These are persistent, actionable names, e.g., Handles, DOIs. We assume that there is a resolution process in place that will take an identifier and return the associated resolution data, i.e., the data associated with the identifier maintained by the resolution system.

The identifier attribute relations follow.

w:X has identifier w:X/id:H
e:X has identifier e:X/id:H
m:X has identifier m:X/id:H
i:X has identifier i:X/id:H

We assume that all identifiers are opaque and include no observable semantics. Given an identifier, you cannot tell if it is for a work (w:), expression (e:), manifestation (m:), instance (i:), metadata (md:), etc. The designation of the type of content is associated with the identifier as an attribute of the identifier, or in the metadata associated with the object.

There may be cases where it could be beneficial to create a composite identifier, e.g., (w:/id:H_i/e:/id:H_j/m:/id:H_k/i:/id:H_l). Such identifier concatenation is for processing, not representation of resources within the model, e.g., encoding the relations describing resource attributes into a single URL.

The model associates metadata with works (w:), expressions (e:), manifestations (m:) and instances (i:).

The metadata attribute relations follow.

w:X has metadata w:X/md:MD
e:X has metadata e:X/md:MD
m:X has metadata m:X/md:MD
i:X has metadata i:X/md:MD

The model does not define a particular set of metadata or metadata schema that is associated with a resource. Nor does the model define where in the model specific metadata attributes are assigned to resources, e.g., are they assigned to works or instances). From a structural and semantic view, metadata is no different than other content or learning resource, e.g., it has generic forms akin to a work, is versioned, and may exist in multiple locations. It should be obvious that the model described herein could be (recursively) applied to the metadata associated with a resource. The details of such an approach are not included in this presentation, and are left to implementations.

Resolution and Relations between Entities

While not a core part of the model, but essential for implementations, a resolution process for identifiers (in particular, multiple resolution) is used to implement the relations between entities, e.g., to implement a work-to-expression relation or the manifestation-to-instance relation.

For a work (w:X), resolution of the identifier (w:X/id:) returns both the metadata (md:) about the work and the collection of expressions (e:X) of the work, each identified by the identifier of the expression (e:X/id:H). Resolution returns the identifier for the metadata (md:) of the work (w:X/md:/id:), which is again resolved to obtain the actual metadata.

For an expression (e:X), resolution of the identifier (e:X/id:) returns both the metadata (md:) about the expression and the collection of manifestations (m:X) of the expression, each identified by the identifier of the manifestation (m:X/id:H). Resolution returns the identifier for the metadata (md:) of the expression (e:X/md:/id:), which is again resolved to obtain the actual metadata.

For a manifestation (m:X), resolution of the identifier (m:X/id:) returns both the metadata (md:) about the manifestation and the collection of instances (i:X) of the manifestation, each identified by the identifier of the instance (i:X/id:H). Resolution returns the identifier for the metadata (md:) of the manifestation (m:X/md:/id:), which is again resolved to obtain the actual metadata.

For an instance (i:X), resolution of the ID (i:X/id:) returns both the locator for the learning content and metadata describing the content. Resolution returns the identifier of the metadata (md:) of the instance (i:X/md:/id:), which is again resolved to obtain the actual metadata.

Note, this model does not imply use of any particular technology to implement resolution. While the model is consistent with technologies such as the Handle System, other implementation approaches may be used.

Extended Example

Assume you have

a resource (X)
with multiple versions (including version N)
that is in a particular language (French)
expressed in a format (PDF), and
stored in repository (Q)

In the model notation, this becomes:

i:X/r:Q is instance of
     m:X/f:PDF is format of
         m:X is embodiment of
             e:X/v:N/l:fr is translation of
                 e:X/v:N is version of
                     e:X is a realization of
                         w:X

The following attributes are available

w:X has identifier w:X/id:
e:X has identifier e:X/id:
m:X has identifier m:X/id:
i:X has identifier i:X/id:
w:X has metadata w:X/md:
e:X has metadata e:X/md:
m:X has metadata m:X/md:
i:X has metadata i:X/md:
e:X has version e:X/v:
e:X has language e:X/l:
m:X has format m:X/f:
m:X has form m:X/a:
i:X is in repository i:X/r:

Alternatively, just using identifiers and not names, this becomes:

i:/id:H₁/r:Q is instance of
     m:/id:H₂/f:PDF is format of
         m:/id:H₃ is embodiment of
             e:/id:H₄/v:N/l:fr is translation of
                 e:/idH₅/v:N is version of
                     e:/idH₆ is a realization of
                         w:/idH₇

It should be apparent that if you can determine the type of resource from its identifier (e.g., is it a work or instance), then all that is needed to describe a resource is the identifier of the resource and its attributes.

The model consists of the following key elements and assumptions

Learning resources can be modeled as works (w:), expressions (e:), manifestations (m:) and instances (i:).
Each part of the model includes an identifier (id:) and metadata (md:) for each item.
Version (v:) and language (l:) are attributes of an expression (e:).
Format (f:) and form (a:) are attributes of a manifestation (m:).
Whole/part relationships can be applied anywhere.
The generic versioning problem can be captured (for now) by just the version (v:) and language (l:) of an expression (e:) and the format (f:) and form (a:) of a manifestation (m:). We explicitly exclude versions of manifestations and formats of expressions.

Specification of Versions and Variants

Given a versioned resource and the model described above, the resource is described by seven attributes.

An identifier (id:) for the resource (it maybe for the w:, e:, m: or i:).
The specification of the version of the resource (e:/v:).
The specification of the language of the resource (e:/l:).
The specification of the format (technical) of the resource (m:/f:).
The specification of the form (accessibility) of the resource (m:/a:).
The specification of specific source repositories for the resource (i:/r:).
The specification of a part of the resource (p:).

Note, we do not explicitly specify the metadata for the resource as one of the attributes that the developer will specify.

We assume that the instructional designer or content developer will specify acceptable values for some or all of these as part of designating the resource to be used in delivering the learning experience. When specifying the desired resource, i.e., the appropriate version, all of the attributes except the identifier (id:) are optional. The next sections outline how the content developer may want to specify the different acceptable values for these attributes.

If necessary, the model could be extended to include additional attributes and additional selection criteria similar to those described here.

Specifying a Version

The content designer may want to specify the desired version (v:) in any of the following ways.

A single, specific, named version of the resource, specified by the actual version name (v:name).
A special, named version of the resource, e.g., the first, latest (v:latest, v:first).
An arbitrary (implementation-defined) selection of the resource from the available versions, specified by the special named version any (v:any).
A version from an unordered set of named versions. We use the notation in to designate an enumerated, unordered set (v:in(name_i, name_j, name_k)) and between to designate the set of all items inclusive through the upper and lower version numbers in the set (v:between(4,7)).
An excluded version. We use the notation not for exclusion (v:not(name)).
A preferred ordering of the versions. We use the notation preferred to designate an ordered set, most preferred first (v:preferred(name_k, name_i)).

If the content designer does not specify a version, an implementation may specify an appropriate default version (v:) for selection, e.g., latest.

In selecting the resource to deliver to the learner, the version information for the learning resource is taken from the version attribute for the metadata (md:) associated with the resource.

Specifying a Language

The content designer may want to specify the desired language (l:) in any of the following ways.

A single, specific, named language of the resource, specified by the actual language designator (l:lang).
An arbitrary (implementation-defined) selection of the resource from the available languages, specified by the special named language any (l:any).
A language from an unordered set of named languages. We use the notation in to designate an enumerated, unordered set (l:in(lang_i, lang_j, lang_k)).
An excluded language. We use the notation not for exclusion (l:not(lang)).
A preferred ordering of the languages. We use the notation preferred to designate an ordered set, most preferred first (l:preferred(lang_k, lang_i)).

If the content designer does not specify a language, an implementation may specify an appropriate default language (l:) for selection, e.g., en-US.

In selecting the resource to deliver to the learner, the language information for the learning resource is taken from the language attribute for the metadata (md:) associated with the resource.

Specifying a Format

The content designer may want to specify the desired technical format (f:) in any of the following ways.

A single, specific, named format of the resource, specified by the actual format designator (f:Y).
An arbitrary (implementation-defined) selection of the resource from the available formats, specified by the special named format any (f:any).
A format from an unordered set of named formats. We use the notation in to designate an enumerated, unordered set (f:in(Y_i, Y_j, Y_k)).
An excluded format. We use the notation not for exclusion (f:not(Y)).
A preferred ordering of the formats. We use the notation preferred to designate an ordered set, most preferred first (f:preferred(Y_k, Y_i)).

If the content designer does not specify a format, an implementation may specify an appropriate default format (f:) for selection, e.g., any.

In selecting the resource to deliver to the learner, the format information for the learning resource is taken from the format attribute for the metadata (md:) associated with the resource.

Specifying a Form

The content designer may want to specify the desired accessibility form (a:) in any of the following ways.

A single, specific, named form of the resource, specified by the actual form designator (a:Z).
An arbitrary (implementation-defined) selection of the resource from the available forms, specified by the special named form any (a:any).
A form from an unordered set of named forms. We use the notation in to designate an enumerated, unordered set (a:in(Z_i, Z_j, Z_k)).
An excluded form. We use the notation not for exclusion (a:not(Z)).
A preferred ordering of the forms. We use the notation preferred to designate an ordered set, most preferred first (a:preferred(Z_k, Z_i)).

If the content designer does not specify a form, an implementation may specify an appropriate default form (a:) for selection, e.g., any.

In selecting the resource to deliver to the learner, the form information for the learning resource is taken from the accessibility attribute for the metadata (md:) associated with the resource.

Specifying a Repository

The content designer may want to specify the desired repository (r:) in any of the following ways.

A single, specific, named repository source for the resource, specified by the actual repository name (r:Q).
An arbitrary (implementation-defined) selection of the resource from the available repositories, specified by the special named repository any (r:any).
A repository from an unordered set of named repositories. We use the notation in to designate an enumerated, unordered set (r:in(Q_i, Q_j, Q_k)).
An excluded repository. We use the notation not for exclusion (r:not(Q)).
A preferred ordering of the repositories. We use the notation preferred to designate an ordered set, most preferred first (r:preferred(Q_k, Q_i)).

If the content designer does not specify a repository, an implementation may specify an appropriate default repository (r:) for selection, e.g., any.

In selecting the resource to deliver to the learner, the repository source for the learning resource is taken from data used to register the content in a repository.

For each of the attributes (v:, l:, f:, a:, r:), the selection process needs to obtain a value of the attribute, in an appropriate form (value space), for the learning resource. While the model does not dictate a particular source or value space, values could be taken from the metadata associated with the learning resource.

The version attribute (v:) aligns with the version attribute in metadata, e.g., the LOM schema item Version (2.1). The value of version could be numeric (with implicit ordering), or a string.
The language attribute (l:) aligns with the language attribute in metadata, e.g., the LOM schema item Language (1.3). The value of language could be represented using the ISO 639 language codes and subcodes, encoded as a character string value.
The technical format attribute (f:) aligns with the format attribute in metadata, e.g., the LOM schema item Format (4.1). The value of format could be represented as the mime-type of the file (RFC 2048), encoded as a character string value.
The accessibility form attribute (f:) aligns with form metadata, and IMS ACCMD specification may provide an appropriate value space and encoding. The value space for form should be a vocabulary of possible rendering of a resource.
The repository name attribute (r:) is a name (possibly an identifier), encoded as a character string value.

Version Specification Attribute Syntax

The discussion above lists the different ways that a content developer may wish to specify version attributes to indicate the appropriate version of a resource. It does not represent a real, concrete syntax for specifications that can be embedded in other forms, such as within URLs or within attributes of a structural representation like a content package.

A real syntax for any of the version attributes will require additional features.

Nesting of expressions, e.g., not(in(a,b,c)).
Boolean operators, e.g., and, or.
Comparison operators, e.g., >, <.
A pattern match facility, e.g., regular expressions for named values. This is important since there are no agreed upon representations for version names, repository names, etc.

With the exception of the range selector between for versions (v:), the other forms of specifications (e.g., specific or special named values, order, not ordered) are the same for all selection attributes. Thus it should be feasible to develop a general syntax to encompass all cases.

In addition to specifying a syntax, an implementation will have to deal with and process the different representations and value spaces for the different attribute values (e.g., string or pattern matching, enumerated or open vocabularies). It will also need to obtain the attribute values from the resource metadata. Such implementation details are beyond the scope of this document.

Version Specification Attribute Examples

The notation

v:preferred(latest > 12 in(between(5:10), 3))

specifies that the latest version of the resource is preferred if the value of the version attribute is > 12; otherwise it is any of the versions of the resource than has a version attribute value of 5, 6, 7, 8, 9, 10; otherwise it is the version of the resource that has a value of the version attribute of 3. Thus, versions 1, 2, 11 and 12 are always excluded from selection.

Delivering the Appropriate Version

Given the specification of the version attributes for a learning resource, the appropriate version must be selected from those available that match the specification and the selected version of the resource is then delivered to the learner. The operational model is based in part on FRBR.

FRBR Operations

The FRBR model defines four key operators.

find -- search to obtain the set of objects (or object identifiers) that match specified search criteria.
identify -- match a set of characteristics to those of a single object.
select -- get item from a search results set that matches a particular set of needs.
obtain -- get an object once the identifier of the instance is known.

In our model, the search operator does not apply during content delivery. As noted, we assume that the learning experience designer or content developer will have identified an appropriate versioned collection of learning resources and will have directly specified the selection attributes of the appropriate version(s) from the set.

The identify operator also does not apply, as we already know that an object meets the criteria. We do not need to determine the attributes of a specific resource.

Thus, getting the appropriate version is an example of the FRBR select and obtain operators. Given the selection criteria, select returns an identifier of the resource to be delivered to the learner. Final repository access and identifier resolution are part of obtain. Given the identifier, obtain the locator of the content instance for delivery to the learner.

This model may be implemented in two ways. The selection process may return either the identifier of the manifestation (m:/id) or the identifier of the instance (i:/id). The repository resolution and obtain process may perform the final mapping from manifestation to instances if this task is delegated to the repository system. In the description below, we assume that the selection process returns only the identifier for the manifestation of the resource (m:/id).

Select Operator

The select operator converts an identifier for a resource and a set of selection criteria specifying the desired version of a resource into an identifier for a manifestation of the resource, independent of where the resource is stored.

Selecting the appropriate version of the resource begins with an identifier (id:) for the resource (X) and the specification of the selection attributes (v:N, l:L, f:Y, a:Z). If selection attributes are not specified, appropriate implementation-defined defaults are used.

The process flows through a series of steps until an identifier used in final repository access is found, or the process determines that no resources meet the selection criteria.

Determine the type of resource from the identifier. It is either a work (w:X), expression (e:X), manifestation (m:X), or instance (i:X). Different approaches may be used to associate the type with the resource, as a kind of metadata.
- The information may be in the metadata for the resource (md:).
- The identifier may be registered, with the registration data including the type of resource. Access to the type is through the data associated with the identifier.
If you have an identifier for a work (w:X/id:)
- Obtain the set of identifiers for the expressions of the work (e:X/id:).
- Obtain the version (v:) and language (l:) attributes for each of the different expressions of the work from the metadata for each expression (e:X/md:).
- Using the version (v:N) and language (l:L) attributes from the selection criteria, determine the identifier for the single most appropriate expression (e:X/id:) of the resource.
- The result of this part of the process will be an identifier for a single expression (e:X/id:) that is used in the next step in the process (e:X).
If you have an identifier for an expression (e:X/id:) (either from the original selection or as a result of the last step)
- Obtain the set of identifiers for the manifestations of the expression (m:X/id:).
- Obtain the format (f:) and form (a:) attributes for each of the different manifestations of the expression from the metadata for each manifestation (m:X/md:).
- Using the format (v:Y) and form (a:Z) attributes from the selection criteria, determine the identifier for the single most appropriate manifestation (m:X/id:) of the resource.
- The result of this part of the process will be an identifier for a single manifestation (m:X/id:) that is used in the next step in the process (m:X).
If you have an identifier for a manifestation (m:X/id:) (either from the original selection or as a result of the last step), exit the process returning this identifier (m:X/id:) that will be used to find the appropriate copy of the resource for delivery.
Otherwise, return a failure indicating that there are no manifestations that meet the selection criteria. Such a failure to select the appropriate version of the content may be propagated back to the learner.

Note, the process does not specify any of the details, such as how to obtain the expressions or manifestations of the work, how to match the selection criteria against the list of potential candidates, how to obtain metadata, use of identifier resolution, etc. Different implementations may choose different methods and approaches to realize the overall process.

Also note, the process is defined so that it may start with an identifier to either a work (w:), expression (e:), manifestation (m:) or instance (i:). Furthermore, if starting with a manifestation identifier (m:/id), then the version (v:) and language (l:) selection attributes are ignored. The process could be refined to verify that attributes of the selected manifestation of the resource satisfy these selection criteria.

Obtain Operator

The obtain operator converts an identifier for a manifestation for a resource, i.e., the appropriate version, into a locator for a particular instance of the resource, i.e., the appropriate copy, that is delivered to the learner.

Identifying the location for the resource begins with an identifier for the manifestation of the resource (m:X/id:) or the identifier for an instance of the resource (i:X/id:) and a specification of specific repositories that are potential candidate sources for the resource (r:Q). Note, if no repository criteria are given, any repository may be used.

Determine the type of resource from the identifier. It is either a work (w:X), expression (e:X), manifestation (m:X), or instance (i:X).
If the identifier is not for a manifestation (m:X) or an instance (i:X), exit the process (invoke the select process).
If you have an identifier for a manifestation (m:X/id:)
- Obtain the set of identifiers for the instances of the work (i:X/id:).
- Determine the repository source (r:) for each of the different instances of the manifestation.
- Using the repository (r:Q) attribute from the selection criteria, determine the identifier for the single most appropriate instance (i:X/id:) of the resource.
- The result of this part of the process will be a single instance id (i:X/id:) that is used in the next step in the process (i:X).
If you have an identifier for an instance (i:X/id:) (either from the original selection or as a result of the last step), resolve the identifier to obtain the locator for the resource.
If the selection criteria for the version include a part (p:), this is passed through to the final identifier resolution process to locate the part of the resource instead of the whole.

As noted, the process does not specify any of the details, such as how to obtain the instances of the work, how to match the selection criteria against the list of potential candidates, use of identifier resolution, etc. Different implementations may choose different methods and approaches to realize the overall process.

As described, the final result of the process is a locator for the resource. However, the final step could return an identifier (depending on what location data was stored with the instance (i:X/id:)). Returning an identifier permits additional resolution steps to be used to extend the process.

Implementing Relations and Resolution

As noted, while not a core part of the model, the representations of the relations between entities, e.g., the work-to-expression relation or the manifestation-to-instance relation, are critical to making the model work. There are several possible ways to implement these relations and the resolution of obtaining the resources related to another resource, e.g., the manifestations (m:) of an expression (e:).

For each element in the model, it is necessary to represent the different related elements, e.g., the expressions of a work, the manifestations of an expression and the instances of a manifestation.

If each of the items have an identifier like a Handle that supports multiple resolution (returning multiple results as part of the resolution process), then the related parts of the resource could be associated with the resource. For example, assign an identifier that is a handle to a work (w:X/id:H). After registering the identifier for the work, register all of the expressions of the work (e:X) with the work (w:X). Applying the (multiple) resolution process to the work (w:X) will return the expressions (e:X). The process can be implemented through the registration of the identifiers of the expressions with the work (e:X/id:).

This solution requires use of a resolution system like the Handle System. Note that while the Handle system is designed to support multiple resolution, the available implementations do not support this feature.

An alternative is to represent the related items via the metadata for a resource. For example, use the relations metadata attribute for a work (w:X) to store the identifiers of the expressions of the work (e:X/id:).

While this approach does not require a resolution system like the Handle system, it requires the use of relation attributes in the metadata. It also requires a level of indirection, i.e., going from the identifier of a resource, to the identifier of its metadata, and finally to the metadata record to obtain the identifiers of the related resource versions.

Another alternative is to create a custom relational structure, i.e., resolving the identifier for an item returns the locator for a record structure that contains the information about the related resource versions. This is essentially the development of multiple resolution outside of an existing resolution system like the Handle System.

All of these solutions require that the relations be explicitly modeled and stored. For example, if the information about the manifestations (m:X) of an expression (e:X) are not obtainable via resolution for the identifier of the expression (e:X/id:) or via the data or metadata associated with the expression (e:X), it will not be possible to find the manifestations (m:X) of the expression (e:X). Thus, we assume that the set of relations will be explicitly created and maintained, as opposed to searching over the items to try to discover the relations.

Establishing policies to insure that the set of relations are appropriately updated, e.g., instances, manifestations or expressions are added to the relation set when they are created, is out of scope. The model and processes assume valid data. How to create and maintain the data is an operational issue.

While we reject the use of search to find related versions of a resource as part of the delivery process (primarily due to performance constraints), the set could be built or maintained by asynchronous search and discovery processes.

Linking to Content Packaging and a Content Delivery Process

To be useful, the specification of the desired resource must be embedded with content structure representation, such as content packaging. The identifier in the content package could be for the work (w:X), expression (e:X), manifestation (m:X) or instance (i:X). The process described above can be used to obtain the appropriate version.

The specification of the desired appropriate version of a resource could be applied to learning content, supporting resources, auxiliary resources, etc. The model is applicable to all types of content and resources within a content package.

Full details of how to modify a representation such as content package are outside of the scope of this document. But in terms of an overall process, the developer of a learning experience will need to fully specify the appropriate versions for resources in a structure like a content package.

Resource Syntax

A full specification for a resource will include seven parts, identifying the resource and the specification of the appropriate version to be delivered to the learner.

An identifier (id:) for the resource, e.g., a Handle or DOI for the resource.
The selection criteria for the desired version (v:).
The selection criteria for the desired language (l:).
The selection criteria for the desired technical format (f:).
The selection criteria for the desired accessibility form (a:).
The selection criteria for the desired source repositories (r:).
The specification of the desired part of the resource (p:).

These attributes could be expressed in a query format, and URL encoded into content URLs. Using Handles as identifiers (noting that Handles are not a URL scheme), some examples are shown below (the examples are not URL encoded).

hdl:1870/123?version=3&lang=en.US&format=mime:application/pdf

hdl:1870/124?version=latest&format=mime:application/msword

hdl:1870/125?repository=local

In the select process described above, the type of resource was determined from the metadata associated with the resource identifier. This type (e.g., work, expression), could be added to a URL expression for the appropriate version.

hdl:1870/124?type=work&version=latest&format=mime:application/msword

hdl:1870/126?type=instance

Since the form, syntax and semantics of the resource selection criteria may vary over time (e.g., if new selection attributes are defined), a complete syntax should include some indication of version of selection criteria expression used in the URL.

hdl:1870/127?resourcespecversion=1.0&lang=(preferred(en-*,es,it,any) and not(jp))

Authoring and Delivery Process

Given the model, operators, sample syntax, etc., we can now describe how the approach is used to solve the appropriate version problem to deliver versioned resources to the learner, uncoupling specifications of which version from content structure representations.

Content Authoring
- In creating the learning experience, for each resource used in the design, the designer determines which appropriate version(s) of the resource may be delivered to the learner.
- A content structure representation, such as a content package, is created the contains expressions describing the selection attributes for the appropriate version of each resource in the learning experience. This content structure representation drives the delivery process: resources are selected from it to be delivered to the learner.
Content Delivery
- When the delivery environment identifies a resource to deliver to the learner, the appropriate version of that resource is determined.
- Using the select and obtain operators, determine the actual version of the resource to deliver.
  - Using the select operator, determine the identifier of the actual version of the resource to deliver to the learner.
  - Using the obtain operator, resolve the identifier for the appropriate version to obtain a locator for the appropriate copy, i.e., the appropriate instance of the resource.
- Deliver the identified instance of the resource to the learner.

The resulting content representation no longer hard wires references to specific content or repository instances into the course structure. These are replaced by selection criteria. The addition of the select and obtain operators along with repository resolution are used to convert the selection criteria into the appropriate resource instances.

Updating the set of expressions, manifestations or instances of a resource can be done independently of maintaining the content representation for the learning experience. Updating the relations is all that is needed for the delivery environment to be able to select from a changing set of potentially appropriate resource versions.

Miscellaneous Discussion Points

Version Specification Attribute Syntax. MODs and Z39.50 web services may provide an alternative syntax that can be used to specify version selection attributes. CQL may also be an appropriate query language.

Using Open URL and the Appropriate Copy Problem. Appropriate copy representations such as Open URL could be used for instance identifiers. The instance identifier (i:X) could be any form of identifier, including Open URL. Additional resolution of such an identifier is outside of the scope of this discussion. We note, however, that the query in Open URL in oriented toward more complex matching against metadata and appears to better align with a search operator rather than with a select operator. Again, the emphasis for the model described assumes that appropriate content has been identified by the learning experience designer and the objective it to obtain only the appropriate version for the content.

Also, the appropriate copy problem is not directly applicable as typically described (obtaining the right copy once you know there are multiple instances of the resource). We assume that repositories and repository services manage copies and instances directly.

Comparison to CCPP. Approaches such as W3C's CCPP attempt to solve a similar problem at the form (a:) level. CCPP is a much more detailed specification of device characteristics. Our goal is to present a model that focuses on the content and learner needs, not on the underlying device representations.

Comparison to HTTP Content Negotiation. We have not investigated HTTP content negotiation as an alternative or complementary model. The overall model described is one of selection, not negotiation.

Representation of the Version Attribute. As noted, there is no standard representation of the value space for version (v:). This makes pattern matching and numeric comparison difficult because there is no known representation. In particular, there is no simple solution to know that a particular version is the latest.

It may be possible to use the relation attribute in metadata to represent ordered sequences of objects, e.g., superseds, is superseded by. Using the approach could also require additional search across the metadata records.

Alternatively, since the metadata record may contain multiple version attributes, an additional version attribute value that is in a known representation could be added to the metadata record. These values could be serialized.

Without using metadata, an alternative is to add an attribute to the is expression of relation between the work (w:) and its expressions (e:) that represents the serialization of the version values.

No conclusions as to how to address the problem are put forth.

Extending the Model. If necessary, additional specification attributes could be added to any part of the model. It should be straightforward to extend the set of attributes used to describe versions and variants, the syntax to specify the additional attributes, and the selection process within the select and obtain operators.

FRBR: http://www.ifla.org/VII/s13/frbr/frbr.pdf
appropriate copy: http://www.dlib.org/dlib/july99/caplan/07caplan.html
openurl: http://library.caltech.edu/openurl/Standard.htm
mods: http://www.loc.gov/standards/mods/
zing (Z39.50 query): http://www.loc.gov/z3950/agency/zing/
SCORM
IMS Content Packaging
LOM
Handle
DOI
MIME RFC
ISO Langs
W3C CCPP

All of the elements of the model from the entire document are combined in the following.

Notation
- Labels for parts of the model appear in lowercase bold, and include a colon (:).
- Labels for resources or content elements appear in bold and italics. Generic resource names (placeholders) are in uppercase.
- Names of relations appear in italics.
- Attributes associated with an element of a model are represented by a slash (/) separating the attribute name from the name of the part of the model.
Model Elements
- w: designation for a work -- the conceptual learning resource.
- e: designation of an expression -- a realization of a work (w:)
- m: designation of a manifestation -- an embodiment of an expression (e:)
- i: designation of an instance -- a copy or instance of a manifestation (m:)
- v: designation of a version or variant of a resource, specifically a different edition, issue, version number, etc.
- l: designation of the language of the resource
- f: designation of the technical format of the resource
- a: designation of the accessibility form of the resource
- r: designation of a repository
- p: designation of a part of a resource
- id: designation of an identifier of a resource
- X designation of a placeholder name for a resource, it may be the work w:, expression e:, manifestation m: or instance i:.
- N designation of a placeholder name for a version v:, e.g., v:N.
- Y designation of a placeholder name for a technical format f:, e.g., f:Y.
- Z designation of a placeholder name for an accessibility form a:, e.g., a:Z.
- Q designation of a placeholder name for a repository r:, e.g., r:Q.
- H designation of a placeholder name for an identifier id:, e.g., id:H.
- Multiple occurrences of a resource X are denoted with subscripts, e.g., X_i, X_j.
- Designated subparts of a resource are denoted by dotted names, e.g., X.part_i.subpart_j.
Resource Relations
- Work-to-Expression Relations
  - is realized through, e.g., w:X is realized through e:X
  - is realization of, e.g., e:X is realization of w:X
- Expression-to-Manifestation Relations
  - is embodied in, e.g., e:X is embodied in m:X
  - is embodiment of, e.g., m:X is embodiment of e:X
- Manifestation-to-Instance Relations
  - is instantiated by, e.g., m:X is instantiated by i:X
  - is instance of (is copy of) , e.g., i:X is instance of m:X
- Whole-Part Relations
  - is part of
  - has part
  - w:X.p_i is part of w:X
  - w:X has part w:X.p_j
  - e:X.p_i is part of e:X
  - e:X has part e:X.p_j
  - m:X.p_i is part of m:X
  - m:X has part m:X.p_j
  - i:X.p_i is part of i:X
  - i:X has part i:X.p_j
Expression Attributes
- Version identification attribute relation
  - is version of, e.g., e:X/v:N is version of e:X
  - has version, e.g., e:X has version e:X/v:N
- Language (translation) identification attribute relation
  - is translation of, e.g., e:X/l:fr is translation of e:X
  - is language of, e.g., e:X/l:fr is language of e:X
  - has translation, e.g., e:X has translation e:X/l:fr
  - has language, e.g., e:X has language e:X/l:fr
Manifestation Attributes
- Technical format identification attribute relation
  - is format of, e.g., m:X/f:Y is format of m:X
  - has format, e.g., m:X has format m:X/f:Y
- Accessibility form identification attribute relation
  - is form of, e.g., m:X/a:Z is form of m:X
  - has form, e.g., m:X has form m:X/a:Z
Identifiers
- w:X has identifier w:X/id:H
- e:X has identifier e:X/id:H
- m:X has identifier m:X/id:H
- i:X has identifier i:X/id:H
Metadata
- w:X has metadata w:X/md:MD
- e:X has metadata e:X/md:MD
- m:X has metadata m:X/md:MD
- i:X has metadata i:X/md:MD

Version	ID	Date	Change Summary
1.00	H	20041009	Initial release
1.00	H	20050205	Editorial changes