13 thoughts on “Comparing metadata requirements for OERs (part 1)

  1. This is really useful (and reassuring!). Some thoughts …

    I wonder what proportion of OER content is shared as zipped files? Either because it’s mixed file types, because it’s big to download, and/or because it’s IMS/METS content packaged. If users want to see the file format in a list of search results (“I’m looking for a presentation format such as a .ppt”) then it would be useful to record the file format in the metadata, even if its downloadable as a compressed zip file? But then the field would need to allow multiple file types to be listed. And if we build this in to metadata requirements as a mandatory field to support this particular scenario, would that be elegance at the expense of uptake? Hmmm … feel free to unpick my woolly logic there.

    Another thought is about rights. Rights should be mandatory metadata, and I guess it should include: rights holder + licence. that license could be a url or just a summary (e.g CC:BY:NonComm). But we’ve been discussing around the OER projects as well that the rights information should ideally be embedded in the resource itself in case the resource gets detached from the metadata (as happens if you download a resource to your C:drive). So in this case the metadata isn’t really enough, for practical purposes.

    Educational level – I totally agree with you. Interested to hear further thoughts on that!

  2. Completely agree re educational level. This is a very difficult field to populate especially for open educational resources that are likely to be used in a variety of different contexts and levels. Having experienced the pain and suffering that resulted from UKEL (how difficult could it be??) any mention of educational level makes me want to run for the hills. Having said that I can think of plenty of usecases where it would be very helpful to have some idea of the original intended educational level of a resource. However I would hesitate to make educational level mandatory or even highly recommended.

    Also agree with Amber re embedding rights metadata within the resources, particularly for the OER Programme.

  3. Hi Amber,

    Zip files do present a case for having the file format(s) in the metadata. With metadata about the zip/ IMS CP/ METS file I guess that it depends how granular the assets and metadata are going to be. As I understand it both packaging formats allow the description of component assets as well as the package. Although even with zip files extracting file format metadata should be automatable as the repository will hold (or at least process) the unzipped files.

    I agree we need clear rights / licence information – ideally in the metadata and on the resource. I think it needs to be both stated and a uri. Ideally resources shold have ‘cover pages’ where they can; beyond that, I think embedding the licence into the resource could be good and I can see a good case for rights provenance travelling with bits of resources but I’m wary of anything that tries to take that a step further and ‘enforce’ the movement of rights. As I understand it DRM has consistently proved double edged and a preservation headache.

    Educational level – this will crop up agian in part 2 (whenever I get it written)

  4. The importance of providing informaiton on educational levels and how difficult it is to do so both depend on the scope of the collection. If you’re collecting resources for everything from kindergarten through to postgraduate / professional development (as I guess ccLearn/DiscoverEd are) then you really need something by way of education level to allow people to filter down to just the primary or just University level. If your collection is focussed on just one sector, e.g. all your material is University level (as is pretty much the case for UKOER) then providing a finer level description becomes more difficult and less useful.

  5. Pingback: John’s JISC CETIS blog » Comparing metadata requirements (part 2)

  6. Educational level even within a sector e.g. HE may be very important to learners rather than teachers. Whether covered in metadata in additional information on site it was something we considered from the outset and much of the reasoning for waht we did is covered in:

    Lane, A.B. From Pillar to Post: exploring the issues involved in re-purposing distance learning materials for use as Open Educational Resources, 25 pp, 2006, OpenLearn Working Paper No. 1, available from http://kn.open.ac.uk/person.cfm?userid=5861

  7. Re: educational level – one could limit the available levels to ‘primary’, ‘secondary’, ‘further’, ‘higher’ – oh wait… no… you’re right… best forget it! Too problematic.

    On filesize… I’m amazed anyone is even interested in this (however it is generated). I take the point about multiple resources embedded into a single zip – but might be better to encourage a move away from the whole ‘content packages’ thing anyway?

  8. Pingback: John’s JISC CETIS blog » Comparing metadata requirements for OERs (part 3)

  9. Pingback: Phil’s JISC CETIS blog» Blog Archive » About metadata & resource description (pt 1)

  10. Pingback: Musings on the developing OER infrastructure « Repository News