Construction d’un gateway SQI pour le réseau CELEBRATE

11 2.2 Framework pour l’interopérabilité entre dépôts d’objets d’apprentissage .... SQI , une spécification élaborée sous les auspices de « CEN/ISSS Workshop on Learning Technologies »,

Bruxelles, avril – septembre 2004

Table des matières

REMERCIEMENTS 4

RESUME 5

ABSTRACT 6

CHAPITRE 1 INTRODUCTION 7

1.1 Contexte du travail 7

1.2 Définitions 7

1.2.1 Objets d’apprentissage 7

1.2.2 Métadonnées d’objets d’apprentissage 7

1.2.3 Dépôts d’objets d’apprentissage 9

1.3 Problématique 9

CHAPITRE 2 LA SPECIFICATION SQI 11

2.1 Travaux concernés 11

2.2 Framework pour l’interopérabilité entre dépôts d’objets d’apprentissage 11

2.3 Spécification SQI 12

2.3.1 Introduction 12

2.3.2 Les méthodes de SQI 13

CHAPITRE 3 GATEWAY POUR CELEBRATE 16

3.1 Le réseau CELEBRATE 16

3.2 Gateway pour CELEBRATE 16

CHAPITRE 4 IMPLEMENTATION 19

4.1 Cas d’utilisation 19

4.2 Architecture générale et implémentation 21

CHAPITRE 5 CONCLUSION 27

ANNEXES 28

REFERENCES 33

Remerciements

Je tiens à remercier sincèrement M.David Massart de m’avoir encadré, de m’avoir soutenu

tout au long de mon stage

Je tiens aussi à remercier M Ulf Lundin, directeur de European Schoolnet, pour la gentillesse

qu’il m’avoir apportée

Je remercie vivement les membres de European Schoolnet de m’avoir accueilli avec bras

ouverts

J’exprime ma reconnaissance aux professeurs et aux personnes de l’Institut de la

Francophonie pour l’Informatique, de m’avoir apporté des connaissances et de l’aide

Ma reconnaissance s’adresse aussi à ma famille et mes amis Leurs encouragements ont

contribué énormément à l’achèvement du stage

Résumé

Avec l’épanouissement du marché de la formation en-ligne, de nombreux dépơts d’objets

d’apprentissage ont vu le jour Ces dépơts stockent une grande quantité de ressources

pédagogiques comme cours, tutoriels, livres électroniques, … dont la création est souvent très

cỏteuse L’échange et la réutilisation de ces ressources sont donc devenus une néccessité

indispensable qui a suscité des recherches sur l’interopérabilité entre dépơts

Malheureusement, ces dépơts emploient très souvent des formats de données propriétaires

De même, ils exposent leurs ressources à travers des protocoles d’accès plus ou moins

différents, ce qui empêche l’interopérabilité entre eux

Notre travail, encadré dans le projet CELEBRATE, consiste à réaliser un gateway (porte

d’echange) en se basant sur la spécification SQI (Simple Query Interface – Interface Simple

de Requêtes) SQI , une spécification élaborée sous les auspices de « CEN/ISSS Workshop on

Learning Technologies », est une tentative qui définit un ensemble de APIs ( Application

Programming Interface) dans le but d’assurer l’échange et la recherche des objets

d’apprentissage via une interface d’accès simple Ce gateway permettra à d’autres dépơts

d’objets d’apprentissage de découvrir les ressources de CELEBRATE ou inversement

Mots clés : e-formation, métadonnées d'objets d'opprentissage, interopérabilité,

objets d'apprentissage, Simple Query Interface, LOM

Abstract

With the development of the e-learning market, numerous learning object repositories have

appeared These repositories store a great number of educational resources such as courses,

tutorials, electronic books,… of which the creation is often expensive The exchange and

re-use of those resources have thus become an inevitable neccessity and have inspired research

works in the area of interoperability between learning repositories Unfortunately, learning

repositories usually use proprietary data formats Moreover, they expose their resources via

different access protocols, which impedes the interoperability between them

Our work, realised in the context of the CELEBRATE project, consists in implementing a

gateway based on the SQI specification ( SQI-Simple Query Interface ) SQI, a specification

