K12 Open Content Exchange

I’ve been intending to write about the K12 Open Content Exchange project, and its metadata, but for various reasons haven’t got round to it. As I have just submitted a use case to the DCMI Application Profile Interest Group based on the projects requirements I’ll post that.

The project is being run by Learning Tapestry in the US, I am contracted to build the metadata specification in an iterative fashion based on experiences of content exchange between the partners (currently we are at iteration 1). I want to stress that this isn’t an authoritative description of all the project’s intents and purposes, or even all the metadata requirements, it’s a use case based on them, but I hope it gives a flavour of the work. The requirements section is more relevant if you’re interested in how to specify application profiles than for the OCX spec per se.

Problem statement

We wish to share relatively large amounts of content and curriculum materials relating to educational courses, for example: all the activities, student learning resources, teacher and parent curriculum guides, formative assessments, etc relating to one school-year of study in a subject such as mathematics.

We wish for the metadata to facilitate the editing, adaptation and reuse of the resources. For example teachers should be able to substitute resources/activities provided with other resources addressing the same objective as they see fit. Or course designers should be able pull out all the resources of a particular type (say activity plans), about a given topic, or addressing a specific learning outcome and use them in a new course. In some cases alternate equivalent content may be provided, for example online Vs offline content or to provide accessible provision for people with disabilities.

We wish for these to be discoverable on the open web at both broad and fine levels of granularity, i.e. whole courses and the individual parts should be discoverable via search engines.

We have decided to use the following vocabularies to describe the structure and content of the material: schema.org + LRMI, OERSchema and local extensions where necessary.


  • Original content providers who create and publish curriculum and course materials using existing systems and already have (local) terminology for many aspects of resource description.
  • Content processors take the original content and offer it through their own systems. They also have (different) terminology for many aspects of resource description
  • Content purchasers wish to discover and buy content that meets their requirements
  • Course designers and Teachers use the content that has been purchased and wish to adapt it for their students
  • Parents wish to understand what and how their students are being taught
  • Learners want a seamless experience using high quality materials and ideas, in which all the work above is invisible.


The application profile must reference evolving specifications: schema.org, OERSchema, various controlled vocabularies/concept schemes/encoding schemes and local extensions. If a local extension is adopted by one of the more widely recognised specifications it should be easy to modify the application profile to reflect this.

The application profile must include a content model that meets the following requirements for describing the structure of content:

  • identify the distinct types of entity involved (Course, Unit, Lesson, Supporting Material, Audience, Learning Objectives, Assessments etc)
  • show the hierarchy of the content (i.e. the Course comprises Units, the Units comprise Lessons, the Lessons comprise Activities)
  • show related content that is not part of the hierarchy but is related to (e.g. information about Units for teachers and parents, content to be used in the Activities)
  • show the ordering of sequential content
  • show options for alternative equivalent content

The application profile must specify optional (may), desired (should) and required (must) descriptive metadata as appropriate for each type of entity. For example

  • Activities must have a learning Time
  • an Activity should have a name
  • any resource may be associated with an Audience

The application profile must specify cardinality. for example:

  • Courses must have one and only one title
  • Units must have one or more Lesson
  • Units may have one or more Assessment

There may be alternative ways of satisfying a requirement

  • Courses must associated with either one or more Lesson or one or more Unit
  • If there is more than one Lesson in a Unit or Course, the Lessons must be ordered

The application profile must specify the expected type or value space for any property

  • this may be more restrictive than the base specification
  • this may extent the base specification
  • this may include alternatives (e.g. free text or reference concept from controlled scheme)