Curriculum Schema Consultation
The first six months of the JISC-funded XCRI project involved document analysis, interviews and site visits to collate requirements for an XML schema that could express curriculum content in a way that fulfilled the quality assurance, marketing, reporting, pathways, portfolio and enrolment needs of UK HEIs and FECs. In close collaboration with the JISC-funded Pathways4Progression regional pilot project and with reference to the Norwegian CDM and a number of other reference standards, a set of candidate elements was identified. The emerging set of elements was then validated against a survey of 161 UK HE and FE prospectus web sites to ensure suitable coverage and category discrimination.
Based on this work, Mark Stubbs (Manchester Metropolitan University) and Ben Ryan (Kainao.com) have drafted a curriculum xml schema for consultation and are collating feedback from interested parties.
Consulation Documents
The following documents are released under a Creative Commons Attribution-ShareAlike 2.0: England and Wales Deed for consultation based on the XCRI research:
| Consultation draft E-Framework Curriculum schema (efc.xsd) | Download | |
| Sample XML document for Adam Smith College course spec (fife.xml) | Download | Background |
| Sample XML document for CDM comparison (cdm.xml) | Download | Background |
| Sample XML document for Liverpool Learning Matrix course spec (learningmatrix.xml) | Download | Background |
| Sample XML document for London Met unit spec (londonmet.xml) | Download | Background |
| Sample XML document for Nottingham Trent programme spec (ntu.xml) | Download | Background |
Download a zipped folder containing the v0d consultation schema and sample xml documents.
Feedback
Feedback from partners is currently being gathered by completing this spreadsheet and emailing to m.stubbs@mmu.ac.uk.
All comments received on the v0d schema are collated below:
| ID | SUMMARY | DESCRIPTION | PROPOSAL | TYPE | AUTHOR | DATE | RESPONSE |
| 1 | Method for coded items | There are many coded / classified items and a generic code element. Current design permits codes in raw form only, which may make the XML less transparent for the human reader without easy access to the coding system. Could we carry (optionally) the code and the description? | Code and matching description elements for coded / classified items. Consider introduction of classificationType complexType (see snippet). | Design | Alan Paull | 07/10/2005 | |
| 2 | qualifiedType | Used for levels of awards and credits. The name itself looks ambiguous (is it a Type that is Qualified?), when it actually deals with Qualifications. | Change name to qualificationType. | Name change | Alan Paull | 07/10/2005 | |
| 3 | designType attribute mixed="true" | SimpleLiteral already has mixed="true", so this may be unnecessary | Remove mixed="true" from designType. | Attribute | Alan Paull | 07/10/2005 | |
| 4 | designType and some other documentation elements unclear | Documentation says 'Extends the base dc:SimpleLiteral to allow for mixed content', which is unnecessary. Also it refers to extension particularly for XHTML, when in fact it only permits XHTML (and the additional attributes). | Review all documentation elements. NOTE: this is not meant as a 'heavy' criticism, just a reminder that we need to do it! | Other | Alan Paull | 07/10/2005 | |
| 5 | calendarType / event / detailType | Possible confusion between this sub-element and the complexType called detailType. | Change name of calendarType / event / detailType sub-element to description. | Name change | Alan Paull | 07/10/2005 | |
| 6 | Does event element need both detailType sub-element and Type attribute? | These two items seem to perform the same function. | Question | Alan Paull | 07/10/2005 | ||
| 7 | identifierType permits a URI only | Local identifiers may need to be more general than URI type. | Suggest introduce a string element as an additional choice to anyURI for identifierType. | Design | Alan Paull | 07/10/2005 | |
| 8 | label attribute in identifierType | What does label attribute in identifierType do? I presume it allows for a more human readable name for the identifier. | Question | Alan Paull | 07/10/2005 | ||
| 9 | admissionType extension | Currently has no extension. | Needs extension in similar way to assessmentType | Structure | Alan Paull | 07/10/2005 | |
| 10 | Similarity between accreditingBody and awardingBody | It is possible that some users may be confused by the terms accreditingBody and awardingBody. | It may be useful to define what we mean by these in the schema. | Other | Alan Paull | 07/10/2005 | |
| 11 | awardingBody element limited to 1 occurrence | awardingBody element is currently limited to 1 occurrence, but there are a v few courses that have more than one. | Make awardingBody attribute maxOccurs="unbounded" or a small number (could be 3?) | Attribute | Alan Paull | 07/10/2005 | |
| 12 | owningBody name | Users may not understand the term owningBody. | Suggest change owningBody to provider (currently a standard term used in Using Learning Information standards etc for organisations providing learning). | Name change | Alan Paull | 07/10/2005 | |
| 13 | How does standardsBody differ from accreditingBody? | How does standardsBody differ from accreditingBody? May be confusion if we have both terms. | Suggest change standardsBody to accreditingBody and change the element in component to a ref. | Design | Alan Paull | 07/10/2005 | |
| 14 | hasPart has redundant information | hasPart is part of the component to component relationship. As such the data should be normalised, such that hasPart contains only items relating to the relationship. | Remove level and credit elements from hasPart; already included in award element, which is part of component. | Design | Alan Paull | 07/10/2005 | Use-case: default level and credit values can be over-ridden when a component is included in a particular programme |
| 15 | modeOfAttendance / modeOfDelivery names | Possible confusion between these two elements. | Suggest change name of modeOfAttendance to StudyMode (which is the name used in the learndirect standards); and change modeOfDelivery to DeliveryPattern, to avoid two uses of 'mode'. | Name change | Alan Paull | 07/10/2005 | |
| 16 | teachingLocation details | Needs extension in accordance with MIAP work on locations (once that's been fully determined) or learndirect venues or some other off-the-shelf standard. | Further investigation needed. | Structure | Alan Paull | 07/10/2005 | |
| 17 | contactPattern positioning | Currently part of offeringOverview, but does not link with modeOfAttendance element. (also see next comment) | Might more usefully be an optional sub-element of modeOfAttendance? | Design | Alan Paull | 07/10/2005 | |
| 18 | modeOfAttendance positioning | Currently at same level as offeringOverview as a part of offeringPattern; might more logically be part of offeringOverview. | Move to sub-element of offeringOverview. | Design | Alan Paull | 07/10/2005 | |
| 19 | effort element name | It is not obvious from the name of the effort element what it means. Is it hours of study or something else? | Suggest change name of effort element to studyHours if that is appropriate. | Question | Alan Paull | 07/10/2005 | |
| 20 | duration element could have more explicit structure | There is an existing vocabulary in the learndirect standards for classifying durations. | Suggest extend the duration element to include provision for a vocabulary. | Design | Alan Paull | 07/10/2005 | |
| 21 | detailType could include code and term sub-elements as standard. | As detailType is a fundamental building block, and many of the information items could have codes or classification vocabs, is it worth extending detailType to include optional code and term pairings to handle vocabs? | See snippet. | Question | Alan Paull | 07/10/2005 | |
| 22 | curriculumElementType position within schema | Currently not with other complexType bits. | Move the text to the other complexType bits (ie top of schema). | Other | Alan Paull | 07/10/2005 | |
| 23 | proportionType in languages | This aspect seems overly complicated. Do we need it? | Question | Alan Paull | 07/10/2005 | ||
| 24 | Conflict between prerequisite and admission element | I think we need to choose whether prerequisite goes with admission element or where it is now. Otherwise we risk having a redundant element. I suspect our problem here is not defining the admission element adequately. In data analysis terms I feel more inclined to have prerequisite with corequisite and any follow-on components, rather than with admission. I think that we are differentiating here between elements that express the relationship (or articulation) between academic components and administrative arrangements for admission. | More discussion needed. | Question | Alan Paull | 07/10/2005 | |
| 25 | Follow-on components not included yet | We have prerequisite and corequisite, but no follow-on components. Could we have them? | Introduce new followon element. Not sure this is the right name however. | Question | Alan Paull | 07/10/2005 | |
| 26 | organization element versus curriculum components | I am not sure that organization can be equated with curriculum components. It may need its own elements, because it appears to be a conceptually different thing. Especially when we get into awarding bodies, accrediting bodies, providers and venues. | Question | Alan Paull | 07/10/2005 | ||
| 27 | Naming of offeringOverview | Confusion between offeringOverview and overview elements. | Suggest change offeringOverview element name to offeringDetail (as in Mark's diagram) | Name change | Alan Paull | 07/10/2005 | |
| 28 | Different structures for offeringOverview and component details | offeringOverview is a catch-all element for the details of an offering. The component element does't have such a catch-all element, which seems inconsistent. | I would go with offeringDetail and componentDetail elements. | Structure | Alan Paull | 07/10/2005 | |
| 29 | classificationType, ref: Alan Paull:1 | Our Student Records ask about including a subject taxonomy to a component or subject, such as LearnDirect's http://www.nln.ac.uk/resource/nlnxml.xml. | I didn't see the snippet referred to in the original comment. I'd imagine that it would involve something like attributes for taxonomy scheme name, location (URL) and taxon code, in a dc:subject element containing taxon name (potentially some of these could be resolved via remote look-up). Is this what is already proposed? | Question | Tavis Reddick | 06/12/2005 | |
| 30 | component/dc:title | For our planning system, Student Records have broken down our existing title into components which should map on to awardingBody, awardTitle, awardLevel plus a 'Subject Area' with optional, prefixing 'Supplementary Information'. However, for our main information system, all of these components are to be concatenated for the course title. What is the advice for component[@type=course|program|module]/dc:title? | I'm not sure from the documentation what should be the format of a course title, so perhaps this could be expanded upon? I'd imagine that this is the publishable title, and therefore could be confusing if aggregated from multiple organizations in different formats. Alternatively, extend the title element to allow refs to other element content to build up complete title? | Question | Tavis Reddick | 06/12/2005 | |
| 31 | Extending the XHTML sections. | XHTML sections are useful for publishing and editing descriptive sections. However, sometimes useful content could be held within these sections (like a job description within career, which could be read by a search designed to match courses with intended career options). | Like 29 above, a job sector taxonomy could be used, possibly in connection with HRXML. However, I do not know if this is feasible, or possibly it could cause problems with XHTML editors which can't manage compound document formats. | Structure | Tavis Reddick | 06/12/2005 | |
| 32 | awardLevel | Student Records and Marketing have reasons to want to store a numeric value as well as a label for awardLevel, such as having a natural sort order. | As in 29 and 31, a taxonomy and code in addition to a label would help. Instead of <efc:awardLevel>SCQF LEVEL 5</efc:awardLevel> we might prefer <efc:awardLevel taxonomy="SCQF" url="http://some_url" level="5">SCQF Level 5</efc:awardLevel> | Design | Tavis Reddick | 06/12/2005 | |
| 33 | Sort orders and aggregation | In terms of the components of an XCRI curriculum being reorderable and selectable by group, what is the position on sort orders and aggregation generally? | See 32 for sorting on awardLevel. | Question | Tavis Reddick | 06/12/2005 | |
| 34 | Native format versus exchange format | If XCRI is purely seen as an exchange format, produced or published on demand from another information system, the parent system can hold administrative and quality information. However, even then, you might want to compare versions, or check the last update time of a particular component. If XCRI was seen as a native format, then it might require more document management data containers. | A datetime attribute could be used for some kind of versioning, or perhaps this is what dc:date is for? | Question | Tavis Reddick | 06/12/2005 | |
| 35 | Marketing department comments | Our Marketing people seem quite happy with the format, as long as there are user-friendly labels and descriptive fields for courses, sort orders are possible, and XCRI can populate website, print prospectus, course pamphlets and external aggregators like LearnDirect. | Other | Tavis Reddick | 06/12/2005 | ||
| 36 | Quality department comments | I can't really speak for Quality, but their representative didn't seem too sold on the concept of interoperability and sector consensus. | Possibly a specific case needs to be made to quality departments, addressing their concerns. | Other | Tavis Reddick | 06/12/2005 | |
| 37 | Student Records department comments | Student Records seemed quite enthusiastic about checking out the basic datatypes for course description and matching them to our developing systems. | As a result of realizing the flexibility required to match course information to various external formats, a more atomized relational database approach was favoured which closely matches a portion of the proposed XCRI schema. However, they reckon that our information system (SITS) is not flexible enough to store data in a structure that can be exported to XCRI. Talks with information system vendors might lead to some kind of support and accreditation, I guess. Ideally, some kind of native XML storage, like in SQL Server 2005, which I think SITS plan to support, would help. | Other | Tavis Reddick | 06/12/2005 | |
| 38 | award | Modelling of award should be aware of other schemas that attempt to capture qualification details | See for instance <qcl> in IMS LIP and <qualification> in HR-XML. This will be particularly important if achievement is going to correlated electronically with course entry requirements to see which pathways are open to a learner | Structure | Berlin Ref Models Seminar | 30/11/2005 | |
| 39 | associating curriculum fragments | Quality assurance documentation often requires one curriculum fragment (eg assessment item) to be asociated with another (eg the learning outcome it addresses) | A flexible mechanism should be considered for associating fragments of curriculum content. | Structure | Airport departure lounge discussion with Ben Ryan | 30/11/2005 | |
| 40 | merging spec and offering data | Whilst spec and offering can be usefully distinguished conceptually, use-cases such as populating an aggregated course catalogue require data from each to be brought together | Mechanisms for doing this should be considered in the revised schema | Structure | Selwyn Lloyd | 05/12/2005 |
