OER 2 Technical Requirements

Following the experiences of projects funded under the HEFCE / Academy / JISC Open Educational Resources Pilot Programme CETIS have made some minor revisions to the technical guidelines for the current OER 2 Programme. These guidelines reiterate and hopefully clarify the guidelines provided in the Programme Circular and presented at the Programme Start Up Meeting.

Resource Description

As with the OER Pilot Programme, the OER 2 Programme will not mandate the use of one single platform to disseminate resources and one single metadata application profile to describe content. However projects still need to ensure that content released through the programme can be found, used, analysed, aggregated and tagged. In order to facilitate this, content will have to be accompanied by some form of metadata. In this instance metadata doesn’t necessarily mean de jure standards, application profiles, formal structured records, cataloging rules, subject classifications, controlled vocabularies and web forms. Metadata can also take the form of tags added to resources in applications such as flickr and YouTube, time and date information automatically added by services such as slideshare, and author name, affiliation and other details added from user profiles when resources are uploaded. Consequently the OER 2 Programme only mandates the following “metadata”:

Programme tag – ukoer

Project tag – each project should devise a short tag for use in conjunction with the programme tag. e.g. projectname

Title – of the resource being described

Author / owner / contributor – Most systems, whether repositories, vles or applications such as SlideShare, YouTube, etc allow registered users to create a user profile detailing their name and other relevant details. When a user uploads a resource to such a system these details are usually associated with the resource.

Date – This is difficult to define in the context of open educational resources which have no formal publication date. Most applications are likely to record the date a resource is uploaded but it will also be important to record date of creation so users can judge the currency of a resource.

URL – Metadata must include a url that locates the resource being described. The system must assign each item a unique url.

Licence information – Creative Commons is the preferred licence for programme outputs. The cc:license element can be used to provide a URI for the licence chosen and the dc:rights element can be used to provide general textual information about copyrights, other IPR and licence. Embedding the license within the resource is also recommended where practicable. Projects may refer to the OER IPR Support Project for further guidance

Technical information such as file format, name and size may be added but is no longer mandatory.

The hash symbol # should be added to the programme and project tag for use on twitter. E.g. #ukoer for twitter, ukoer for blogs etc.

Projects are also encouraged to think about providing additional information that will help people to find and access resources. For example:

Language information – The language of the resource.

Subject classifications – Specific subject classifications vocabularies are not mandated for the OER Programme. However if a controlled vocabulary is required, projects are advised to use a vocabulary that is already being used by their subject and domain communities. It is not recommended that projects attempt to create new subject classification vocabularies.

Keywords – May be selected from controlled vocabularies or may be free text.

Additional Tags – Tags are similar to keywords. They may be entered by the creator / publisher of a resource and by users of the resource and they are normally free text. Many applications such as flickr, SlideShare and YouTube support the use of tags.

Comments – Are usually generated by users of a resource and may describe how that resource has been used, in what context and whether it’s use was successful or otherwise.

Descriptions – In contrast to comments, descriptions are usually generated by the creator/ publisher of a resource and tend to be more authoritative. Descriptions may provide a wide range of additional information about a resource including information on how it may be used or repurposed.

It’s also useful for projects to be aware that once OERs are released they can easily become separated from their metadata descriptions, if this information is recorded in an associated file. Consequently projects are encouraged to consider embedding relevant descriptive information within the open educational resource where practicable. For further discussion of this approach see Open Educational resources, metadata and self description.

Delivery Platforms

Projects should deposit their content in JorumOpen and in at least one other openly accessible system or application with the ability to produce RSS and / or Atom feeds; for example an open institutional repository, an international or subject area open repository, an institutional website or blog, or a Web 2.0 service.

The RSS / ATOM feed should list and describe the resources produced by the project, and should itself be easy to find. Where a project produces a large number or resources it may not be practical to include them all in one single feed. In such cases it may be necessary to create several feeds in order to list all the resources. If a number of feeds are required to represent the whole collection, the discovery of the complete set of feeds should be facilitated. A number of approaches to enable this are possible, e.g. by creating an OPML file and using multiple instances of the element in the HTML header, or simply listing all feeds in a human readable web page.

There are many other approaches that projects may choose to investigate and use to facilitate resource discovery including search engine optimisation, site maps, OAI-PMH or APIs for remote search (SRU, OpenSearch, ad hoc RESTful search). CETIS will provide further guidance on these approaches in due course.

Projects will be expected to report to JISC on resource use so it is highly recommended that if the chosen delivery platform has tracking functionality this should be switched on and monitored.

For an overview of the wide range of delivery platforms used by the OER Pilot Programme projects may find it useful to refer to the UKOER Technology Overview

Content Standards

The OER 2 Programme is expected to generate a wide range of content types so mandating specific content standards is impractical. However projects should consider using appropriate standards for sharing complex objects e.g. IMS Content Packaging, IMS Common Cartridge and IMS QTI for assessment items.

What We Hope To Learn

We have learned a great deal from the technical choices and experiences of the OER Pilot Projects but we still have much to learn about how to describe and distribute open educational resources most effectively on the open web. Consequently we strongly encourage projects to share their comments, queries, successes and frustrations with CETIS and with other OER 2 projects. CETIS OER Programme Support Officer R. John Robertson will be undertaking informal technical review calls with all OER 2 projects over the course of the programme. Feel free to comment here, or contact John with comments, queries and suggestions.

4 thoughts on “OER 2 Technical Requirements

  1. Pingback: CETIS update tech guidelines | Project TIGER Blog

  2. Pingback: Making OER visible and findable : Information Environment Team

  3. @Nicola/ Jorum a couple of quick questions.

    You mentioned at the programme start up meeting that JorumOpen would – in line with programme IPR guidance – be looking at support for other forms of CC license – unported and UK v3 – the guidelines state England and Wales v2.0 : can you clarify if you’ll be able to support these forms of CC license for bulk deposit?

    I know that there were some concerns with IMS CP bulk upload last time round having to go into a single collection – did this prove to be a problem or are there any work around options for projects?

    I’ve spoken to one project who are planning on using RSS (from an eprints repository) as an ongoing metadata deposit option – your guidelines indicate this is a one time upload option only; so there’s obviously a mismatch. Several options for RSS feed are discussed in the documentation you note can you confirm that you’re expecting a feed for the whole oer collection in the format you specify? and that any updates to the feed need to liaise with Jorum and replaces the entire collection? are you planning to support this post -programme?

    Selenium looks interesting and I’m glad to see another option for projects. To be honest though I’d hoped that SWORD would be on list – does this mean there are still issues with SWORD and Shibboleth that prevent you using it?

    Obviously for some projects there are going to be difficulties in getting the metadata profile their systems create and the profiles you want – based on your experience with phase 1, can we work on a list of tools that can serve as intermediaries /editors?