This Internet2 Draft will expire on October 26, 2004.

This document is an individual submission to the courseID WG of the Internet2 Middleware Initiative. Comments should be sent to the mace-courseID@internet2.edu mailing list.

Abstract

For many educational purposes, it would be advantageous for a course offering to have a single, globally unique identifier. Example scenarios illustrating this point can be found at the MACE CourseID WG web site. This document is a draft proposal for both the syntax of such a single globally unique identifier as well as ideas on how to administer and manage the assignment of such identifiers. The resolution of such identifiers is out of scope for this draft. Even without automated resolution services, such identifiers, when paired with services like those provided by the MACE Shibboleth project, could support controlled inter-institutional access to course offerings. The utility of the proposed approach will be illustrated through detailed walk-throughs of selected e-learning scenarios.

1. Context and assumptions

Context

This proposal is intended to work within relevant existing standards, in particular, within the IMS Enterprise Specification.

Assumptions

This proposal assumes the course-related data model developed by the CourseID WG. Since the proposal is primarily concerned with controlling access to on-line e-learning materials, the entity to which an identifier needs to be assigned is a particular instance of a course offered during a specified time interval. For a traditional face-to-face course, this time interval may correspond to an academic term, while for asynchronous course offerings, it may correspond to something as specific as the beginning and ending dates between which a particular student works through the course materials The CourseID WG data model terms this instance a "course offering." I.e., this proposal is about assigning, managing and using single, globally unique identifiers for course offerings.

Version 1.1 of the IMS Enterprise Specification explicitly states that it focuses on systems within the same enterprise or organization. This means that course offerings that span two or more institutions are not directly supported by that specification. Yet there is a pressing need to address such inter-institutional e-learning applications. If a course offering is given only a locally unique identifier, there is the possibility that, by chance, any single course identifier, when taken at the inter-institutional level, may refer to two or even more distinct course offerings at different institutions, leading to an ambiguity of reference.

A second problem may arise when course offering identifiers are aggregated across institutions. If multiple globally unique identifiers are assigned to a single course offering by different institutions, then aggregations of such identifiers may well contain duplicate references to a single course offering. This is a problem for the aggregator in that there is no easy way to detect or flag the extent of duplicates in a combined listing from multiple sources. This draft proposes mechanisms that lead to the assignment of a specific single globally unique identifier to a given course offering.

Some arbitrary decisions have been made in the following in the interest of proposing a solution complete in all details. Other equally valid choices could be made on many of these points. This proposal is offered as one workable solution.

Over time the CourseID Working Group may develop specifications for many aspects of the course domain. Course offering identifiers should thus be given their own sub-arc under the courseID arc. The full prefix for course offering identifiers would thus be: "courseid:offering:"

Institutions or consortia opting to assign global identifiers to course offerings in alignment with this proposal would first register as institutional namespace authorities under the urn:mace namespace. Institutions are encouraged to register under their dns name (e.g. uchicago.edu) and then to assign institutionally unique identifiers to each course offering under a "courseid:offering" arc, e.g., urn:mace:uchicago.edu:courseid:offering:. The unique identifier assigned by an authority should refer to a concrete offering of a course down to and including a specific section if that is necessary to uniquely distinguish that offering from others (e.g., urn:mace:uchicago.edu:courseid:offering:Physics-101:7D60E22A3:section-01). This document does not recommend any particular syntax for the portion of the identifier that follows "courseid:offering." Possibilities range from a unique serial number to a human-readable string. See the "Usage Notes" section below for some comments on the issues involved in choosing a syntax for the unique part of course offering identifiers.

If a course is being offered by two or more institutions in a consortium, they may wish to avoid "branding" the course with one of their dns names. In such a case, they could propose a different namespace authority identifier. The MACE namespace authority would be responsible for preventing the assignment of the same namespace authority identifier to two different requesters. For example, if an institution in New Jersey and one in Scotland were jointly developing a course in marketing communications under a project called "Thistle," they could apply to MACE to register "thistle." If that name is not already assigned and the registration is approved, they could then assign the course-offering identifier under that namespace (e.g., urn:mace:thistle:courseid:offering:mc300-section-01).