elaborated under the auspices of « CEN/ISSS Workshop on Learning Technologies », is an

effort that defines a set of APIs (API - Application Programming Interface) aiming at

ensuring the exchange and search of learning objects via a simple acces interface This

gateway allows other learning object repositories to discover the resources of CELEBRATE

or vice versa

Index Terms: E-Learning, Repository Interoperability, Learning Object,

Learning Object Metadata, Simple Query Interface, LOM

Introduction

Chapitre 1 Introduction

1.1 Contexte du travail

CELEBRATE ("ContExt eLEarning with BRoAdband TEchnologies") est un projet de 5

millions d’euros qui s’étend sur une période de 30 mois et qui entre dans le cadre du

programme Technologies de la société de l’information de la Commission européenne [1]

L’objectif principal du projet est de créer un réseau européen d’apprentissage qui relie des

établissements scholaires en assurant l’échange et la recherche des ressources pédagogiques

entre eux Chaque établissement est considéré comme un dépôt contenant des ressources On

adopte une approche distribuée : les ressources sont éparpillées dans un dépôt central ou dans

les dépôts dans le réseau Au cœur du réseau est un système de courtage ( brokerage system )

auquel les clients se connectent Le système de courtage sert à acheminer les requêtes en

provenance d’un client à des dépôts appropriés ou renvoyer les résultats

Toutefois, CELEBRATE n’est malheureusement pas le seul système de ce genre Il existe

d’autres systèmes comme ARIADNE Knowledge Pool System, PROLEARN Repository

Portal, EDUTELLA Smart Space for Learning, Il est nécessaire donc de se mettre d’accord

sur une interface commune pour que ces systèmes « parlent la même langue » et se fassent

comprendre l’un par l’autre A cette fin, la spécification SQI est née

Ce stage se concentre sur l’analyse, la conception et l’implémentation d’une interface d’accès

selon la spécification SQI De plus, sa réalisation aide à détecter les imperfections de SQI et

alors contribue à l’améliorer parce que SQI est encore en phase de développement

1.2 Définitions

Il convient d’aborder quelques notions de base concernant SQI

1.2.1 Objets d’apprentissage

Selon la définition de IEEE-LSTC [2], un objet d’apprentissage est « entité numérique ou non

qui peut être utilisée, réutilisée ou référencée pendant des activités d’apprentissage assistées

par ordinateur » Les objets d’apprentissage peuvent être considérés comme des briques, et en

combinant ces briques on arrive à construire une maison C’est de cette façon que les

documents pédagogiques sont établis : ils sont une composition d’objets d’apprentissage La

forme d’un objet d’apprentissage peut être très variée: un texte, une image, un questionnaire,

une vidéo, Un objet d’apprentissage idéal se montre comme une entité autonome, ce qui

n’empêche pas qu’il fonctionne bien en étant incorporé à un tout L’objectif principal de la

conception des objets d’apprentissage est de faciliter leur migration entre différentes

documents, différents contextes Par exemple une séquence vidéo de deux minutes peut aussi

bien servir dans un cours d’informatique que dans le cadre d’un test, mais aussi cette

séquence peut être insérée dans différentes plateformes [3]

1.2.2 Métadonnées d’objets d’apprentissage

En général, métadonnées sont des données sur des données En formation en ligne, les

métadonées permettent de décrire la sémantique des diverses ressources pédagogiques et

Introduction

donc favoriser leur découverte et recherche Un autre intérêt des métadonnées est de

permettre à divers outils, divers systèmes de comprendre une ressource et de la réutiliser

Il nous faut aborder le standard LOM (Learning Object Metadata – Métadonnées d’objet

d’apprentissage) qui concerne l’implémentation du gateway mentionné ci-dessus

Le Standard LOM (Learning Object Metadata)

Le standard LOM est une création du groupe LTSC (Learning Training System Committe) au

sein de l’association IEEE (Institute of Electrical and Electronics Engineers) Il précise

d’abord la syntaxe et la sémantique des métadonées éducatives et puis il spécifie les

descripteurs, les attributs concrètes permettant la réalisation d’une fiche descriptive à partir

d’une ressource pédagogique ( on dit un binding en anglais ) Les descripteurs sont classés en

