[These posts should be regarded as drafts for comment until I remove this note]

Although, a project’s choice of licence is not a particular concern of a technical synthesis,  how the licence is associated with the open content is a technical issue (see also Self description), and many of the available discovery services look for and only recognise particular licence types (typically Creative Commons – see Scott’s post).

Licence choice

Licences chosen in the UKOER 2 programme

Encoding choice

How licences are associated with content in the UKOER 2 programme

Notes

• A few projects use multiple options for licences, but on the whole each of these choices represents a single project.
• A few projects hadn’t chosen at the time of the review calls.
• Some projects use multiple methods to associate their licence with their content.
• Licence encoding options are: entry in a formal descriptive metadata record, encoding in file structure (eg in Word file) or page markup (eg wiki or html), creation of human readable licence information as part of content (eg cover page)
• Consent Commons is a initiative by the Medev subject centre to develop a licence to support the recording of patient and practitioner consent around the use of their personal data. It is beign developed in the style of a Creative Commons licences to offer a simple statement of types of use which are permitted without further permission being sought (i.e. providing consent for some use in a non-transactional licence).
• many of the Strand C collection projects are working with materials under a variety of licences – consequently a number of them don’t have a particular licence choice and aren’t represented here.

Comments

• Although the use of the CC: nd clause works against usage some projects have found it necessary in light of 3rd party or patient rights
• Projects had a strong steer to use a cc: by license, but it seems only a few have been able to do this – it is noteworthy that more projects opted to use the open but restrictive cc: by sa option. For example the Triton project has chosen CC:BY SA for the blog posts which form its ‘static’ collection. As a result any pictures which use in those posts need to have either a CC: BY or CC: BY SA licence. They discuss this in more detail on p5-6 &24 of  Triton final report , as well as Appendix 3
• CC: BY NC SA remains the most popular option
• One project developed software artefacts and used the GNU GPL.

[These posts should be regarded as drafts for comment until I remove this note]

Descriptive choices

Descriptive metadata in use in the UKOER 2 programme

Dublin Core

“The Dublin Core Metadata Initiative “popularized the idea of “core metadata” for simple and generic resource descriptions” and its initial 15 descriptive elements became an international standard and a component of the Open Archives Initiatives Protocol for Metadata Harvesting. The Dublin Core community has subsequently developed in two directions – one developing application profiles to support particular implementation communities and the other developing in a way that would make its data structures more compatible with RDF and support the uptake of Dublin Core around Linked Data (http://dublincore.org/metadata-basics/). At this time there is, therefore, a very wide spectrum of usage of Dublin Core.” (http://blogs.cetis.org.uk/johnr/2010/03/17/the-use-of-dublin-core-metadata-in-the-ukoer-programme/)

As in the first UKOER programme Dublin Core metadata is by far the most widely used descriptive standard in the programme. As in that programme, it is not clear what version of Dublin Core metadata projects are using (many are likely to be using some form of the basic DC Metadata Element Set, some may be using the newer DC Metadata Terms structure), nor is it clear if there is any common set of metadata element choices in use (the programme’s descriptive requirements are representable in Dublin Core and this is likely to form a common set, but there are other valid ways to present this information)

As noted in commenting on the first  UKOER programme, many projects will be using Dublin Core because it is probably the most commonly implemented interoperability standard in repositories and is also a required part of the OAI-PMH protocol.

It is, however,  noteworthy that some of the projects are developing a wordpress plugin to support the creation of DC metadata based on items in blog posts rather than the blog post itself (for more details please refer to the Summary of Strand C [forthcoming]) .

IEEE LOM

““Learning Object Metadata (LOM) is a data model, usually encoded in XML, used to describe a learning object and similar digital resources used to support learning. The purpose of learning object metadata is to support the reusability of learning objects, to aid discoverability, and to facilitate their interoperability, usually in the context of online learning management systems (LMS).”http://wiki.cetis.org.uk/What_is_IEEE_LOM/IMS_LRM

The LOM standard is available from the IEEE store. There are also many Application Profiles of the LOM data model. One of which is the UK LOM CORE http://www.cetis.org.uk/profiles/uklomcore/uklomcore_v0p3_1204.doc ” ( http://blogs.cetis.org.uk/johnr/2010/03/11/the-use-of-ieee-lom-in-the-ukoer-programme/)

The use of IEEE LOM in the second programme is quite a bit lower than in the first UKOER programme. Two possible reasons for this are: 1) fewer projects are using learning object repositories so there is less native support for LOM 2) in the first programme a number of HEA subject centres may have had significant quantities of existing content in the LOM which they released under an open licence, in the second programme projects may not have had relevant legacy content in this form. [Note: these are speculative].

