The ARIADNE registry is one of the core components in an architecture that promotes interoperability of networks of repositories that facilitates the access to the learning content and encouraging the share and reuse of digital content. This paper explains the development of the ARIADNE registry of learning object repositories (LORs) and the role played by standards and speci cations.
One of the problems of Technology Enhanced Learning (TEL) is that creating
Learning Objects (LOs) is expensive and time-consuming [
LOs are typically stored in Learning Objects Repositories (LORs). In
ARIADNE, considerable e ort has been spent on the development of standards and
speci cations for LORs [
One of the problems for managing all these repositories within a network is the scalability. Currently, every repository is added manuallyin the harvester or in the federated search layer service. However, this time consuming process requires that one person con gures the targets and its parameters such as the requirements (e.g. query languages for querying or metadata formats for harvesting).
In addition, some extra information about the content inside of the repositories can be useful for managing this architecture. For instance, if we know that one repository contains LOs focused on mathematics, and we are interested in them, we can select this target to be harvested. To enable the sharing and exchange of this information with other networks of repositories, the information needs to be structured and managed.
This paper focuses on how the ARIADNE implements the ARIADNE
Registry that has been integrated in the GLOBE architecture [
The paper is organized as follows: section 2 which shows a possible use case of the approach. Section 3 introduces an explanation of the Registry Data Model co-developed in ASPECT project. Section 4 explains the Registry Architecture. Some statistics and data are presented in section 5. 2
This section focuses on a use case for the ARIADNE registry and discusses: (i) the integration of the ARIADNE Registry in existing architectures and (ii) increasing the collaboration between di erent institutions for exposing their LOs. Also, we introduce some technical details about the implementation. The nal goal is to explain the use of the registry in a non formal way.
ARIADNE Foundation has several repositories where the LOs are described by Learning Object Metadata. They expose the metadata using SQI and OAIPMH. However, they have noticed that the number of repositories is increasing and it's di cult to manage all the information from other content providers. These content providers describe their LOs using di erent speci cations like LOM and Dublin Core(DC), on the other hand some content providers expose the LOs using OAI-PMH and/or SQI. Looking for a good solution, they decide to integrate the ARIADNE Registry to manage this information because: 1. The ARIADNE Registry allows the de nition of LORs using IMS LODE.
That is open in terms of using speci cations. 2. The ARIADNE Registry exposes the information using SQI, RSS and OAIPMH. SQI allows to query the registry. RSS alerts subscribers when a new target is added. OAI-PMH allows to harvest all information from the ARIADNE Registry. These three speci cations allow to integrate their ARIADNE Federated Search Layer which queries di erent repositories to obtain di erent LOs from di erent repositories, the ARIADNE harvester which harvests metadata from di erent repositories and to build a federation of registries which allows to collaborate with di erent institutions.
The bene ts that they obtain from the integration of the ARIADNE Registry are: 1. They have centralized all the information from all the repositories where they harvest from. It saves time in terms of administration tasks. 2. They can implement other services on top of the registry to check the availability of the di erent services. This service allows that other services can check this information before trying to access the targets. This information optimizes the performance behavior of these services. 3. The integration of the registry allows that new targets added are widespread by di erent network of LORs which are federated with ARIADNE network. 3
The ASPECT project [
ARIADNE has chosen this speci cation, because it is not restrictive in terms of use of speci cations, and it increases the possibilities of interoperatibility between architectures. In addition, the model does not restrict how the content collections are created. This is an important issue, because the content providers can choose how they create them and can o er metadata information about the collections that they are interested in.
This model is represented by a schema that contains three main elements Content Collection, Metadata Collection and Protocol. 1. Content Collection contains information about access rights, authoring, title description, keywords, etc. This is information about the content itself. 2. Metadata Collection contains information about how the metadata is exposed. Here, the content provider has to de ne which speci cation are used to expose metadata. This part of the speci cation has an element for de ning the speci cation called Protocol Implementation Description which is used for de ning extra information like the query language supported by an SQI interface or sets supported by an OAI-PMH interface. 3. Protocol contains speci c information about the speci cation used like the URL of the schema, namespace or the binding location.
Several examples can be found at the ARIADNE Registry site [
The implementation of the registry enables ARIADNE to build a federation of registries, to provide access to collection information using SQI and to publish new content collections using SPI.
Connections to all the networks
querying one registry Federated Search
Harvester
Registry 2 MC OAI-PMH
CC CC CC
MC SQI MC SSPQII MC SRU/W
SQI OAI-PMH
RSS SPI
Synchronization
A registry can contain metadata collections (MC in the gure 1) or content collections (CC). The latter contain metadata collections (MC).
The nal goal of the registry is to create a network of networks of repositories, similar to current DNS functionality on the internet. All the registries are synchronized so if a harvester or a federated search service queries a registry, they can access all the content collections or metadata collections in the di erent networks. This approach is important: it allows automated discovery, decreases time spent managing repository information, and allows automated widespread updates.
This architecture shows how the registry can be synchronized with other registries. The registry exposes its contents using OAI-PMH so that other registries can harvest its content. In addition, the registry exposes its updates also using the RSS 2.0 speci cation, so that registries can be synchronized also with RSS feed readers. This RSS system can be used as a noti cation system, as it contains all the targets published.
The registry uses SQI for querying because it is neutral in terms of query language or results formats. Consequently, all SQI clients can query the registry. The registry supports di erent query languages like PLQL, VSQL and Lucene Query Language.
Finally, the registry implements an SPI interface for publishing content collections. For instance, when other content collections are harvested, they are inserted using SPI to publish content by reference, because the metadata in this case de nes a content collection already published elsewhere.
One of the main advantages of this implementation is that ARIADNE Registry is based on the ARIADNE Repository. This software is a exible implementation that allows di erent models of metadata. For instance, it supports LOM, ILOX, Dublin Core and this paper explains how it supports IMS LODE Registry speci cation. The idea behind this software is that we can index all kind of xml document. However, the nal goal is that we can built combined queries, for instance, using PLQL, based on the content of di erent tags.
Trying to validate this architecture, we have integrated the ARIADNE harvester with the registry. The following sequencing diagram 2 shows how a system administrator can con gure the harvester using the current implementation where the system administration can query the registry and add the targets that he/she is interested in. 5
One of the main goals of ARIADNE is to encourage sharing and reusing LOs. For this purpose, we have implemented a registry using the concept of content collection, integrating some technical information in the data model and allowing the federation of registries. Table 1 shows the similarities between existing approaches and the ARIADNE approach.
Domain Name System (DNS)[
ARIADNE Harvester
To Send keywords Forms for adding/update/delete new targets
Request Forms updated
To complete the query with (1)
Results the federation of the registries (the new content collections should be propagated among them)
METEOR's Web Service Discovery Infrastructure (MWSDI) uses UDDI
speci cation for de ning the interfaces (web services) and it de nes an ontology for
providing support to the infrastructure using OWL. MWSDI is based on the
need to decentralize an architecture for several reasons such as geographical
location, nature of registered services, business functionality, technical speci
cations and so on [
JISC Information Environment Service Registry (IESR)[
CORDRA / ADL registry (ADL-R) merges the concepts or MWSDI and
IESR/OCKHAM, introduces a hierarchical structure of registries and the
concept of content collection based on repositories which accept LOM as a metadata
of LOs [
At the end, we can conclude that Ariadne Registry incorporate the best characteristics from other approaches: 1. Conceptually, we implement similar approach to DNS widespread functionality. 2. IMS LODE Registry allows the de nition of the services like UDDI speci cation concept do. 3. IMS LODE Registry allows the content collection approach like the above approaches mentioned do. 4. ARIADNE Registry allows the federation of the registries. 6
In this section, we include some information about the metadata collections inserted and how they expose the metadata. It includes the number of records harvested using the OAI-PMH protocol. However, SQI or SRU/W don't provide a way to get all the possible results, thus the SQI and SRU/W targets do not contain information in date and records harvested eld (table 2).
Table 2 shows that the registry contains fourteen repositories which support SQI, one repository which supports SRU/W, twenty- ve which support OAI-PMH and one which supports SPI. As the ARIADNE harvester relies on the registry, we know how many objects are exposed through OAI-PMH. The information is shown in the table.
The result is that we expose 1151000 metadata instances through the ARIADNE registry so far, although, we have to remark that some of them are duplicated, because some targets harvest other targets. But it means that we can expose a large amount of metadata instances specifying the protocol to access to them. All the harvesters which implement OAI-PMH can connect easily to the registry, using an SQI client for nding the targets and harvesting all the metadata from all the repositories described in the registry. 7
We have developed a LOR registry, which enables us to set up a federation of registries. Di erent federations of repositories can easily obtain information from other federations through the registries. In this context, we will deploy the ARIADNE Registry in the ASPECT project, and we will evaluate the pros and cons of the federation.
In the scope of this work, we have considered some of the main speci cations about querying, harvesting and publishing like SQI, OAI-PMH and SPI. We have spent some e orts to de ne extra information for the SRU/W. However, we have to validate this speci cation. Also, we would like to consider more speci cations such as OKI OSID.
Now, we have integrated the ARIADNE harvester with the registry, in addition, we have to work on the Federate Search Layer to allow querying based on the content of the registries.
Acknowledgment The ARIADNE Registry has been funded partially by the ASPECT project: Adopting Standards and Speci cations for Educational Content (Grant agreement number ECP-2007- EDU-417008) and by the CEN/ISSS workshop on Learning Technologies (WS-LT). Thanks also to our colleagues Ivana Bosnic and Katrien Verbert for helping us in this work.