XCRI CAP 1.1

Status

This is currently a working draft of version 1.1.

There is a proposal available for version 1.2.

Patents

This specification is subject to a royalty free patent policy.

There are no known patents covering any of this work. If you think that part of this work may be subject to an existing or pending patent, please email the editors.

This work is (c) 2005-2009 XCRI.org, and licensed under a Creative Commons Attribution 3.0 Licence. All contributions MUST be licensed under the same conditions. This is to ensure that the specification work can be transferred to an appropriate standardisation body.

Inspiration and acknowledgements

Introduction

The XCRI Course Advertising Profile (XCRI-CAP) is a specification to enable the interoperability of descriptions of courses, or any other kind of learning opportunity, between the course provider and any number of aggregators and brokers, by supplying an XML description.

There are two implementation patterns for XCRI-CAP, one following the general model of simple XML syndication (rather like RSS or Atom) called the simple aggregation pattern, and another following the model of metadata harvesting by checking for differences between the current catalog and a previously harvested copy (the delta update pattern). Whichever pattern is used, the XML format used for the course description is largely identical.

An XCRI-CAP document typically consists of a top-level catalog element, encapsulating a single provider, and a collection of course descriptions for the courses offered by the provider. Each course has various descriptive information available such as syllabus, the qualification you can obtain, career options and so on. The course is also divided into any number of presentations, which are the ‘instances’ or ‘offerings’ of the course that a prospective student will apply for, and which have specific start and end dates, locations and so on, and can vary in aspects such as the location and mode of study (e.g. a full-time and part-time presentation, with different duration and end date).

Design Goals

XCRI-CAP is being designed with the following goals in mind. XCRI-CAP should:

  • Be simple to implement by providers using existing course databases and publishing systems or as a single static XML file
  • Be simple to implement by aggregators using existing metadata harvesting and syndication techniques
  • Be capable of being parsed by widely used XML parsing modules in a range of languages, including PHP, Java, Ruby, C#
  • Enable the development of added-value services using aggregated data as a starting point
  • Reduce the amount of data transformation and re-keying needed to advertise courses
  • Provide immediate and identifiable benefits for both provider and aggregators/brokers
  • Support a wide range of potential business models

Basic Concepts

The basic mode of operation for XCRI is for organisations to create a feed of course information, consisting of an XML document that contains their provider details, including the courses they offer. Each of these objects (or resources as we call them) is described using a number of properties.

An aggregator or a broker can then download a number of feeds and collate them to enable cross-searching or other capabilities.

Image:Model.png

Implementation Patterns

XCRI-CAP supports two main implementation patterns:

  • In the simple aggregation pattern, each provider offers its feed as an XML file that can be periodically downloaded by an aggregator. The aggregator replaces any previous information about the provider and their courses with the latest data.
  • the delta update pattern follows the same pattern as the Open Archives Protocol for Metadata Harvesting (OAI-PMH). In this pattern, each provider offers an API where aggregators can obtain an XML catalog file containing information about changes since a specified date.

For aggregators, there are also patterns for discovering XCRI feeds:

See also Category:Implementation patterns for more patterns.

Format

XCRI Documents

An XCRI-CAP XML document MUST have one of the following resources as its root element:

In general any provider SHOULD use Catalog as the root element. (Note that the “Catalog” element is just a container for the information - it doesn’t imply a relationshop between the feed and a real course catalog)

The specification allows both Provider and Course as alternative root elements to enable REST-style operations to be provided by aggregators (much in the same way that the IETF Atom specification enables both feed and entry elements to be document roots).

Information Model

Click the image to see a schematic of the XCRI-CAP v1.1 information model.

Namespace

XCRI-CAP elements and attributes are identified using the namespace:

Resources

A resource is something that can be uniquely identified [1]{.external .autonumber}. In XCRI, we identify resources using a Uniform Resource Identifier (URI). A resource can possess a number of properties, which may be simple value-strings or can be structured.

XCRI-CAP specifies the following resource classes:

Properties

Properties contain information about resources. While many of the properties of the resources defined by XCRI-CAP are simple values such as strings and dates, properties can also be structured objects. Typically in an implementation structured properties become resources in their own right, however as they are not addressed directly from outside the implementation they are usually not given universal identifiers.

View a complete index of properties defined within the XCRI-CAP namespace.

Vocabularies

Use of the XCRI_Terms_1.1 vocabulary encoding scheme is recommended.

Inheritable property values

Some elements may be inferred from their presence in a containing resource when not present in child objects. Specifically:

  1. Where a presentation does not contain a venue, an Aggregator SHOULD assume that the venue details (name, address, email, fax, phone, url, image) are exactly the same as the properties of the provider. An Aggregator MAY assume that the description is the same as that of the provider.
  2. Where a course does not contain an image, but its containing provider does, an Aggregator MAY use the image of the provider when displaying the course.
  3. Where a presentation does not contain an applyTo property, or a qualification does not contain an awardedBy and/or accreditedBy property, an aggregator SHOULD interpret this as meaning the capability is provided by the provider and use its contact information.

This enables XCRI documents to be less verbose by not repeating basic information.

Extensions

You can extend XCRI-CAP in a number of ways; check out the Extending XCRI-CAP guidelines.

XML Binding

The following schemas are available:

Examples

Similar work

The following have a similar scope:

The following have inspired the specification approach: