XCRI CAP 1.2 Extras
From Xcri
This document contains various "bits n pieces" that aren't included in the final specification document
Contents |
[edit] Design Goals and Requirements
This section is non-normative
The design goals and requirements for this specification are documented in the XCRI 1.2 Requirements document.
The specification meets the following requirements as identified in XCRI 1.2 Requirements:
- R1 Conform to the European Norm for Metadata for Learning Opportunities
- See section on MLO Conformance
- R2 Support Online Application Links
- This is implemented using the <applyTo> element
- R3 Support Higher Ambitions
- TBC
- R4 Flexible date handling
- See notes on temporal elements
- R5 Different provider types
- This is implemented using the <type> element
- R6 Link to Ofsted
- This is implemented using the <ofstedUrl> refinement in XCRI Terms 1.2
- R7 Short description for list views
- This is implemented using the <abstract> refinement in XCRI Terms 1.2
- R8 Age range
- This is implemented using the <age> element.
[edit] Implementation Patterns
This section is non-normative
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.
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.
An Aggregator or a broker can then download a number of feeds and collate them to enable cross-searching or other capabilities.
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:
- the feed autodiscovery pattern uses the Link tag in HTML pages on the provider's site
- the reliable feed location pattern uses a convention for deploying XCRI feeds in consistent ways
See also Category:Implementation patterns for more patterns.
[edit] Extensions
This section is non-normative
You can extend XCRI-CAP in a number of ways; check out the Extending XCRI-CAP guidelines.
[edit] Vocabularies
This section is non-normative
Use of the XCRI_Terms_1.2 vocabulary encoding scheme is recommended.
[edit] Changes from V1.1
This section is non-normative
The following changes have been made in v1.2 of XCRI-CAP
- Added Contributor, Date, and Type properties to Catalog, Provider, Course and Presentation
- Replaced Relation with HasPart
- RelationDType redefined as supporting association both by reference and inclusion
- Modified Venue property of a Presentation to contain a Provider instance for the venue Location
- Added Location property to Provider, containing the information previously supplied in OrganisationDType
- Replaced Credit with a very similar model taken from CEN
- Added Objective to XCRI Terms
- Added level to course
- Added engagement to replace studyMode etc
- Removed @recstatus (now a separate spec)
- Removed entryProfile and entryRequirements: now uses Prerequisite, plus parked separate spec for structured entry requirements
- Added age
- Added Abstract to XCRI Terms
- Added url to location
Editor's NoteThis image is now out of date:
The changes are summarised in the following information model:
