A "simple query interface" adapter for the discovery and exchange of learning resources.

Developed as part of CEN/ISSS Workshop on Learning Technology efforts to improve interoperability between learning resource repositories, the Simple Query Interface (SQI) is an Application Program Interface (API) for querying heterogeneous repositories of learning resource metadata. In the context of the ProLearn Network of Excellence, SQI is used to interconnect heterogeneous networks of metadata repositories such as Elena, Celebrate, Ariadne or Edutella (Simon, Massart, Van Assche, Ternier, Duval, & Brantner, et al., 2005). This article proposes to use SQI not only as an interface for searching metadata as it is primarily intended by the CEN/ISSS workshop, but also to obtain the learning resources themselves. It describes how, taking advantage of its asynchronous mode, SQI constitutes a simple and robust entry point to the networks of metadata and learning object repositories that compose an iClass server.

**********

Learning objects are definable, reusable chunks of digital content and process elements used for learning, training, and instruction (Richards, 2002). Actually, learning objects can be anything digital used in learning (e.g., texts, illustrations, digital videos, interactive multimedia, tests, lessons, or courses). The potentially dynamic and multimedia nature of learning objects makes most of them unlocatable using text-based search engines such as Google which, in addition, returns results that are difficult to assess by teachers and pupils. This problem is usually solved by creating metadata to adequately describe learning objects (Richards & Hatala, 2003). The IEEE Learning Object Metadata standard (IEEE Standards Department, 2002) was created to unify the way learning objects are described and to ease their retrieval. Although they can be stored on a web server, learning objects and metadata are often stored in specialized repositories referred to as learning object repositories.

Usually, obtaining a learning object is a three-step process consisting of (a) searching and evaluating metadata, (b) resolving the location of the chosen learning object, and (c) consuming the learning object. This process is depicted on the activity diagram of Figure 1.

1. Searching and evaluating metadata: Selecting a learning object that satisfies user needs on the basis of the description provided in the metadata. It may be necessary to repeat this step in order to refine the search criteria and find the appropriate learning objects.

2. Resolving the learning object location: Under some circumstances, metadata provides references to learning objects rather than their locations and an additional step is necessary to resolve the location of an object on the basis of its reference (1). This situation occurs, for example, in the Celebrate federation (Van Assche & Massart, 2004; Simon & Colin, 2004) where the additional step, which consists of requesting a learning object location, is used to enforce the digital rights associated with the learning object. The actual location of a learning object is delivered only if the requester is authorized to access the learning object. Another reason (for not storing the location of a learning object in the metadata describing it) is illustrated by the iClass project (iClass Consortium, 2004) where the adaptive and multimedia nature of the learning objects combined with the peer-to-peer nature of the underlying network of learning object repositories makes it difficult to access learning objects directly. This is why, in iClass, the "resolve-location" step is used to retrieve the requested learning object in a peer-to-peer network of repositories and move it to a streaming server which, combined with a "presenter," gives access to the learning object using a web browser.

3. Consuming the learning object: Getting the selected learning object at the location--usually a universal resource locator (URL)--obtained during the second step.

Obtaining a learning object from a peer-to-peer network of learning object repositories, such as the one developed by the iClass project, requires an interface that not only supports all of the three steps but is also able to perform those steps in an asynchronous mode. Currently none of the interfaces that have been proposed to enable open learning object repositories to search each other (2) fulfills all those requirements.

[FIGURE 1 OMITTED]

Among these interfaces, the Simple Query Interface (SQI) is the only one that supports asynchronous queries. This article shows how the adapter developed by the iClass project (iClass Consortium, 2004) takes advantages of SQI independence in terms of query language and resulting formats to resolve learning object locations (i.e., step 2) in an asynchronous way.

The rest of this article is structured as follows: the section "Overview of the Simple Query Interface (SQI)" gives an overview of the main characteristics of the Simple Query Interface. "The iClass Adapter in Context" section presents the main components of the iClass project used for searching metadata and obtaining learning objects. Finally, the section "Obtaining Learning Objects with SQI" describes how SQI can be enriched by a new query language and a new result format to request learning object location without modifying the interface itself.

OVERVIEW OF THE SIMPLE QUERY INTERFACE (SQI)

The Simple Query Interface (SQI) is a standard (3) Application Program Interface (API) for querying heterogeneous learning resource repositories (Simon, Massart, Van Assche, Ternier, & Duval, 2005) (i.e., it covers the first step of the process of obtaining a learning object, previously described). Its main characteristics are:

* simplicity and ease of implementation,

* neutrality in terms of query languages and result formats, and

* support for both a synchronous and an asynchronous query mode.

Considering two repositories sharing at least a common query language and a common metadata format, the following steps are necessary to enable one repository (referred as the source of the query) to query the other (referred as the target of the query) using SQI:

* the source selects one of the query languages available at the target (e.g., XQUERY--It is possible to skip this step when a default query language is proposed by the target),

* the source selects one of the result formats available at the target (e.g., the IEEE Learning Object Metadata binding--Here also it is possible to skip this step when a default result format is proposed by the target),

* the source sends a query in the selected query language,

* depending on the query mode selected, the target provides the result of the query in the selected format either as the return value of the call used to send the query (synchronous mode) or by calling one or more times a query result listener implemented by the source (asynchronous mode). The latter mode is much more robust and enables SQI to be used as the front-end interface of a federated search since it is not necessary to wait for the end of the initial query before returning the first results.

The API itself is depicted on the class diagram of Figure 2. It consists of 13 methods that can be grouped into four categories: session management, query management, synchronous query management, and asynchronous query management.

Actually, session management methods are not part of the SQI specification itself and can potentially be replaced by any other session management mechanism that would be considered more appropriate. Current methods permit opening anonymously (createAnonymousSession) or not (createSession) and to close (destroySession) a session with the target repository.

The query management methods permit the configuration of query parameters such as the query language (setQueryLanguage), the format of the results (setResultsFormat), the maximum number of results returned (setMaxQueryResults), and the duration of a query (setMaxDuration).

In a synchronous query, query results are returned as the results of a query call (synchronousQuery). Additional methods permit the choice of the number of results returned by a call (setResultsSetSize) and to know the total number of results of a query (getTotalResultsCount).

[FIGURE 2 OMITTED]

In an asynchronous query, query results are sent by the target to the source of the query by calling a listener implemented by the source (queryResultsListener). This implies that the source has to indicate the location of the listener to the target (setSourceLocation) before sending an asynchronous query (asynchronousQuery).

The fault mechanism provided by SQI is intentionally unsophisticated. It aims at simplicity rather than richness in order to offer the greatest opportunity for consumption by a variety of applications. When a failure occurs, each SQI method is able to report it by throwing a fault (SQIFault) that specifies a predefined error code (4) and a free-text message.

THE ICLASS ADAPTER IN CONTEXT

The iClass adapter is a component of the Intelligent distributed Cognitive-based Learning System for Schools (iClass, [iClass Consortium, 2004]). It enables the end-users of so-called "legacy systems," (5) such as the learning management systems and learning content management systems that are members of the Celebrate federation, to search and access iClass contents (or learning objects).

The iClass components interacting with the iClass adapter are specified on the component diagram of Figure 3. A legacy system communicates with an adapter using the simple query interface. In turn, the adapter communicates with two elements of the iClass server to which it is connected: the content server and the content distribution system using their respective interfaces.

The content server is a peer-to-peer network of metadata repositories (Blyuss, 2004b). It propagates each query received from node to node. Each node processes the queries and returns the results to the content server which forwards them asynchronously to the source of the query.

