Modelling MMU programmes and units with Metadata for Learning Opportunities (MLO)

MMU is currently reviewing the information it collects about Programmes and the Units that comprise them with a view to streamlining curriculum design, approval and delivery. The goal is to enter data once and re-use data items where they are needed: for instance, for setting up enrolment possibilities and assessment regimes in the student records system, or advertising courses in the prospectus.

Traditionally, information about Programmes and Units has been collected in Word documents for review through Quality workflows. Recently, templates used for these Word documents have been scrutinised in an institution-wide review of the Programme Approval, Review and Modification (PARM) process. Simplified versions have been developed in consultation with colleagues from Planning and Management Information and the Centre for Quality Assurance and Enhancement.

Whilst naming conventions vary across the institution, simplified versions of the Programme and Unit documentation have been developed based on a five level hierarchy:

  • Programme Specification
    (top level document scrutinised as a whole at a QA event)

    • Award Specification
      (defines the final award titles for a Programme)

      • Course Specification
        (defines the delivery modes for achieving each defined Award)

        • Stage Specification
          (defines the stages that comprise each Course and specifies the Units that comprise each Stage)

          • Unit Specification
            (defines the learning outcomes and assessment regime for a particular unit (or module) of study)

The following information has been identified as important for each level of specification (the column on the right provides a mapping to properties of the Learning Opportunity Specification class in the MLO information model):

Information MLO LOS property
Programme programmeCode dc:identifier
programmeTitle dc:title
programmeDescription dc:description
programmeLearningOutcomes mlo:objective
Award awardCode dc:identifier
finalAward details
(finalAwardTitle and finalAwardBody)
Course courseCode dc:identifier
(if applicable)
(succinct, ideally less than 100 words)
courseSpecificEntryRequirements mlo:prerequisite
(expected all year numbers)
(each start within year must be identified)
(full-time, part-time or sandwich)
(if a collaborative partner is involved)
(normal duration for the mode of study specified for the course)
Stage stageCode dc:identifier
(scheme, level and value of credits for stage completion)
stageLearningOutcomes mlo:objective
(details of any interim award title the awarding body for the stage)
(including unit code, whether it is core or optional and the stage learning outcomes covered)
Unit unitCode dc:identifier
unitTitle dc:title
(an official abbreviation to be used with the unitCode on timetables, VLE announcements, etc)
(to facilitate unit search)
(for statutory returns and to facilitate intelligent recommendation of library resources)
unitLearningOutcomes mlo:objective
unitDescription dc:description
unitSyllabus dc:description
(the department responsible for resourcing the Unit)
unitCoordinator dc:contributor
unitExternalExaminer dc:contributor
(maintained automatically)
(scheme, level and value)
(any units that must be passed in order to enrol on the unit)
(any units that must be taken alongside the unit)
(any units that cannot be taken alongside the unit)
(the element type and weighting and unitLearningOutcomes and graduateOutcomes covered by each item in the assessment regime)
(the code, coordinator, start within the year, mode of study and delivery provider for each unit instance that will run within an academic year)

A diagrammatic representation of this hierarchy of information appears below
Model of entities in MMU's Programme and Unit hierarchy

MMU’s five level hierarchy can be represented using the forthcoming European Norm on Metadata for Learning Opportunities, using draft XML bindings under development to support the imminent release of the EN.

The hierarchy will be implemented using a custom XML schema that references (and refines) tweaked versions of the XML schema documents under development to support the EN:

A working prototype of an XML schema for modelling the MMU hierarchy using MLO-AD is available below:

This schema permits representation as follows:

        <mmu:courseSpecificEntryRequirements />

Proposals for curriculum information forms are currently out for circulation across the university, supported by some web mock-ups:

It is hoped that this prototyping work on a MLO-compliant schema will accelerate development of the final system when requirements are signed-off.

Is it me or is it InfoPath?

I have been exploring the potential of the proposed new European Norm on Metadata for Learning Opportunities (MLO) for modelling proposed changes to curriculum.

The MLO work uses Dublin Core Abstract Model notions of refining properties to sub-class them.

I have been considering the use of Microsoft’s InfoPath for creating forms based on XML schema representations of MLO, which colleagues could use to enter proposed changes to curriculum: for instance, a change to assessment weighting for a particular course unit.

However, I seem to be coming un-stuck when I try to sub-class a property that has been defined using XML wildcards.

Here’s a simplified example of my problem. I have a Parent type that is defined as mixed content, with the xs:any wildcard specifying any element 0 or more times. I have a Child type that refines the parent to be non-mixed content with a single identifier element. InfoPath is able to generate a form for elements of type Child.

<?xml version=”1.0″ encoding=”utf-8″?>
<xs:schema xmlns=”” xmlns:mstns=”” xmlns:xs=”” targetNamespace=”” elementFormDefault=”qualified” >
<xs:complexType name=”Parent” >
<xs:complexContent mixed=”true” >
<xs:restriction base=”xs:anyType” >
<xs:sequence >
<xs:any processContents=”lax” minOccurs=”0″ maxOccurs=”unbounded” />

<xs:complexType name=”Child”>
<xs:complexContent mixed=”false”>
<xs:restriction base=”Parent”>
<xs:element name=”identifier” type=”xs:string”/>

<xs:element name=”root” type=”Child”/>


However, if I specify that the Child node has two elements (for instance, identifier and title), the schema validates but InfoPath cannot generate a form from the schema and returns the error:

Invalid particle derivation by restriction.
Base type : ‘{}Parent’
Derived type : ‘{}Child’

It appears that InfoPath regards the Child type as an invalid restriction of the Parent wildcard.

<xs:complexType name=”Child”>
<xs:complexContent mixed=”false”>
<xs:restriction base=”Parent”>
<xs:element name=”identifier” type=”xs:string”/>
<xs:element name=”title” type=”xs:string”/>

Am I missing something here, or is InfoPath correct in saying that a Child with two specific nodes is not a valid restriction of a Parent with 0 or more nodes?