neuf catégories

Figure 1.1 Learning Object Metadata (Source: [4])

Introduction

Voici une brève description des neuf catégories de descripteurs :

• General : détermine les caractéristiques générales à savoir l’identifiant, la langue, le

titre,…

• Lifecycle : spécifie les caractéristiques du cycle de vie comme par exemple le numéro

de version, la date de création, date d’expiration, …

• Meta-metadata : des indications sur les attributs

• Technical : définit les aspects techniques tel que le format, la taille, …

• Educational : concerne les spécificités pédagogiques d’un document, tel que son type,

son niveau ou son public cible

• Rights : spécifie les droits de la propriété intellectuelle et les conditions d’utilisation

tel que le copyright, le cỏt…

• Relation : précise les liens entre des documents

• Annotation : permet d’ajouter des annotations, des commentaires et des informations

supplémentaires

• Classification : permet de localiser un document dans un système de classification

1.2.3 Dépơts d’objets d’apprentissage

Par une vue générale, un dépơt d’objets est une collection des objets Normalement, ces

objets sont identifiés et référencés à travers des métadonnées Les services de base d’un dépơt

sont :le stockage, l’exposition et la livraison des objets

Ces objets peuvent aussi bien être stockés dans un seul endroit que dispersés dans un système

distribué Dans le deuxième cas, le dépơt devrait se manifester comme un point d’accès

unique même si les objets sont stockés sur des serveurs à divers endroits, ce qui donne à

l’utilisateur un accès transparent au dépơt

1.3 Problématique

Grâce à de nombreux dépơts d’objets d’apprentissage créés récemment, les utilisateurs ont

accès à une ressource éducative énorme Toutefois, il n’est pas toujours facile de trouver les

objets dont on a besoin car ils se cachent dans des systèmes fermés ou propriétaires Ces

systèmes utilisent souvent des formats de données et des interfaces d’accès propriétaires Cela

rend ces systèmes disparates : il manque l’interopérabilité entre eux

On peut citer cinq raisons principales qui rendent l’interopérabilité entre des dépơts d’objets

d’apprentissage nécessaire [6]:

• La création des objets d’apprentissage est cỏteuse

• L’annotation des objets d’apprentissage est cỏteuse

• Une fois que les objets d’apprentissage sont créés, l’éditeur s’intéresse souvent

à les disséminer

• Les dépơts d’objets d’apprentissage n’ont pas assez d’objets d’apprentissage

• Les utilisateurs veulent choisir les objets à partir d’un grand nombre de dépơts

Selon [5], l’interopérabilité est “ la capacité de deux ou plusieurs systèmes ou composantes

d’échanger informations et d’utiliser les informations échangées » Ainsi, l’interopérabilité

Introduction

concerne deux aspects : la réutilisation et l’échange des données Pour assurer la réutilisation

des données, on a besoin une sémantique commune afin qu’un système puisse

« comprendre » les données provenant de l’autre Le deuxième aspect est garanti en

employant des protocoles communs qui rendent possible l’échange des données

La Spécification SQI

Chapitre 2 La Spécification SQI

2.1 Travaux concernés

Digital Repository Interoperability (DRI): Il s’agit d’une spécification de l’IMS Elle

propose recommendations pour les fonctionnalités d’interopérabilité les plus communes d’un

dépôt qui sont «rechercher/exposer», «ramasser/exposer», «alerter/exposer»,

«soumettre/stocker», «demander/délivrer» Elle laisse pourtant implémenteurs trop d’options

à choisir pour effectivement régler l’interopérabilité

Z39.50: C’est un protocole principalement utilisé dans des systèmes de bibliothèques Il a son

propre langage de requête qui se base sur un ensemble d’attributs prédéfinis ainsi que sur des

syntaxes de jeu de données Les récentes technologies web comme XML ou XQUERY ne

sont pas présentes dans Z39.50 Des efforts sont en cours pour y incorporer XML comme

format commun des échanges de données

SRW (Search/Retrieve Web Service protocol) vise à promouvoir l’interopérabilité entre bases

de données réparties et ressources par l’utilisation d’un framework commun SRW emploie le