The content distribution system is a peer-to-peer network of learning object repositories (Blyuss, 2004a). When the location of an iClass learning object is requested (on the basis of an iClass learning object identifier found in the metadata), the request is propagated from node to node until an instance of the iClass learning object is found. The iClass learning object is then moved to a streaming server close to the requester location and a URL from which the iClass learning object can be consumed is returned by the content distribution system. Since potentially this process has a "certain duration," the content distribution system answers to these requests asynchronously. The presenter is a web server from which the iClass learning object can be consumed.

[FIGURE 3 OMITTED]

OBTAINING LEARNING OBJECTS WITH SQI

The use of a standard and open interface is a strong requirement to enable as many learning systems as possible to search and access the iClass collections of learning objects. The simplicity of SQI, its ability to be used in combination with any query language and result format, and its asynchronous query mode make it a good candidate interface for searching metadata in a peer-to-peer network of metadata repositories such as the iClass content server (6).

In iClass, metadata indicates the identifier of the learning object and not its location. A second step is thus necessary to resolve the location of a learning object identified in the metadata. Since an open interface for performing this step asynchronously does not exist, and rather than create an ad hoc interface, it was decided to use SQI for this task as well by adding a new "query language" for requesting a location and a new "result format" for returning a location to the list of languages and formats supported by the iClass adapter. It is easier for those with legacy systems and the adapter to implement this solution rather than a new interface.

The sequence diagram of Figure 4 describes the sequence of method calls necessary for obtaining the location of a learning object using the SQI interface of an iClass adapter. It covers both the step of searching the metadata and the one of resolving a learning object location. For simplicity, the method calls required to manage a session between the legacy system and the iClass adapter have been omitted.

Searching Metadata

* The legacy system starts by sending to the adapter the address of an SQI listener that can be used by the adapter to return query results (setSourceLocation).

* This being done, the legacy system sends an asynchronous query to the adapter (asynchronousQuery).

* The adapter forwards the query to the iClass content server (queryMetadata).

* The content server processes the query and sends the results (i.e., a set of metadata) back to the adapter (queryResultsListener).

[FIGURE 4 OMITTED]

* In turn, the adapter propagates the results by calling the SQI listener implemented by the legacy system (queryResultsListener).

Resolving Location

At this stage, the legacy system is able to request the location of a learning object on the basis of the information found in the result of the query (i.e., metadata containing a learning object identifier).

* The legacy system calls the adapter to indicate that it will use a new query language (setQueryLanguage) and a new result format (setResultsFormat) to request a learning object location.

* In this particular case, the query language is named "ICLASS-LO-ID." A query in this ad hoc language consists of the requested learning object's identifier. The result's format is named "URL." A result in this format consists of a URL pointing to the requested learning object.

* Then, the legacy system sends the request (i.e., the identifier of the requested learning object) as an asynchronous query (asynchronousQuery).

* The request is forwarded by the adapter to the iClass content distribution system (requestILOcation).

* The content distribution system processes the request and returns to the adapter the URL from which the learning object can be consumed (queryResultsListener).

* The adapter, in turn, forwards the URL by calling the SQI listener implemented by the legacy system (queryResultsListener).

At this stage, the URL can be used by a legacy system end-user to consume the learning object in a web browser.

CONCLUSION

Taking advantage of SQI independence in terms of query languages and result formats, this article proposes to use SQI not only for querying metadata as it is primarily intended in the context of the CEN/ISSS workshop on learning technology, but also for resolving the locations of learning objects. In the latter, requests for location are viewed as a query in an additional query language and locations are returned in what is considered as a new result format. This permits the minimization of the cost of implementing a "resolve-learning-object-location" step for learning object repositories that already use SQI for searching metadata.

References

Blyuss, I. (2004a). iClass content distribution system: High-level design specification. Version 0.6.

Blyuss, I. (2004b). iClass content server and database: High-level design specification. Version 0.2.

IMS Global Consortium (2003). IMS digital repositories interoperability--core functions best practice guide. Retrieved September 29, 2005 from http://www.imsglobal.org/digitalrepositories/driv1p0/imsdri_bestv1p0.html