exif

Exif is a standard widely used in cameras and smartphones for storing and transferring information about images, audio, and associated tags. More information is available in the Wikipedia article.
In use by the Open Fieldwork and ORBEE projects.

MeSH

MeSH (Medical Subject Headings ) is not a descriptive metadata standard as such but it is rather a controlled vocabulary used in the description of medical resources. It can be used and referenced with a number of metadata standards such as Dublin Core and IEEE LOM.
In use by the PORSCHE project.

Geo Microfromat

“geo (pronounced “gee-oh”) is a simple format for marking up WGS84 geographic coordinates (latitude; longitude), suitable for embedding in HTML or XHTML, Atom, RSS, and arbitrary XML. geo is a 1:1 representation of the “geo” property in the vCard standard (RFC2426) in HTML, one of several open microformat” from http://microformats.org/wiki/geo.
In use by the Open Fieldwork project.

KML

Keyhole Markup Language: “KML is an XML language focused on geographic visualization, including annotation of maps and images. Geographic visualization includes not only the presentation of graphical data on the globe, but also the control of the user’s navigation in the sense of where to go and where to look.” The major implementation of this standard is in Google Earth and Google Maps.
In use by the Open Fieldwork project.

paradata

Paradata is a rapidly evolving specification to describe activity and review data for digital assets. The initial specification was developed by the NSDL) in connection with the US Learning Registry initiative.
In conjunction with SRI International the Oerbital project developed an experimental template to generate paradata from mediaiwki pages at the OER Hackday.

Packaging choices

Packaging formats in use in the UKOER 2 programme

IMS CP

“IMS Content Packaging “describes data structures that can be used to exchange data between systems that wish to import, export, aggregate, and disaggregate packages of content.”http://www.imsglobal.org/content/packaging/ .” (http://blogs.cetis.org.uk/johnr/2010/03/08/the-use-of-ims-cp-in-the-ukoer-programme/)

ADL SCORM