To sum up, locally unique course offering identifiers are made globally unique by combining a registered namespace authority identifier (e.g. urn:mace:uchicago.edu or urn:mace:thistle) with the string ":courseid:offering:" followed by an identifier for a course offering that is unique within that registered namespace.

It would also be beneficial if a particular course offering is given a single primary such identifier. A logically straightforward approach would be for the education community to agree on a single authoritative registration agency that would be responsible for registering and guaranteeing uniqueness, persistence and resolvability of such single primary course offering identifiers. The CourseID Working Group is not an appropriate body to take up such a role. The following proposal can be considered a stop-gap measure that could establish single primary course offering identifiers in the absence of a single registration agency. The proposal's effectiveness depends entirely on voluntary compliance by all members of the community with a simple "rule of practice." The IMS Enterprise specifications support for multiple values of "sourcedid" make it possible to assign different local identifiers if needed. All aggregators of course offering identifiers would have to agree 1) to carry at most one value for sourcedid where the prefix includes "primid" just before the unique courseid offering identifier, e.g., "urn:mace:foo.bar:courseid:offering:primid:," and 2) if they find an identifier value of the form "urn:mace:foo.bar:courseid:offering:primid" for any course offering resource, they carry that sourcedid pair over unchanged regardless of any other source-identifier pairs that they might assign or delete.

The application of this identifier scheme can be illustrated by reference to the scenarios defined on the MACE-CourseID site. The first scenario submitted was for dynamic provisioning of a user into a course management system (CMS). If the wording of the scenario is altered so that every occurrence of "course" is replaced by "course offering," this current draft specification for unique identifiers for course offerings would meet all the requirements of the scenario. The key is that the user's origin site would assert an entitlement (perhaps via eduPersonEntitlement) using the course offering identifier. Other information needed by the target to properly provision for a new user would be a unique identifier for the person and an assertion of that person's role with respect to the given course offering. The specification of those elements is outside the scope of the present draft.

The second and third scenarios are detailed subtypes of the initial scenario. The second is a case where the TEACH act requires the institution to limit access to covered materials to registrants in a particular course instance. The course offering identifier specified in this draft provides the necessary level of granularity to support the required access control decisions. The third scenario elaborates a case that is sketched above in the example of two institutions offering a collaborative course. If both participating institutions follow the first scenario scheme of asserting entitlement to the collaborative course offering via an agreed-upon single course offering identifier, the various requirements of the scenario can be met. Note that where the scenario refers to a "CourseID," it should be understood to refer to a course offering identifier as defined in this present draft.

A fourth scenario describes an informal co-taught course offered by two collaborating instructors at UCLA and Berkeley. Each institution has a formal course to which this co-taught offering corresponds. In this case, the primary utility of a shared course offering identifier is to pass assertions of entitlement to access course site materials from the external origin site to the target hosting the course site. The course offering identifier, established by informal agreement between the two participating instructors, then becomes the key to the ability to appropriately ask for and grant access to the course site.

---

4. Usage notes

Some identifier schemes are meant primarily for use by humans, and the values may give some hint of the semantic base object being identified. For example, NetIDs often carry some component of the associated holders name, thus suggesting that whatever is being identified is associated with that individual. At the other extreme are UUIDs as originally defined in the Distributed Computing Environment (DCE) model from IBM. UUIDs are 128 bit numbers assigned to persistent objects. They have no semantic content in and of themselves, but are simply globally unique numeric identifiers that may be bound to objects of any type. They are intended primarily for application to application use. When they occur in documents, they are often represented as 32-digit hexadecimal numbers that virtually defy human handling.

The course offering identifiers proposed here may be somewhat closer to NetIDs than UUIDs. Certainly the namespace identifier prefix presents itself as something meaningful to the human reader. A first encounter with the prefix "urn:mace:courseid:offering:rutgers.edu" might lead someone to form a rough and ready notion of what is being identified by the remainder of the string. The MACE CourseID Working Group believes it is too early to prescribe the style of the remainder of the course offering identifier string. Some institutions may prefer humanly-readable forms reminiscent of entries in a timetable of course offerings for a given term. Others may opt for a more opaque string. But in both cases, it is critical to realize that a course offering will have a rich set of associated metadata. The identifier can point to that metadata, it can never substitute for it. Meaningful inter institutional sharing of course materials will require agreement on the syntax and semantics of such metadata. That work is outside the scope of this proposal.