This document was developed by the participants of the OER Search and Discovery meeting, based on discussions at the meeting.
This document aims to help those who ask, "What should I be doing when I publish my OER's so that they are searchable and discoverable by the OER community and (perhaps) the whole world?". More specifically, this document aims to help those with a collection of such OER's.
There are several options for many of the fundamental questions. Luckily, the number of options is actually quite limited. For nearly all producers we recommend adopting one of the choices outlined below. These have significant adoption and deployment, increasing the reach and exposure of your OER. We will develop bridges between the different approaches; indeed, many of these bridges already exist.
In essence, the choices boil down to:
Harvesting is a technique that allows a software agent to collect resources (content or metadata) from a repository. Some harvesting protocols such as OAI-PMH enable the requesting agent to retrieve only a specific set of metadata or content (for instance based on a query that identifies what is relevant).
The major advantage of harvesting is that the harvester then has all the metadata or content available, so that queries from end users can be processed without further need to contact the harvested repositories. Especially in the context of infrastructures with many dozens or more repositories, this can be quite important, as the response time involved with contacting repositories in order to answer and end user request becomes prohibitively long. Moreover, when queries are forwarded to local repositories for federated search, the local repository may incur considerable load servicing third party queries.
The major concern with harvesting for some organisations is that this approach allows third parties to collect the metadata and content from a repository. In an OER context, this is probably not much of a concern, but it can still raise issues about visibility for the party being harvested.
In concrete terms, there are two important harvesting protocols:
We suggest that you adopt OAI-PMH if you have no strong reason to prefer RSS, as OAI-PMH offers more features that can be important for third party developers. If you also want to provide feeds of new objects that are deposited in your repository, then an additional RSS feed is quite useful.
In order to enable harvesting software to contact a provider of content and metadata, this software must be aware of
This information is typically maintained in a so-called registry. In a way, a registry is a meta-repository: a repository with information about repositories. Its main goal is to enable other services to discover repositories. To this effect, it sometimes also includes additional information about the content repositories, such as data about
We strongly encourage you to register your repository in with ARIADNE or OERfeeds.info.
Metadata describe the content. We strongly suggest that you use either one of the following two metadata schemas, that define an extensive set of metadata elements:
By adopting one of these common schemas, it is easy for software to process the metadata. For specific niche content, standards such as MPEG (for audio-visual material) and others, special purpose formats may be more appropriate. In that case, a mapping to LOM or DC enables interoperability with learning specific tools and infrastructures.
In order to enforce your requirements, you can define an "application profile". This typically involves making some metadata elements mandatory, or imposing constraints on the values that they can hold, etc.
Finally, the metadata are typically expressed in a machine-readable format, sometimes called a "binding". Common bindings includes:
If you want to make sure that the metadata you expose adhere to your self-imposed requirements, we strongly suggest leveraging a validation service, such as ARIADNE's validation service.