langage de requête assez puissant CQL SRW ne supporte que des requêtes synchones

Edutella est un réseau paire-à-paire pour le partage de ressources éducatives Les ressources

dans les dépôts sont décrites en RDF Edutella emploie le langage de requête QEL approprié

à ressources décrites en RDF Les requêtes asynchones sont supportées par un méchanisme

« écouteur de résultats» qui est aussi utilisé dans SQI

EduSource est un projet qui suit IMS Digital Repository Specification Il emploie un langage

de requête propriétaire ECL (EduSource Communication Language )

Ariadne propose une interface de requête basée sur service web Cette interface ne s’intéresse

qu’à des requêtes synchrones

2.2 Framework pour l’interopérabilité entre dépôts d’objets d’apprentissage

CEN/ISSS a proposé un framework pour l’interopérabilité entre dépôts d’objets

d’apprentissage [5] Ce framework spécifie un ensemble d’interfaces fournissant les services

pour construire un réseau de noeuds éducatifs Dans ce framework, les services sont divisés

en deux couches : les services noyau et les services d’application Les services noyau

s’impliquent dans l’identification des dépôts d’objets d’apprentissage, dans l’authentification

des utilisateurs et des dépôts, ou dans la gestion des sessions En se situant au-dessus des

services noyau, les services d’application sont ceux qui vraiment apportent l’interopérabilité

Quelques services dans cette couche sont service de fourniture, service de requête, service de

contrat, service de livraison, …

La Spécification SQI

Figure 2.1: framework pour l’interopérabilité entre dépôts d’objets d’apprentissage

Les services de deux couches fonctionnent en se reposant sur un service de messagerie

comme XML-RPC, RMI, SOAP, … Le service de messagerie a recours lui-même aux

protocoles réseau comme HTTP, TCP/IP, SMTP, … pour transférer les données

Figure 1.2 : Les couches dans le framework pour l’interopérabilité entre dépôts d’objets d’apprentissage

2.3 Spécification SQI

2.3.1 Introduction

La spécification SQI est née dans le cadre des travaux du framework pour l’interopérabilité

entre dépôts d’objets d’apprentissage ci-dessus mentionné Elle introduit une interface

Core Services Applications (e.g Query)

Network Architecture (e.g HTTP, SMTP; TCP/IP, …)

Semantic Model

Service de messagerie

Services noyau (Gestion des sessions, authentification, …)

Applications (Requête,…)

Architecture Réseau

Modèle sémantique

La Spécification SQI

couvrant trois services : authentification, gestion des sessions (service noyau) et requête (

service d’application )

SQI supporte aussi bien les requêtes synchrones que celles asynchrones car elle a comme but

de faciliter l’interopérabilité entre des systèmes pouvant être extrêmement hétérogènes La

mode de requête asynchrone se montre appropriée quand il s’agit de faire une requête à un

réseau hétérogène paire-à-paire ó la possibilité que des systèmes concernés sont

« suspendus » est très forte La mode synchrone est utile lorsqu’on fait des requêtes de façon

locale, c’est à dire des requêtes client-serveur simple

D’ailleurs, SQI est neutre en termes de langages de requête et de formats des résultats En

réalité, les dépơts stockent les métadonnées utilisant divers types de support comme base de

données, système de fichiers, avec les formats de métadonnées différents (eg X ML,

RDF,…) Les deux systèmes impliqués dans une requête (le système « source » et le système

« cible ») doivent avant tout se mettre d’accord sur les langages de requête et sur les formats

des résultats Ceci nous offre une façon très flexible de changer le langage de requête et le

format de résultats en cours d’exécution Il faut quand même que les dépơts possèdent des

« wrappers » pour traduire entre les formats

SQI est conçu pour être extensible Pour cela, les auteurs ont choisi l’approche de minimiser

le nombre des paramètres dans les méthodes Par conséquent, le nombre des méthodes

devient grand On n’a heureusement pas à appeler toutes les méthodes définises dans SQI

pour achever une requête Dans ce cas, les valeurs défauts sont utilisées

Figure 3 montre les étapes d’une requête ó le dépơt A recherche des ressources au dépơt B

Dans ce scénario, on s’intéresse à l’échange des données plutơt qu’à la gestion des sessions

