The repository is responsible for storing content in Connexions. It has the following functions:

New content publication

When a user publishes a new content object, the repository assigns the object a new objectId unique within the repository and an initial version. When publishing a new content object, users may specify a parent object from which the new content derives (see Derive Copy). In this case, the repository also stores a reference to the objectId and version of the parent content object.

Additional metadata fields

Upon publication, the repository adds the following metadata fields to the content:

objectId

The unique ID string assigned to this object. Different versions of the same object all share the same objectId.

version

The version identifier of this version of the content. The combination of objectId and version must be unique in the repository.

submitter

The name of the person who submitted this version to the repository

submitlog

A description of the changes made to the content by the submitter

Version control

The repository stores the complete history of all published content so that users can access any version, previous or current. Some important features of Connexions repository versioning are:

• the entire content object (including metadata and any associated files or data) is versioned
• each version of a content item is always accessible both internally as a first class object, and externally via a URL
• the version history of an object (who published each version and the "change log") is always accessible
• there is a special method for retrieving the latest version of an object in case a users wishes to obtain the most recent version, regardless of its version number.

Content checkout

The repository allows anyone to checkout a copy of a content item. There is no locking mechanism at the repository level: any number of users may checkout the same content simultaneously. Therefore, to prevent collisions maintainers should communicate with each other before publishing changes.

Publishing new versions

After checking out content, a user may make modifications and publish the revised content object. Publications of revised content objects share the same objectId as the original but each is assigned a new version. To minimize collisions, the repository will only allow publication if the version of the checked-out copy matches the latest published version. This ensures that if other versions have been published since the user performed a checkout, he or she will made aware of them before publishing.

Security and permissions

The repository only allows users with the correct permissions to publish new versions of a content object. These users are referred to as maintainers of that content. Maintainers may or may not be the same users as the authors (see Contributor Roles). Although an object's maintainers may change as new versions are published, only someone listed as a maintainer on the latest published version may publish a new version.

Search

The repository provides a common metadata search (ID, title, author, keywords, and so on) for finding content, as well as full text searching for modules.

Retrieval and display

Each version of a content object has a URI of the form http://cnx.rice.edu/content/<id>/<version>/ where <id> is the unique objectId, and <version> is the version identifier. For example http://cnx.rice.edu/content/m11617/1.2/ identifies version 1.2 of the module m11617. The most recent version of an object is available through a URI of the form http://cnx.rice.edu/content/<id>/latest/. When responding to a URI request, the repository returns a representation of the content appropriate to the object and medium. For a course, it returns the table of contents and course metadata. For a module, it returns the text of the module. Additional links within the content provide access to alternative presentations, for example, a PDF version of the module, or a machine-readable RDF version of a course.

Displaying modules customized for a course

Retrieving a course URI sets a browser cookie for that course. From that moment on (until the cookie expires, is removed, or is replaced), the user (or rather, the user's browser) is in the "context" of that course. In the context of a course, any module included by that course will be displayed with the appropriate customizations such as display options, annotations, and links. Note: the actual module in the repository is not altered, and is accessed via the same URI. It is only the presence of the course cookie that causes the module appearance to be changed.