““The Sharable Content Object Reference Model (SCORM) integrates a set of related technical standards, specifications, and guidelines designed to meet SCORM’s high-level requirements—accessible, interoperable, durable, and reusable content and systems. SCORM content can be delivered to your learners via any SCORM-compliant Learning Management System (LMS) using the same version of SCORM.” (http://www.adlnet.gov/Technologies/scorm/default.aspx )” (http://blogs.cetis.org.uk/johnr/2010/04/01/the-use-of-adl-scorm-in-the-ukoer-programme/)

Two  projects are using both IMS Content Packaging and ADL SCORM – EALFCO and ALTO. ALTO’s use may relate to the capabilities of the tools they have chosen to use.

OAI-ORE

““Open Archives Initiative Object Reuse and Exchange (OAI-ORE) defines standards for the description and exchange of aggregations of Web resources.” (http://www.openarchives.org/ore/)””

OAI-ORE – a number of projects mentioned this standard. For three of the four projects the standard is supported out of the box by the repository platform they were using  and it is there is no indication of actual or intended use. Part of the OSTRICH project team (the partners at University of Bath) were investigating the possible use of OAI-ORE with their repository.

Other content related standards in use

Other assorted standards in use in the UKOER 2 programme

The other standards graph is a miscellanea of other standards which projects are using which are distinctive but don’t easily fit into other categories.

IMS LD

The IMS Learning Design specification provides a flexible markup language to encode pedagogies  (http://www.imsglobal.org/learningdesign/)

The ALTO project is usingconcepts and structures from IMS-Learning Design to inform their work but they are NOT implementing the specification

IMS QTI

“IMS Question & Test Interoperability Specification http://www.imsglobal.org/question/ is a standard used to support the interoperability and exchange of digital assessment items (questions, answers, and data).” (http://blogs.cetis.org.uk/johnr/2010/03/03/the-use-of-ims-qti-in-the-ukoer-programme/)

IMS QTI, one of the content types whose release surprised us in the first UKOER programme, has again been released by a number of projects (De-Stress, OER Cafe, Ripple).

HTML5

HTML5 is a work in progress of the latest update to HTML the defining specification of the world wide web.
The De-Stress project used this specification.

epub

“EPUB is a distribution and interchange format standard for digital publications and documents.” http://idpf.org/epub

Although mobile delivery and etextbooks were not an explicit part of the call both DHOER and Triton are experimenting with the epub format to explore these options.

OPML

OPML (Outline Processor Markup Language) http://www.opml.org/spec is being used in the progamme by the Triton project to support exchanging lists of RSS feeds.

iCalendar

the iCalendar specification is an exchange format for calendar information which can be used to record diary information or request meetings.
The EALFCO project was investigating the use of this specification.

• a protocol almost universally implemented in repositories and consequently (usually) publishing metadata about repository contents to the world
• a protocol frequently reviled by anyone trying to aggregate feeds from different repositories and build discovery tools and services on top of that aggregate.

I’m not going to repeat OAI-PMH’s problems in detail (PERX, the experience of the NSDL with metadata quality, Andy Powell, Jim Downing and many others have done that), suffice to say their are issues about how protocol was implemented by software, how it is used by metadata creators, and how not web-friendly it is and niche it remains.

However,  I realised recently that I’d begun to think that it must be better by now – surely the teething problems are done with – implementations more mature, record quality better, and aggregation more stable. This is, in part, because it remains the standard for sharing repository metadata and because in a number of settings it works well – there are plenty of communities using it to establish and provide services either by creating ‘closed’ controlled conditions through communally enforced ways of recording information and application profiles, guidelines and ‘political’ agreements in additional to the protocol or by creating tools that simply hack their way around whatever data they get and offer good enough services.

So it was with interest that I picked up on a discussion on twitter about what’s wrong with OAI-PMH and an upcoming paper on using Atom .[edit: I’m updating this list with fragments of conversation about OAI-PMH if I see them, and the odd link or two] It’s not the first time I’ve caught fragments of conversations on the use of feeds – for example the earlier RSS and repositories discussion.

There are a slew of issues around trying to standardise feed types (as we discovered in the discussions organised around RSS as a possible metadata deposit mechanism). See for example Feed Deposit , OER, RSS, and JorumOpen , and the two later review articles (1 , 2) as well as the email list discussions ). Given the increasing use of RSS or Atom in some of the OER discovery tools, the work listed above, and the wider promotion of it in the UKOER pilot projects, why am I so interested in this discussion about OAI-PMH and about another effort to use Atom/ RSS?

I’m happy to see this debate crop up again in the wider (library) repository community for two reasons:

1) perhaps obviously it reaffirms the issues with OAI-PMH, that they haven’t changed, and the possibilities RSS/Atom offers,

2) more importantly it’s bringing the discussion about the feeds produced by repositories into the library/ scholarly works communities. Like it or not those are the communities who are most using repositories and the communities who can to some degree shape the development of repository software and specifications. Few repository platforms natively support much customisation of the feeds they produce and until the wider repository community wants that type of functionality or control and begins to think how update or move beyond OAI-PMH* there’s little reason for repository developers to work on the problem.

Without those changes anyone wanting to manage learning materials in a repository still has to hack their own fixes, build their own repository – or not use repositories (but that’s another question).

*I should note: I like OAI-PMH – I can play with in a browser, repository explorer is a good tool, and using OAI-PMH I can get and interact with someone else’s ‘raw’ metadata. – I’m just no longer convinced it’s the right tool to share metadata – in part by how few successful discovery services there are which use it.

In the context of the OER programme SCORM has mostly been interacted with as  a profile of IMS CP (though it utilises and profiles other standards as well).

SCORM is supported by:

• Unicycle
• OCEP
• BERLiN
• mmtv (under consideration)
• Evolution
• OLE Dutch History
• FETLAR

comparing this to the list of those using IMS CP (link); those using SCORM and not using Content Packaging are:

• OCEP
• BERLiN
• Evolution
• mmtv

Support for SCORM is an out of the box function for

• OCEP
• BERLiN
• Unicycle
• Evolution

it may also be for the Moodle users (I’m not sure):

• OLE Dutch HIstory
• FETLAR

I’m not (yet) sure if mmtv decided to pursue the creation of SCORM packages, and am not clear, at this stage, if anyone is actively using SCORM or if projects are only supporting it.

The Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH ; http://www.openarchives.org/OAI/openarchivesprotocol.html ) “provides an application-independent interoperability framework based on metadata harvesting.” The protocol is widely used by repository software to make metadata about the resources they store available. In its use the repository acts as a data provider which is then able to be harvested by a data harvester. Two issues of note:

1. although most repositories can function as data providers the data harvesting aspect of the protocol often requires separate software and is much less widely implemented.
2. OAI-PMH specifies a minimal base metadata set of OAI_DC (~ the simple DC element set) therefore any implementation of it should be able to provide this as a minimum. Other metadata standards such as DC Terms or IEEE LOM can also be made available for harvesting.