Tout d’abord, le dépơt « source » A formule une requête en langage de requête commun et

l’envoie au dépơt « cible » B Ensuite, B traduit la requête en langage de requête local et

l’exécute Lors que les résultats ( au format local ) sont produits, B les renvoie à A en les

traduisant au format de résultats commun Les composants « wrapper » servent de traducteurs

entre les langages de requête et les formats de résultats

Simple Query Interface Component

Learning Repository B (Target)

Learning Object Metadata

Common Query Language

Results in Local Format

Results in Common Format

Local Query Language Simple Query

Interface Component

Learning Repository A (Source)

Learning Repository B (Target)

Learning Object Metadata

Common Query Language

Results in Local Format

Results in Common Format

Local Query Language Simple Query

Interface Component

Learning Repository A (Source)

Figure 2.3 : Communication entre deux dépơts de SQI (Source : [7])

2.3.2 Les méthodes de SQI

Implémentée à la cible et appelée par la source

Implémentée à la source et appelée par la cible

Configuration des requêtes

setQueryLanguage X

La Spécification SQI

setResultsFormat X

setMaxQueryResults X setMaxDuration X

Interface de requête synchrone

Les méthodes sont catégorisées en 5 groupes : gestion des sessions ,configuration des

requêtes, interface de requête synchrone, interface de requête asynchrone, et gestion des

résultats

L’établissement d’une connexion entre la source et la cible se fait grâce à createSession ou

createAnonymousSession qui créent une session La source doit fournir à la cible nom

d’utilisateur et mot de passe ou d’autres crédentiels en vue de créer une session Cette façon

d’identifier une source permet la cible, d’une part, de refuser les sources inconnues et d’autre

part, d’établir une politique de requêtes Une fois créée, une session peut être utilisée dans

plusieurs requêtes Lors que la source appelle destroySession la session est supprimée Si la

source n’appelle pas destroySession, la session est supprimée après une durée de time-out La

source peut préciser la durée de time-out, le défaut pour time-out est 30 minutes

Les méthodes du groupe configuration des requêtes servent à préciser la valeur de divers

paramètres impliqués dans une session comme le langage de requêtes, le nombre des résultats

dans un jeu de résultats, la durée maximale d’une requête, le format des résultats

Dans le cas d’une requête synchrone, la méthode synchronousQuery est invoquée Le nombre

maximum des résultats dans un jeu de résultat est limité par setResultsSetSize La méthode

getTotalResultsCount donne le nombre total des résultats tandis que le reste des résultats à la

cible sont retirés lors que la source appele getAdditionalQueryResults

Les résultats d’une requête asynchrone sont retournés à la source quand la cible appele

queryResultsListener La méthode setSourceLocation est utilisée afin que la cible connaisse la

La Spécification SQI

localisation de la source

Gateway pour CELEBRATE

Chapitre 3 Gateway pour CELEBRATE

3.1 Le réseau CELEBRATE

Comme mentionné dans chapitre 1, CELEBRATE est un réseau européen de nœuds

éducatifs Un nœud éducatif ici est en fait un système de gestion de contenus pour

l’apprentissage Au cœur du réseau se trouvent un serveur de messagerie (messaging server)

et un système de courtage (brokerage system) dont le role est d’acheminer les requêtes vers

de bons destinataires Chaque nœud se muni d’un ELN Client qui est une couche logiciele

servant à connecter au système de courtage Les étapes d’une requête peuvent être résumées

comme suit :

- Un nœud (on dit « la source » ) soumet une requête au serveur de messagerie

- Le serveur de messagerie transite la requête vers le système de courtage

- Le système de courtage valide cette requête et l’envoie ensuite aux nœuds

appropriés

- Ces nœuds éxecutent la requête et envoient les résultats au système de

courtage

- Le système de courtage passe ces résultats à la source

Figure 3.1: La recherche d’objets d’apprentissage dans le réseau CELEBRATE

3.2 Gateway pour CELEBRATE

Il existe actuellement en Europe ( et dans le monde ) plusieurs réseaux de nœuds éducatifs par

Messaging Server

Brok System ELN Client

ELN Client

ELN Client LMS/LCMS