The XCRI project plan has received JISC Programme approval, and contributions against the first major work package (WP5) have been received from many of the partners. The aim of this work package was to collect views on the suitability for UK need of the Norwegian CDM XML schema.

Useful insight was gained from the contributions themselves, and the difficulty of obtaining them, particularly the challenge of crossing organisational boundaries to collate views about schema coverage from marketing, quality, enrolment and reporting perspectives. This latter point will be particularly important when the project moves to embedding its outcomes in practice.

Without exception, Work Package respondents expressed admiration for the work undertaken by the CDM team. The schema, and its particular attention to the European Credit Transfer Scheme (ECTS) ensured that a home could be found for most information that needed to be stored. Respondents were keen to build on the CDM work and raised a number of problems and suggestions for a closer fit to UK need:

• Several institutions (including the UK's Universities and Colleges Admissions Service) identified a need to distinguish between course Specification and Offering. An Offering is defined in this context as a particular instance of a course or module running at a particular location at a particular time. An approved Specification might have several Offerings. It was noted that modular schemes present particular problems and any XCRI schema would need to be tested against them. Each Offering would <<realize>> the course Specification but would hold specialized information: for instance, the number of places available, relevant open day and interview arrangements, where and when it was offered (which may involve multiple locations) and the typical contact pattern a student could expect if they enrolled.
  It is interesting to note that the eduCourse and Swedish EMIL schemas distinguish between Specification and Offering. Plans to harmonize CDM with EMIL could be usefully informed by this need, which is articulated further below.
• CDM's hard split between Programme and Course didn't suit all institutions: many used different names, others had curriculum objects in-between that needed to be represented (eg Programme hasMany Courses hasMany Stages hasMany Units/Modules). Several contributors suggested that Programme and Course should perhaps be modelled as implementations of a more generic curriculum Specification object.
• Several institutions described how rules for curriculum structure (cores, options, 4 mandatory plus 1 from Set A plus 1 from Set B, etc) were often specified in UK definitive documents and needed for enrolment purposes, but didn't seem to be captured in a way that was amenable to automated processing. It was also noted that rules would be required to alert students to typical pathways: recommendedFollowOn, etc.
• Many respondents suggested that infoBlockType could probably be handled with XHTML
• Varied requirements (mainly for searching and reporting purposes) were expressed for identifying Programmes, Courses, Units or Modules against many different coding schemes. It was apparent that a precise but flexible identifier and typing approach would be needed for the UK, which would work for schemes administered by local institutions and national bodies, such as the QAA, UCAS and HESA.
• One institution raised the problem of versioning Specifications, particularly for courses in transition. For instance, in the same academic year, a two year programme might have its first year following a recently-approved Specification, while its second year was still on the old scheme. A system that provided students with definitive information about the course on which they were enrolled would need to bring up the correct Specification for each year group.
• Two institutions identified their need to express multiple accreditations for different bodies. Details of the accreditation date, and a description and any qualifications upon the accreditation would need to be stored for each body.

These observations can be translated into a set of guidelines for a schema that offers an improved fit to UK need:

1. Separate Offering from Specification so that Offering <<realizes>>Specification
2. Ensure that relations between versions of Specifications and Offerings can be specified
3. Make Specification (and therefore Offering) a generic curriculum object that can be "typed" to become a Programme, Course, Route, Stage, Unit, Module...
4. Provide a flexible mechanism for representing relationships between curriculum objects
5. Provide a flexible mechanism for identifiers and typing statements that works with locally and nationally-administered coding schemes
6. Provide a flexible mechanism for representing multiple accreditations
7. Provide a flexible mechanism for representing fractional relations between the curriculum object and other entities, such as locations, teaching bodies and cost centres

These guidelines formed the basis of some brief email exchanges involving me, Scott Wilson, Sean Mehan and Ben Ryan. Our brainstorming raised the following points:

• If curriculum Specification is separated from Offering, Specification becomes more like standard metadata, amenable to representation using dublin core; whereas Offering is a mix of metadata and calendar/schedule information, some of which could be handled by dc:temporal but more detailed contact patterns and key dates (interviews/open days) were more amenable to something like iCal. Comparison of the CDM Programme and Course elements shows similarity in content (if not always name), which could point towards elements of description that could be included in a generic curriculum object, thus addressing points 1 and 3 above.
• Point 2 could be handled by suitable identifiers for Specification and Offering, and extending the dc:relation element using either a name appropriate to the domain, eg: hasOffering/isOfferingOf, or something more generic: hasInstance/isInstanceOf)
• For implementing guideline 4 we identified two generic types of relation between a curriculum object and its parts:
  

  A list of parts	showing that first year is followed by second year
  A set of parts	showing that >=min and <=max (specified in either a unit count or credits) must be taken from a specified set

• The namespace-qualified typing approach used in qualified dublin core could meet requirement 5 above:
  <dc:identifier xsi:type="ucas:courseCode">G563</identifier>
  <dc:identifier xsi:type="mmu:courseCode">5504</identifier>
  It may even work for approved titles
  <dc:title xsi:type="hesa:finalAward">BA(Hons) Business Studies</dc:title>
  <dc:title xsi:type="hesa:exitAward">Certificate of HE</dc:title>
  Although award titles may need more precise identification and articulation of rules for their selection if award conferment use cases are to be supported (a separate <award> element block may be required).
• Criterion 6 could be handled by 0..* occurences of an accreditation element that specified a relation to the accrediting body, details of the accreditation and date from which it was valid
• Criterion 7 could be handled by a domain-specific extension to the dc:relation element that included an attribute for proportion.

• A two year course (identified by the code 5504)
• The first year (55041) has six compulsory modules (5A1010, 5A1020, ... 5A1060)
• The second year (55042) has four compulsory modules (5A2010..5A2040) plus 1 from Set A (5G2000..5G2003) and 1 from Set B (5J2000...5J2003)

• Specification_v0h.xml
• Offering_v0d.xml