Although OAI-PMH is a well established standard which is widely used, at this point it’s use for open educational resources is somewhat limited. OAI-PMH is not currently in use by Jorum for metadata harvesting and, as far as I know, there are not many OAI-PMH based harvesters offering aggregated search services for educational materials (outside of those within particular closed/ or semi-closed communities). DiscoverEd from Creative Commons does offer an OAI-PMH based harvest but prefers RSS/Atom based approaches (Enhanced Search for Educational Resources – A Perspective and a Prototype from CCLearn (2009) http://learn.creativecommons.org/wp-content/uploads/2009/07/discovered-paper-17-july-2009.pdf , p12). UPDATE: Please see comment from Jenny Gray below.

OAI-PMH is being used or is supported by:

• ChemistryFM (option once content is in backup ePrints repository)
• Phorus
• Unicycle
• OCEP
• Open Exeter
• OpenStaffs
• OERP (use unknown)
• Humbox

OAI-PMH is in active use by (as opposed to out of the box support):

• Phorus (harvesting catalogued resources from Intute.)
• TRUE (using a Drupal plug in?)
• ADM OER
• ChemistryFM (option once content is in backup ePrints repository)

OAI-ORE

“Open Archives Initiative Object Reuse and Exchange (OAI-ORE) defines standards for the description and exchange of aggregations of Web resources.” (http://www.openarchives.org/ore/)

As a standard for describing aggregated or compound resources ORE has the potential to be highly relevant to some types of education materials made up of distributed web resources; its use, however, with educational materials has thus far been somewhat limited. It has however been used as an exchange mechanism for moving repository contents from one system to another.

Projects using OAI-ORE:

• ChemistryFM (export function from WordPress – will use to backup content to repository)
• ADMOER (export function from ePrints)
• HumBox (export function from ePrints)

The LOM standard is available from the IEEE store. There are also many Application Profiles of the LOM data model. One of which is the UK LOM CORE http://www.cetis.org.uk/profiles/uklomcore/uklomcore_v0p3_1204.doc

There are a number of projects in the UKOER programme which have identified themselves as using IEEE LOM, they are:

• Unicycle
  • http://unicycle-leedsmet.ning.com/
• Open Exeter
  • http://projects.exeter.ac.uk/oer/
• BERLiN
  • http://unow.nottingham.ac.uk/berlin.html
• OpenSpires
  • http://openspires.oucs.ox.ac.uk/
• OpenStaffs
  • http://www.staffs.ac.uk/about_us/projects/openstaffs/
• Evolution
  • http://www.uclan.ac.uk/lbs/about/evolution.php
• FETLAR
  • http://www.fetlar.bham.ac.uk/
• TRUE
  • http://economicsnetwork.ac.uk/projects/oer
• OERP
  • http://www.engsc.ac.uk/an/oer-project/oer-project.asp

Some of the projects use the LOM as the software they are using to manage OERs uses it or offers it as an export option. These projects are:

• Unicycle
• BERLiN
• OpenStaffs
• EVOLUTION
• FETLAR

Some projects have created mappings to the LOM to support interoperability

• Open Exeter has mapped DC:terms to LOM
• OpenSpires has the capacity and an outlined intention to create an IEEE LOM export but as yet this has not been realised. Their output/export formats are here: http://www.steeple.org.uk/wiki/Msc/E

Others using LOM natively have created a mapping from LOM to Dublin Core to support interoperability

• Unicycle (see http://repositorynews.wordpress.com/2009/08/05/musing-about-metadata-for-oer/ )

Observations

Given the prevalent use of the LOM in VLEs and Learning Object Repositories there’s surprisingly few projects using it – this could have more to do with the technology choices which projects have made for sharing OERs than with the standard as such – although the complexity and richness of the LOM may have been a factor in some project’s choices of technology and (unlike IMS Content Packaging) I suspect choices of whether or not to use the LOM have been much more deliberate.

It is notable that some projects have considered the use of LOM with the explicit intention of better interoperability with other repositories -in particular Jorum (although JorumOpen now supports Dublin Core – this feature was still under development in the early stages of the programme).

Of course this indication of use says nothing about which LOM elements where selected for use in any project or to what extent or how the selected elements were used – that’s a different question for another time.

• Unicycle
  • http://unicycle-leedsmet.ning.com/
• Open Exeter
  • http://projects.exeter.ac.uk/oer/
• OpenStaffs
  • http://www.staffs.ac.uk/about_us/projects/openstaffs/index.jsp
• OLE Dutch History
  • http://www.ucl.ac.uk/dutch/OER/
• FETLAR
  • http://www.fetlar.bham.ac.uk/
• Open Educational Resources Pilot
  • http://www.engsc.ac.uk/an/oer-project/oer-project.asp
• CORE-materials
  • http://core.materials.ac.uk/
• OOER
  • http://www.medev.ac.uk/oer/
• Simulation-OER
  • http://www.ukcle.ac.uk/simshare/index.html
• UK Centre for Bioscience OER Project
  • http://www.bioscience.heacademy.ac.uk/resources/oer/

Some of the projects use Content Packaging in so far as the software they are using to manage OERs uses it or offers it as an export option. These projects are:

• Unicycle
• OpenStaffs
• OLE Dutch History
• FETLAR
• Simulation-OER

Some projects using IMS_CP as a mechanism to deposit content into Jorum

• Unicycle
• OpenExeter [tbc conversation about CP use occured early in project]

Some projects are mediating but not creating resources which are Content Packages

• OERP
• OOER

Observations

Although some projects have chosen to use CP, it should be observed that many projects are either submitting single resources or simply using zip to aggregate or bundle resources. There are a number of reasons CP may not have featured as much as usual, which include:

• different tools in use
  • In comparison to many e-learning development projects few projects in the UKEOR programme are using elearning specific technology (more on this in a future post) and as a result out-of-the-box support for CP is not prevalent in the programme. There is also only limited use of VLEs in the programme.
• detailed structuring seen as superfluous?
  • Another possible reason for the relative underuse of CP may be that the functionality and features it offers to support or store structured content was not considered necessary by projects.
• “Not using content packaging for repository- end users unlikely to use Reload so using  a more straightforward Zip based approach” Humbox project

Talking to DC [Washington] (Adam Bosworth, Adam Bosworth’s Weblog)

In a post based on his experiences with standards development, Adam outlines seven guidelines for good standards development
http://adambosworth.net/2009/10/29/talking-to-dc/

1. Keep the standard as simple and stupid as possible.
2. The data being exchanged should be human readable and easy to understand.
3. Standards work best when they are focused.
4. Standards should have precise encodings.
5. Always have real implementations that are actually being used as part of design of any standard.
6. Put in hysteresis for the unexpected.
7. Make the spec itself free, public on the web, and include lots of simple examples on the web site.

Making Standards that Work (Dorothea Salo, The Book of Trogool)

http://scienceblogs.com/bookoftrogool/2009/11/making_standards_that_work.php
Relfecting on Adam’s post, Dorothea relates some of those principles to her own experience and view of standards development in particular commenting on OAI-PMH.
OAI-PMH is an interesting example because it’s so widely used and, as Dorothea says, so simple. When it works, it works well (even if we might now like to change some of it to be more web friendly). However, metadata sharing works best in defined communities. When OAI-PMH doesn’t work, it’s a mess as frequently it’s the data harvesters who notice but who are dependent on the data providers (and potentially also their technical support) to change anything. Interestingly the OAI-PMH Static repository specification pushed some of the emphasis back onto the data provider – as their base information in xml had to be valid xml before it would be mediated by a gateway (but SRs are a whole other story with lots of potential but their own problems.)

The Sordid History of Learning Object Repositories or, a chat with Brian Lamb (Jim Groom, bavatuesdays)

One of the interesting things about the UKOER programme is how much freedom projects have to choose how they are going to store, describe, manage, and share their resources. They are using a wide variety of approaches, which include repositories, content management systems, and web pages of rss feeds. They’re also using a wide variety of ways to descibe stuff. All of the approaches though are some way from the sort of educational world which the original learning object repositories envisaged and which Brian Lamb reflects on here:
http://bavatuesdays.com/the-sordid-history-of-learning-object-repositories-or-a-chat-with-brian-lamb/. I still think repositories have a lot to offer the management of learning materials but they’re not the only option, are better as part of a wider suite of tools, are really hope they aren’t going to ask users about semantic density. To my mind Brian’s relfections highlight a number of reasons why the UKOER programme is implementation nuetral.

I’ve also realised that I’ve not yet pointed to a related resource from CC Talks about OERs A chat with Stephen Downes on OER http://creativecommons.org/weblog/entry/17860 I was also going to talk about Pete Johnston’s latest installment about Simple Dublin Core but that’ll have to wait for another day (http://efoundations.typepad.com/efoundations/2009/11/simple-dc-revisited.html)

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.

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.