Navigation
     
   
visit European Schoolnet The MELT project is co-funded by the European Community eContentplus Programme. logos
 MELT architecture 

The MELT Architecture for metadata enrichment

The MELT project aims to provide more and better metadata for approximately 38,000 learning resources and 100,000 learning assets. Enriching such a critical mass of content, however, requires a scalable, extensible architecture. To achieve this, KatholiekeUniversiteit Leuven/ARIADNE Foundation and European Schoolnet have designed and implemented an architecture that consists of several, loosely coupled components that facilitate:

  • Inclusion of new content providers
  • Validation of metadata
Below we describe how this architectureis currently beingused in the MELT project. We explain howit deals with how metadata travels in a network of repositories and illustrate how, usinge-learning standards such as IEEE LOM, CEN SQI and OAI-PMH, different repository components are brought together in a service oriented architecture.

Harvesting

Frameworks for metadata harvesting (like OAI-PMH) enable harvesters to copy (pull) metadata from a repository and save a copy of the metadata locally. The MELT architecture for harvesting illustrates the metadata flow prior to enrichment of content.

Fig. 1: The MELT enrichment architecture: centralised enrichment. 
Fig. 1: The MELT enrichment architecture: centralised enrichment.


On the left of Figure 1 the MELT content providers offer access to their non-enriched metadata. These content providers use the OAI-PMH framework to offer access to metadata encoded according to the LOM standard. The ARIADNE harvesting component regularly checks for new metadata instances and pushes them into a non-enriched metadata store, where the LOM records are available for enrichment. In order to ensure that only MELT compliant metadata records will arrive in the non-enriched metadata store, the metadata validation service enables the harvesting framework to check records against the MELT metadata application profile. This service builds on XML Schema (XSD), Schematron rules and special purpose components to check for compliance.

Content enrichment

Enrichment of content can take place at various places. MELT content providers can opt for local enrichment. In this case, the indexation tool of a content provider has been extended so that it supports the metadata fields that are required in the MELT LOM-based application profile. In order to support enrichment in a centralised fashion, an enrichment toolkit has been created. With this toolkit, indexers can select metadata instances from the non-enriched metadata repository and complete these metadata instances. After enrichment (either centrally or locally), the MELT instances are published in the central repository where they can be consumed in various ways:

  • The MELT portal enables teachers to search for suitable learning objects
  • The content providers can harvest back enriched metadata instances and use these instances locally.
The MELT enrichment tool can select metadata instances from the EUN harvested metadata repository, enrich them and afterwards store them in a MELT repository.
 
Figure 2: Enrichment flow of a single metadata instance
Figure 2: Enrichment flow of a single metadata instance


Central enrichment of metadata instances in MELT includes two steps:

  1. In a first phase, all non-enriched metadata instances are automatically enriched by SAmgI, the automatic metadata generation framework offered by ARIADNE. (see Figure 2). The next section explains this framework in more detail.
  2. Next, a MELT administrator can assign metadata instances to expert indexers. This indexer can further add, change or alter metadata fields.
After submission by the expert indexer, the new metadata instance is stored in the enriched metadata store along with other enriched metadata instances.
 
 
Figure 3: Enrichment flow of a single metadata instance
Figure 3: Enrichment flow of a single metadata instance


Figure 3 illustrates two ways in which metadata can travel to the enriched metadata store:

  1. After local enrichment, metadata is harvested through OAI-PMH and stored in the enriched metadata repository where it is available for the MELT portal
  2. Metadata can migrate from the non-enriched metadata repository to the enriched metadata repository through central enrichment.

Automatic metadata generation

We have developed various cases where metadata can be generated automatically. Through the Simple Automatic Metadata Generation Specification (SAmgI), various components in MELT can benefit from this functionality:

  • Locally. Two cases have been developed where local content enrichers can make use of our SAmgI services to generate metadata for specific kinds of content. In Scoilnet (the educational portal for schools in Ireland) for instance, many resources coming from teachnet.ie are indexed. As these web-based resources are all structured according to the same template, a special SAmgI context based indexer was deployed that is able to exploit the teachnet.ie template and automatically generate MELT metadata for Scoilnet.
  • Centrally. A general purpose version of SAmgI has also been deployed at the level of the central enrichment tool (see fig 2). Before central enrichment, metadata instances are enriched using the SAmgI services with additional metadata. Next, expert indexers can futher edit this semi-automatically generated metadata.

Harvesting back

Content providers that opted for central enrichment, need a means to obtain the enrichments that their indexers carried out using the central enrichment toolkit.
Also, as the MELT generated metadata is freely available for the MELT partners, an OAI-PMH target is provided by EUN that facilitates obtaining the enriched instances from the enriched metadata repository. We encourage content providers not to overwrite their original resources with these metadata instances but rather host them in a metadata store that is not harvestable through the OAI-PMH offered in phase I of the project. Deleting the old instance and using the MELT instance instead is thus not advised.

The enriched metadata repository offers two important interfaces (Figure 4):

  1. Through an SQI target, various tools can dynamically query the enriched metadata repository. Figure 4 illustrates that, through SQI, the MELT content is not only available for searching by the MELT portal, but can also be queried by the GLOBE network of repositories.
  2. The OAI-PMH target enables various interested parties to obtain a local copy of the MELT metadata.
  
Figure 4: MELT enriched metadata usage
Figure 4: MELT enriched metadata usage


Conclusion:

The architecture that has been presented in this article is currently in use in the MELT project and enables various partners to share and reuse metadata and learning objects. Furthermore, as we have put strong emphasis on interoperability and using open standards, the MELT architecture and the various components can be exploited even beyond MELT:

  • Various LRE Associate Partners are building on the services that are offered in MELT.
  • GLOBE, an international alliance of organisations involved in federated search,connects to the MELT federation.
  • Various components (e.g. harvesting, validation, repository) that are leveraged in MELT have already been reused and deployed in other projects. For example, the MACE eContentplus project relies on these components to offer search access to a similar network containing learning objects for teaching architecture in Europe.
If you want to find out more about this architecture and how you can connect to our services or reuse our components, you why not attend the next MELT LRE developers' workshop on 8-9 September 2008?