Teachers do not need to understand anything about the LRE architecture or how it works. They simply carry out a search on the LRE portal itself or, if their national or local repository is part of the LRE federation, they can search for LRE content without going to the LRE portal at all.

As well as having access to the repositories in the LRE federation, organisations that decide to become LRE Associate Partners can make their content available via the LRE in a number of ways.

Federating Repositories
In the earlier CELEBRATE project, European Schoolnet discovered that many Ministries of Education supported the concept of a pan-European Learning Resource Exchange but did not necessarily want to create a single centralised database or repository of educational materials.

From a technical standpoint, therefore, the LRE has been designed as an infrastructure based on a ‘brokerage system’ to which independent systems (e.g., learning resource repositories, educational portals, learning platforms) connect to share learning resources in a federated way. This architecture has been adopted because it offers maximum flexibility: it is decentralised enough to allow content providers to manage their collections autonomously, and is secure enough to ensure the trust needed when dealing with content for school pupils.

Figure 1: The LRE architecture.

Figure 1 shows the LRE architecture that is being further developed in the CALIBRATE and MELT projects that are supported by the European Commission. The backbone of the federation is a brokerage system, named “Limbs Is My Brokerage System” (LIMBS), to which repositories of learning resources and educational portals connect thanks to a client java library (depicted as a grey bar) that encapsulates the different networking protocols behind standard application programming interfaces (APIs). LIMBS and its client have already been released under an open source license (LGPL).

The LRE is organised as a set of independent services (e.g., metadata exposition, resource discovery, resource exchange, digital rights management) that can be combined arbitrarily. At the client side, each service corresponds to a pluggable module with a simplified (and, when possible, standard) interface. When connecting a new system to the federation, one selects the services needed and integrates the corresponding modules. This makes the integration effort proportional to the number of services being integrated. Since the brokerage system is able to automatically discover the services supported by a client, it is possible to transparently add or remove services to any system connected to the federation.

With this architecture in place, a teacher or a pupil can query all the metadata repositories available on the LRE for references of learning resources that match their search criteria. The LRE service module that enables federated searches is based on the Simple Query Interface (SQI). SQI is a standard API used to query repositories of learning resources that is characterised by its independence in terms of query language and result format.

Metadata harvesting
Harvesting metadata consists of allowing repositories to expose their content by having their metadata harvested (i.e., mirrored) by a third party (the harvester). Depending on the harvesting service specification, the mirroring of metadata can be total or limited (selective harvesting) according to various criteria (e.g. collections, time periods).
 

Figure 2: Metadata Harvesting

If you have a learning content repository, an alternative solution is to have the LRE service harvest all or part of your metadata. Here the harvesting of the metadata relies on HTTP requests as defined by what is now a widely accepted protocol from the Open Archive Initiative Protocol for Metadata Harvesting version 2.0 (OAI-PMH) (1). OAI-PMH is complemented by an OAI client module that allows repositories:

1. To be registered by the brokerage system so that they can be found by harvesters and
2. To ensure that only authorized harvesters get access to their metadata.

In Figure 2, a harvester and 3 repositories negotiate the harvesting of the repository collections with the brokerage system (black arrows). Then, the harvester uses OAI-PMH to harvest the metadata contained in the repositories (blue arrows and bars). Harvested metadata are stored in a harvester repository that implements a target SQI client module. Thanks to the latter, the harvested metadata can be discovered during federated searches as described in the previous Section.

Federated Search versus Metadata Harvesting?
When choosing whether to support ‘live’ searching, harvesting or both, repository owners should bear in mind that these are not equivalent and each has its pros and cons. During a federated search, the repository is queried in real time, whereas, with harvesting, exposed metadata is gathered into a central cache and it is this cache that is queried.

With live federated searching, a repository can take advantage of unexposed information to process queries more efficiently (unexposed information is information about resources that a repository stores but does not make directly available either because it is not part of the selected metadata standard or because its access is restricted for some reason). However, this also means that, during a federated search, each repository needs to be powerful enough to support the load of processing queries, which, in a federation can be a significant overhead, particularly if the default option for a federated search service is to search all repositories.

Real time searching of repositories will always produce up-to-date results. This is an advantage when collections are volatile with frequent updates. The drawback of live searching is that repositories that are temporarily unavailable at query time, for whatever reason, are ignored. In contrast, when searching cached (i.e. harvested) metadata, complete results are always returned (even if some repositories are unavailable at the time of the query). But the results might be outdated.

Digital Rights Management (DRM)
The main objective of the Digital Rights Management mechanisms supported by the LRE consists in providing all the necessary components to support as many business and distribution models as possible. A second objective consists in making possible their progressive adoption: although the protocol supports many possible use cases, it is really up to the LRE members to decide up to what point they want to implement DRM.

A paper on the LRE technical architecture that includes more detail on the approach to DRM can be downloaded here.

(1)http://www.openarchives.org/OAI/2.0/openarchivesprotocol.htm