iClass Consortium (2004). Intelligent distributed cognitive-based learning system for schools. Retrieved September 29, 2005, from http://www.iclass.info/iclass01.asp

IEEE Standards Department (2002). IEEE 1484. 12.1-2002, Learning object metadata standard. Retrieved September 29, 2005, from http://ltsc.ieee.org/wg12/files/LOM_1484_12_1_v1_Final_Draft.pdf

Open Knowledge Initiative (OKI). Retrieved September 29, 2005, from http://www.okiproject.org/

Richards, G., & Hatala, M. (2003). Semantic cobblestones: An interoperability mechanism for learning object repositories. In R. McGreal (Ed.), Online education using learning objects, (pp. 301-313). London: Routledge Falmer.

Richards, G. (2002). The challenges of the learning objects paradigm. Canadian Journal of Learning and Technology, 28(3), 3-10.

Simon, J., & Colin, J.N. (2004). Celebrate: A federated model for exchange of learning objects. In Proceedings of the World Conference on E-Learning in Corporate, Government, Healthcare, and Higher Education (ELEARN), (pp. 886-891), Washington, DC. Norfolk, VA: Association for the Advancement of Computing in Education.

Simon, B., Massart, D., Van Assche, F., Ternier, S., & Duval, E. (2005). Simple query interface specification. Draft CEN Workshop Agreement (CWA). Version 1.0 beta, Public Draft. Retrieved September 29, 2005, from http://nm.wu-wien.ac.at/e-learning/interoperability/SQI_V1.0beta_2005_04_13.pdf

Simon, B., Massart, D., Van Assche, F., Ternier, S., Duval, E., Brantner, S., et al. (2005, May). A simple query interface for interoperable learning repositories. In D. Olmedilla, N. Saito, & B. Simon, (Eds.), Proceedings of the WWW*05 Workshop on Interoperability of Web-Based Educational Systems, 143, 11-18, Chiba, Japan. Retrieved September 29, 2005, from http://sunsite.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-143/paper02.pdf

Van Assche, F., & Massart, D. (2004, September). Federation and brokerage of learning objects and their metadata. In Kinshuk, C.K. Looi, E. Sultinen, D. Sampson, I. Aedo, L. Uden, & E. Kahkonen, (Eds.), Proceedings of The Fourth IEEE International Conference on Advanced Learning Technologies, ICALT'04, (pp. 316-320), Joensuu, Finland. Los Alamitos, CA: IEEE Computer Society.

ZING (2004). Search/retrieve web service (SRW). Retrieved September 29, 2005, from http://lcweb.loc.gov/z3950/agency/zing/srw/

Acknowledgement

The work presented in this article is partially supported by the European Commission under the Information Society Technologies (IST) program of the 6th FP for RT & D project iClass contract IST-507922. The author is solely responsible for the content of this article. It does not represent the opinion of the European Commission nor is the European Commission responsible for any use that might be made of data appearing therein.

Notes

(1) Note that in some simple cases, when the location of a learning object is directly provided in its metadata, the second step is not necessary.

(2) Such as, for example, the IMS Digital Repository Interoperability (DRI) Specification (IMS Global Consortium, 2004), the Simple Query Interface (Simon, Massart, Van Assche, Ternier, & Duval, 2005), the Zing Search/Retrieve Web Service (SRW, [Zing, 2004]), or the Open Knowledge Initiative (OKI) Open Service Definition Interface (OSID, [Open Knowledge Initiative, 2004]).

(3) SQI was accepted by the CEN/ISSS workshop on Learning Technologies in June 2005 and is expected to become an official CEN Workshop Agreement in Fall 2005.

(4) Error codes are part of the SQI specification.

(5) One might regret the choice of the term "legacy system" which, in the context of the iClass project, refers to any non-iClass system.

(6) Not only the iClass content server works asynchronously but, when the adapter development started, the content server query language and result format were not chosen yet.

DAVID MASSART

European Schoolnet--Brussels, Belgium

[e-mail]