The first two parts of this foray into metadata requirements for Open Educational Resources examined: 1) how the required information for the UKOER programme compared with the requirements for the Jorum deposit tool and the DiscoverEd aggegator 2) how the UKOER requirements compared to the information projects thought would be necessary for particular activities (find, identify, use, cite, manage, select). In this final part I’ll offer some personal reflections on the implications of these comparisons and comment on the role of educational metadata and annotations.

It was perhaps predictable, though not essential, that there would be close correspondence between the programme requirements and Jorum’s requirements but it was good to see that the UKOER’s metadata requirements were comparable to those of ccLearn’s aggregator. I’m glad to note that alongside The University of Nottingham initiative UNOW and the Open University’s Open Learn,  Leeds Met’s Unicycle project are also thinking about this (http://twitter.com/mrnick/statuses/3575276663 ). As outlined in part 2, what proved more interesting is that, when as a programme we thought about some of the information that the users of our resources would need, the programme requirements were a subset of that list.

One thing I’d highlight here, before I do that, is that the one piece of information that we agreed was essential to use an OER was clear licence information. I’m sure that this will get discussed a lot more but in the wider discussions going around the programme it is becoming clear that this information needs to be available as part of the asset for people to read (for example, as a cover page statement), in the metadata (to support licence specific searching), and in the RSS feed – so that it’s clear to aggregators.

Educational description

Part 1 noted DiscoverEd’s use of educational content and sparked some comments about the use of educational context – specifically focused on the issue of educational level; in part 2 information about  educational context emerged from our discussions aboutwhat we would want to know to interact with the OERs.

Developing best practice guidelines for eduational metadata in the UKOER programme is an ongoing process and one in which we’ll probably be tracking what the projects find useful as much as, if not more than, we make recommendations. CETIS has existing guides to metadata at http://wiki.cetis.org.uk/Guides_to_metadata and summaries of relevant metadata standards at http://wiki.cetis.org.uk/Educational_metadata_standards . We’re begining to gather specific guidance, links, and best practice information at http://wiki.cetis.org.uk/Educational_Content_OER but these guidelines are very much just beginning.

As Phil and Andy L noted on part 1 -if you’re dealing with resources ranging from primary school to postgraguate or CPD, the ability to quickly filter by broad educational level is quite important and for the purpose of wider interoperability recording educational level allows a richer service in some aggregators (currently DiscoverEd). But it’s hard to know what an appropriate and useful granularity would be – especially given that the audience of an OER is global. Perhaps, stating on the resource what class or course something was used for is a good idea as it provides the user (though not the system) with an understandable point of reference. In terms of metadata – if Jorum uses UKEL (I can’t remember and can’t access it) this is probably the right vocabulary to use. Given the focus of the programme on HE the appropriate (multiple) UKELs may be able to be added to batches of project resources – though broad this would give aggregators with a wider remit something to work with.

In terms of wider educational description – intended use, context of use, requirements for use, instructional method, are a few of the candidates. However, providing this sort of information has the potential to rapidly move away from the light touch approach to metadata that has characterised the programme thus far, and significantly add to the ‘cataloguing’. A quick glance at the practice of many of the successful OER initiatives suggests limited educational metadata may be the way to go; OCW & MERLOT record the item type but with vocabularies geared to their collections.

The upcoming technical discussions with projects will begin to establish what educational information they are recording and help frame some guidelines.

Usage information

Some other types of information that our discussions suggested would be really helpful (especially in the context of managing OER collections) was usage information, user ratings, and comments. This presents somewhat of a challenge. As:

1. Usage statistics are often application specific and not part of structured metadata.
2. Annotations are a sort of metadata but they actually form resources in their own right and it’s both tricky and somewhat messy to include them in metadata – especially if the resource and metadata then move (as they are intended to). As I understand it one possible approach would be to use OAI-ORE to associate distributed annotations that you were aware of with a resource.

I’m not yet aware of best practice in this area, nor aware of what projects are planning to do about recording OER use or distribution, but suspect that:

1. is beginning to move towards the bigger discussion about tracking of OERs.
2. is going to depend a lot on the capabilities of the tools and systems projects are using and how they record anntoations or ratings.

More details of about both of these issues will again emerge through the technical discussions but I suspect best practice for statisitics or an investigation of tracking are getting outside of the scope of our work.

In Comparing metadata requirements (part 1) I examined the required and suggested metadata for Open Educational Resources in the UKOER programme, for the Jorum deposit tool, and the DiscoverEd aggregator. In this second part of the comparison I’m going to try to capture some of our initial discussions fom the UKOER programme session about metadata and then very roughly compare the brainstorming we did as part of that event with the requirements of the programme and other initiatives.

To begin with let’s have a look at a graphical overview of the requirements from the three initiatives. The graph below displays an overview of the metadata requirements of the UKOER programme, the Jorum deposit tool, and the DiscoverEd aggregator service. Full height bars are manadatory elements, three quarter height bars are system generated elements and half height bars are recommended metadata elements.

Graphical overview of metadata requirements relating to the UKOER programme

In the elluminate session, we asked the participating projects to consider what metadata they would require to:

• identify
• find
• select
• use
• cite
• manage

a resource. Participants then shared their suggestions in the chat box. I’ve put the data together and were appropriate combined or split entries. The below graph represents the group’s suggestions of which possible pieces of information are important for each of the outlined functions. (Some caveats are in order. The exercise was not rigorous, the number of participants answering at a given time varied; the first question ‘identify’ had a higher broader repsonse rate – this may relate to how we explained the exercise. The answers were free text and not from a prior list. Unless specified the idea of a date is counted for both creation/ initial use and upload/ publication. It also became clear that for functional purposes rights mostly collapsed in to licence (thus it was dropped from the graph).

Condensed outputs of metadata responses

Graph displaying a summary of metadata requirements for functions from brainstorming in 2nd Tuesday session

The idea of educational level is implict in educational description /context and so it should probably be included with that category (this has not been done in this graph however, as educational level is singled out in the requirements). It is not entirely clear what was intended by some of the descriptions – e.g. coverage.

Examining the graph it is clear that there are some key pieces of infromation for particular uses. Across the entire set of functions the key information appears to be: author, date of publication, subject and description, educaitonal description/ intended use (if combined with educational level) and usage data.

The key information for each function was:

• identify – subject
• find – description
• select – licence
• use – licence
• cite – date of publication
• manage – usage data

By way of enabling a comparison with the metadata requirements, the top three responses for each function where collated (and then taken as factor of one) – this was done to provide an approximate indication of overall importance that could be compared to the requirements data.

OER required metadata compared to brainstorming

From this comparison it is interesting to note the following:

1. Of the two contentious mandatory metadata elements: file format/ mime type was actually considered to be functionally important.
2. Recording the Language of an OER was not considered to be critcial for any of the functions – though all the initiatives consider it important (this may be attributable to the programme-based context of our discussion).
3. The institution/ publisher is surprisingly unimportant functionally (unless you are, like Jorum, hosting materials).
4. Licence is probably the most important piece of information for an OER.
5. Usage data and user ratings are considered to be critical pieces of information – they are not however included in metadata profiles – however, it is likely that this information would be generated over time by the relevant host services

There’s probably more to say about this data and more to do with it but for now at least – that’s plenty to reflect on.