Contrats pour la recherche fédérée des métadonnées d’objets dapprentissage

Institut de la Francophonie pour l'Informatique

MÉMOIRE DE FIN D’ÉTUDES

Titre :
Contrats pour la recherche fédérée
des métadonnées d’objets d'apprentissage

Soutenu par :
LE Tien Dung
Sous la direction de :
Dr. David Massart

Bruxelles, novembre 2003


Contrats pour la recherche fédérée

2


Contrats pour la recherche fédérée

Remerciements
Je tiens tout d'abord à remercier M. David Massart pour avoir bien
voulu diriger mon stage au European Schoolnet, pour avoir bien voulu
m'accueillir au sein de l'équipe CELEBRATE et de ses conseils qu'il m'a
apportés.
Merci à M. Ulf Lundin pour son encadrement, ses conseils, son
soutien dévoués ainsi que pour sa gentillesse tout au long du stage. Ce
travail n'aurait pu être accompli sans son aide.

Merci aux membres de European Schoolnet : Mme Brigitte Parry,
Mme Sophie Vandeputte, M. Dietmar Baur… pour leur accueil, leur aide
et leur bonne humeur tout au long de mon stage.
Ma reconnaissance s’adresse aussi aux professeurs à l’Institut de
la Francophonie pour l’Informatique. Leurs cours m’ont apporté des
connaissances et des suggestions qui sont utiles pour mon stage.
Finalement, j'exprime mon entière reconnaissance à ma femme,
ma famille et mes amis pour leur soutien, leur aide et leurs
encouragements.

3


4

Contrats pour la recherche fédérée

Résumé
Nous proposons une approche innovante de l’utilisation des
technologies d’eLearning dans l’enseignement. Cette méthode est
appliquée dans le projet CELEBRATE qui a pour objectif de construire
un réseau européen d'apprentissage permettant de chercher et d’échanger
des objets d’apprentissage entre les membres du réseau. La partie
principale de ce réseau est le système de courtage auquel les membres, à
savoir les clients, se connectent.
Pour chercher des métadonnées d'objets d'apprentissage, nous
utilisons la recherche fédérée qui est déterminée par les contrats des
membres. Le contrat supporte le langage de requête des métadonnées
d'objets d'apprentissage, restreint les informations échangées entre
les membres. Le langage de requête est construit par des comparaisons

grâce aux trois éléments suivants : l’opération, le champ et la valeur. Et
nous aussi souhaitons que le contrat soit facilement distribué par
n'importe quels protocoles donc les données sont présentées au format
XML.
Mots clés : eLearning, métadonnées d'objets d'opprentissage,
objets d'apprentissage, recherche fédérée, XML.


5

Contrats pour la recherche fédérée

Abstract
We propose an innovative approach to teaching using E-Learning
technologies. This approach is applied in the CELEBRATE project, the
support system for a European Learning Network of virtual learning
environments capable of exchanging learning objects between its
members. The backbone of this network is the brokerage system to which
LMS/LCMS (or Clients) connect.
To search learning object metadata, we use a federated search
determined by members’ contracts. These contracts support query
language, reduce exchanged information in the network. The building
blocks of LOM queries are comparisons that consist of 3 elements: an
operator, a field and a value. And we wish the contract is easily
distributed by any protocols thus the data are presented at format XML.
Index Terms: E-Learning, Federated Search, Learning Object,
Learning Object Metadata, XML.


Contrats pour la recherche fédérée

6

Table des matières
Remerciements ...................................................................................................................... 3
Résumé .................................................................................................................................. 4
Abstract ................................................................................................................................. 5
Table des matières ................................................................................................................. 6
Acronymes............................................................................................................................. 7
Chapitre 1 : Introduction ................................................................................................... 8
1. Problématique........................................................................................................ 8
2. Environnement de travail ...................................................................................... 9
2.1. European Schoolnet....................................................................................... 9
2.2. Projet CELEBRATE ..................................................................................... 9
3. Objectifs du stage ................................................................................................ 10
4. Les contraintes pratiques ..................................................................................... 10
Chapitre 2 : Système de courtage .................................................................................... 11
1. Système de gestion du contenu d’apprentissage ................................................. 11
1.1. Objets d'apprentissage ................................................................................. 11
1.2. Métadonnées d’objets d'apprentissage ........................................................ 11
1.3. Système de gestion du contenu d’apprentissage ......................................... 12
2. Réseau d'apprentissage........................................................................................ 13
3. Système de courtage............................................................................................ 14
Chapitre 3 : Contrats pour la recherche fédérée.............................................................. 15
1. Recherche fédérée ............................................................................................... 15
2. Contrat................................................................................................................. 18
2.1. Structure du contrat ..................................................................................... 19
2.2. Schéma du contrat ....................................................................................... 19
3. Réalisation ........................................................................................................... 26
3.1. Conception................................................................................................... 26

3.2. Base de données XML ................................................................................ 29
4. Implémentation.................................................................................................... 31
4.1. Architecture Java pour la liaison avec XML (JAXB) ................................. 31
4.2. Connexion à la base de données .................................................................. 34
4.3. Interfaces ..................................................................................................... 35
4.4. Sécurité........................................................................................................ 36
5. Résultat ................................................................................................................ 36
Chapitre 4 : Conclusion................................................................................................... 37
1. Travail réalisé...................................................................................................... 37
2. Perspective........................................................................................................... 37
Références ........................................................................................................................... 38
Annexe 1: Les diagrammes de classes ................................................................................ 39
Annexe 2: Les interfaces ..................................................................................................... 44
Annexe 3: Profil d'application des métadonnées d’objets d'apprentissage ......................... 47


7

Contrats pour la recherche fédérée

Acronymes
Terme

En Français

En anglais

EUN

European Schoolnet

European Schoolnet

ENT

Espace Numérique de Travail

Virtual Learning Environment

SC

Système de Courtage

Brokerage System

XML

Langage Extensible de Balisage

Extensible Mark-up Language

OA

Objet d'Apprentissage

Learning Object

MOA

Métadonnées d'Objets

d'Apprentissage

Learning Object Metadata

DOA

Dépôts d’Objets d’Apprentissage

Learning Object Repositories

REA

Réseau Européen d'Apprentissage

European Learning Network

SQL

Langage de requêtes structuré

Structured Query Language

SGCA

Système de Gestion du Contenu
d’Apprentissage

Learning Content Management
System

SGC

Système de Gestion du Contenu

Content Management System

SGA

Système de Gestion d’Apprentissage

Learning Management System


Contrats pour la recherche fédérée

8

Chapitre 1 : Introduction
1. Problématique
De nos jours, l’utilisation de nouvelles technologies se répand rapidement dans
l’enseignement. Le monde enseignant se montre souvent partagé entre l’enthousiasme pour
ces nouveaux moyens d’accéder à la connaissance. A partir de petits fragments
indépendants d'informations, nous constituons des objets d'apprentissage ("learning
objects") qui sont facilement échangés entre les dépôts d’objets d’apprentissage ("learning
object repositories"). Tous les objets d'apprentissage contiennent des renseignements ou
des métadonnées pour aider à les cataloguer facilement et à évaluer leur pertinence. Dans
la plupart des réseaux basés sur le modèle client/serveur, les métadonnées d'objets
d'apprentissage sont stockées dans le dépôt central mais quand une approche distribuée est
choisie, les métadonnées peuvent être répétés dans des dépôts différents.
Nous proposons une nouvelle approche que les membres d’une fédération d’espace

numérique de travail (ENT) peuvent proposer leurs métadonnées au dépôt central ou les
stocker dans leur dépôt local. Un utilisateur d’ENT (par exemple, un professeur ou un
élève) demande à connaître tous les dépôts actuellement disponibles au sein du réseau
européen d'apprentissage dans lesquels les objets d'apprentissage remplissent ses critères.
Le contrat d’un client d’ENT exprime les types de ses objets d'apprentissage et sa
capacité de réponse aux requêtes envoyées par les autres. Autrement dit, le contrat limite
les éléments de métadonnées utilisés dans ses recherches et ses réponses. Ce contrat utilise
le profile d’application de métadonnées d’objets d'apprentissage basé sur la norme IEEE
1484.12.1-2002 [4].


Contrats pour la recherche fédérée

9

2. Environnement de travail
2.1.

European Schoolnet
European Schoolnet (EUN) est un réseau international de plus de 20 ministères de

l'Éducation européenne dont l'objectif majeur est le développement des méthodes
d'apprentissage pour les professeurs et les élèves d'Europe. Aux chefs d’établissements et
professionnels de l’éducation, EUN offre une vision d’ensemble de l’utilisation
pédagogique des technologies de l’information et de la communication pour
l’enseignement en Europe. EUN atteint cet objectif en communiquant et en échangeant des
informations à tous les niveaux de l'enseignement par le biais de technologies innovantes et
en offrant un portail aux réseaux scolaires nationaux et régionaux.

2.2.

Projet CELEBRATE
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.
L’objectif principal de ce projet est de créer une approche innovante de l’utilisation des
technologies d’eLearning dans l’enseignement basée sur la vision de ce que seront les
contenus électroniques de demain (ressources, services et outils de communication). Ce
projet offrira aux établissements scolaires une base de données de contenus en ligne,
laquelle inclura des supports d’apprentissage multimédias, à savoir des objets
d’apprentissage (OAs).
L’objectif clé du projet est, d’une part, d’analyser comment une nouvelle
génération de systèmes de gestion de contenus pour l’apprentissage (SGCA) mis au point
par divers professionnels commerciaux pour traiter les OA et, d’autre part, de tester
l’interopérabilité de ces systèmes dans un site de démonstration réel. CELEBRATE jouera
le rôle de catalyseur pour l’industrie européenne des contenus eLearning (la chaîne de
valeurs complète inclut propriétaires de contenus, éditeurs, diffuseurs, réseaux scolaires
nationaux et fo urnisseurs commerciaux de plate-formes technologiques).
Le système de courtage auquel les clients se connectent est une partie principale du
réseau européen d'apprentissage. Pour se connecter au système, les clients doivent
s'enregistrer. Les clients enregistrés authentifient des transactions et des messages par les


Contrats pour la recherche fédérée

10

appels de méthodes distantes en utilisant JAX-RPC. On ne permet aucun échange direct
entre les clients, excepté ceux explicitement autorisés par le système.

3. Objectifs du stage
Ce stage se focalise sur l’analyse et la mise en œuvre d’un module de système de
courtage concernant des contrats entre des membres du réseau EUN. Concrètement, mes
travaux s’articulent sur trois grands axes :
•

Etude de la recherche fédérée, des requêtes, des métadonnées d'objets
d'apprentissage, et des services fournis par le système de courtage.

•

Analyse des contrats et de la procédure pour avoir l’accord entre un client
d’ENT et l’administrateur.

•

L’implémentation en utilisant de nouvelles technologies comme la base de
données XML Oracle 9i, XPATH, JAXB.

4. Les contraintes pratiques
Quelques contraintes ont été apportées au sujet :
•

Les contrats doivent répondre aux demandes du projet.

•

Il faut avoir une interface graphique simple et conviviale, et bien appliquer
de nouvelles techniques comme la base de données XML, le langage

XPATH accès aux informations, l’architecture Java pour la liaison avec
XML (JAXB).

•

Il faut vérifier la permission d’un utilisateur avant de réaliser ses demandes.


Contrats pour la recherche fédérée

11

Chapitre 2 : Système de courtage
1. Système de gestion du contenu d’apprentissage
L’enseignement connaît une tendance vers la création de contenu sous la forme
d’objets d’apprentissage indépendants qui peuvent être stockés dans des dépôts d’objets,
partagés entre les établissements d’enseignement et utilisés de façons diverses. Les objets
peuvent être stockés et échangés par des systèmes de gestion du contenu d’apprentissage
(SGCAs) qui nous permettent d’élaborer et de fournir un contenu didactique.

1.1.

Objets d'apprentissage
Selon Wiley, un objet d’apprentissage (OA) est "toute ressource électronique qui

peut être utilisée à nouveau pour venir en support à l’apprentissage". Plus précisément, un
objet d’apprentissage est un granule de formation en principe réutilisable et réagençable
selon différents objectifs ou environnements. Autrement dit, un bon objet d’apprentissage
est complet en soi et aborde tous les aspects d’un point particulier de connaissance.
Par conséquent, des éléments tels qu’une image, un jeu interactif, une vidéo

numérique, un fichier multimédia, un texte éducatif peuvent être considérés comme un
objet d’apprentissage. On peut essayer des objets d’apprentissage sur le site
. Tous ces objets se servent de la facilité de l’apprentissage.
En utilisant des objets d’apprentissage, les professeurs peuvent fournir des
ressources pédagogiques pour que les étudiants puissent choisir les objets qui répondent à
leurs besoins individuels.

1.2.

Métadonnées d’objets d'apprentissage
Les métadonnées sont des descriptions des données, les métadonnées d’objets

d'apprentissage (MOA) sont un ensemble de descripteurs du contenu de l'objet
d'apprentissage. Tous les objets d'apprentissage contiennent des renseignements à leur sujet
pour aider à les cerner et à les cataloguer facilement et à évaluer leur pertinence. Ces


Contrats pour la recherche fédérée

12

métadonnées nous permettent de faciliter la réutilisation des objets d'apprentissage et le
partage des ressources.
Au mois de juillet 2002, l’institut des ingénieurs électriciens et électroniciens
(IEEE) a proposé un ensemble normalisé de métadonnées pour les objets d'apprentissage.
Les données décrivant les objets d'apprentissage sont groupées dans neuf catégories telles
que la catégorie de la généralité, la catégorie du cycle de vie, la catégorie des métamétadonnées (information sur elle-même), la catégorie de la technique, la catégorie de
l’éducation, la catégorie du droit, la catégorie de la relation, la catégorie de l'annotation, la
catégorie de la classification.
Le projet CELEBRATE utilise un ensemble de métadonnées basé sur la norme

IEEE LOM qui contient de nouveaux éléments définis par le comité CELEBRATE. En
fait, cet ensemble est le profil d'application des métadonnées d’Objets d'apprentissage qui
définit les éléments obligatoires, recommandés, et optionnels. Le lecteur peut consulter
l'annexe 3 pour connaître la liste de MOA.

1.3.

Système de gestion du contenu d’apprentissage
Un système de gestion du contenu d’apprentissage (SGCA) est un système qui

permet de créer, valider, publier et gérer des contenus de formation. Il se compose de deux
systèmes : un système de gestion d’apprentissage (SGA) et un système de gestion du
contenu (SGC).
Un SGA, considéré dans bien des cas comme le cœur du dispositif eLearning, a
pour but la gestion et l'organisation de la formation : Individualisation et distribution des
parcours de formation; Gestion des apprenants; Suivi de la réalisation des parcours
d'apprentissage; et Mise à disposition d'outils coopératifs pour la relation tuteur/apprenant.
Un SGC a pour but de simplifier la création et la gestion du contenu en ligne. Il
permet une meilleure fréquence des mises à jour des ressources déjà publiées. Cela repose
sur deux principes essentiels :
•

La forme est séparée du fond : ainsi les auteurs doivent-il pouvoir se
concentrer uniquement sur leur contenu. Ils disposent pour ce faire de
modèles de présentation prédéfinis spécifiques à chaque élément qui
compose le document (en -tête, format du titre, emplacement d'une image,


Contrats pour la recherche fédérée

13

intégration d'un fichier multimédia etc.). L'auteur intègre son contenu dans
cette ossature.
•

Il induit des procédures de publication des contenus. Deux étapes précèdent
la publication : la création, la validation. Un SGC permet de les organiser
selon les règles propres à l'entreprise.

Le SGCA permet de créer des bibliothèques de OAs, une vraie bibliothèque de
grains de contenu de formation indépendants, qui peuvent être réutilisés et associés
indifféremment les autres. Le SGCA pourra alors, pour un apprenant donné, gérer la
distribution et le suivi de l'apprentissage à un niveau très fin. La seconde fonction des
SGCA est la gestion des procédures et des flux de publication. Sur le même modèle que le
SGC, le SGCA assure la mise en place d'une organisation garantissant le respect des règles
de publication. Après la création d'un OA, l'auteur le soumet à la procédure de validation.
S'il est approuvé, il sera publié et donc disponible, sinon il sera rejeté pour être modifié.
Les nouvelles fonctionnalités des SGCA permettent de s'orienter vers de nouvelles
pratiques dans la création de contenus pédagogiques. Ils favorisent le partage du travail de
création simplifient les mises à jour des ressources déjà publiées.

2. Réseau d'apprentissage
Les objets d'apprentissage sont stockés dans des machines et répartis à travers des
réseaux. Les métadonnées donnent une structure à l'étiquetage ou au référent d'objets.
Auparavant, il n’existe que deux types de stockage des métadonnées des OAs : Le modèle
centralisé (utilisé par la plupart des systèmes basés sur l’architecture client/serveur [2]) ou
le modèle décentralisé (comme le "POOL, POND et SPLASH" [7]).
Nous suggérons une nouvelle approche que les membres du réseau peuvent
proposer leurs métadonnées au dépôt central ou les stocker à son dépôt local. La recherche

fédérée a pour but de trouver les bons MOAs du réseau satisfaisant à certains critères. Un
de facteurs pour améliorer la performance de telle recherche est l’utilisation des contrats
entre les membres. Dans le chapitre suivant, on expliquera les contrats en détail.


Contrats pour la recherche fédérée

14

3. Système de courtage
Dans le réseau européen, nous utilisons un système de courtage pour permettre aux
membres de se communiquer. En effet, ce système a pour d’échanger des OAs et de
chercher des MOA. Ce système se compose de deux parties principales : "le client du
réseau" et "la gestion des services". "La gestion des services" contrôle la recherche et
l’échange des objets tandis que "le client du réseau" intégré dans le système de système de
gestion du contenu d’apprentissage aide les membres à se connecter au réseau européen.
Le diagramme de classes "client du réseau européen" figure suivant :

Figure 1.

Les classes du "Client du Réseau européen"


Contrats pour la recherche fédérée

15

Chapitre 3 : Contrats pour la
recherche fédérée
Dans le réseau européen d'apprentissage, nous proposons une recherche fédérée

basée sur les contrats des membres qui désirent rechercher des métadonnées d’objets
d’apprentissage. Chaque membre utilise l’interface "ELN Client" qui lui permet de se
connecter au système.

1. Recherche fédérée
La recherche fédérée permet d’identifier les bons dépôts dans le réseau européen
d'apprentissage. Voici, ci-dessous une simulation d’une recherche en supposant qu’il y a 3
membres (GiuntiLabs, "Digital Brain", "Sanoma WSOY"), le dépôt central et le système
de courtage ("Brokage System"). Les boîtes blanches représentent les membres du réseau
tandis que les boîtes bleues représentent les clients du réseau ("ELN Clients") qui
permettent de se connecter facilement au serveur. Dans cet exemple, le "Digital Brain"
envoie une requête au système de courtage. Une telle requête s'appelle "LOM Query
Request" et est présentée par une flèche bleue.

Figure 2.

"Digital Brain" envoie une requête au SC


16

Contrats pour la recherche fédérée

Le SC vérifie la question (le format est bon? les qualifications sont correctes?, la
permission dépasse la limite de "Digital Brain") avant de l’envoyer comme une "Checked
LOM Query Request" aux autres membres qui sont d'accord sur le processus de telles
questions (figure 2). Ces requêtes sont présentées par les flèches pleines.
Quand un membre reçoit une telle requête, il cherche dans son dépôt local et envoie
le résultat "LOM Query Result" au SC (figure 3). Ensuite, le SC envoie le résultat
"Checked LOM Query Result" à l'auteur de la requête originale après avoir vérifié. Dans

ce cas, GiuntiLabs envoie son résultat "LOM Query Result" au SC (figure 4). La même
chose se passe avec "Sanoma WSOY" et le dépôt central.

Figure 3.

Figure 4.

SC envoie les requêtes aux autres.

GiuntiLabs envoie son résultat au SC.


17

Contrats pour la recherche fédérée

Figure 5.

SC envoie le bon résultat.

On voit que l’utilisateur peut trouver des objets d’apprentissage non seulement dans
le dépôt local, dans le dépôt central mais dans tous les dépôts du réseau.


Contrats pour la recherche fédérée

18

2. Contrat
Un dépôt peut contenir un grand nombre d’OAs mais normalement ces OAs sont

groupés dans certains types. Sans un contrat, les informations échangées entre un client et
le SC sont énormes. C’est la raison pour la quelle, il faut que chaque client ait ses contrats
pour décrire ses MOA. Par exemple, on ne cherche pas des OAs en français à un client
ayant des ressources en anglais.
Le contrat est encore utilisé dans le langage de requêtes des MOA, un des facteurs
les plus importants pour exécuter une recherche. Le composant de bas est la comparaison
qui se compose de trois éléments :
•

Opération : égale à (eq), non égal à (ne), inférieur à (le), supérieur à (gt),
inférieur ou égal à (le), supérieur ou égal à (ge).

•

Champ : Un élément dans la liste de MOA.

•

Valeur : Le type de cette valeur doit correspondre à l’opération.

Les types se groupent dans un des trois cas suivants:
•

Le type numérique : La valeur est un numéro. Par conséquent, toutes les
opérations sont applicables. Par exemple, l’expression "la taille ne doit pas
être supérieure à 30000" est présente comme "taille (LOM 4.2) < = 30000".

•

Le type alphanumérique : Il est possible de comparer des valeurs (toutes les

opérations peuvent être utilisées) mais il faut établir un ordre de ces valeurs.
Par exemple, on a: "very easy" < "easy" < "medium" < "difficult" < "very
difficult".

•

Le reste : Dans ce cas, seuls l’opération "eq" et l’operation "ne" sont
applicables. Par exemple, le langage est égal ou non égal à "français". Un
langage ne peut être inférieur ou supérieur à "anglais".


Contrats pour la recherche fédérée

2.1.

19

Structure du contrat
Un contrat limite les interactions entre un client et le système de courtage. D’abord,

il définit les services que le client fournit. Récemment, nous définissons deux types de
services :
•

"Checked LOM Query Request" : être capable de traiter des requêtes des
MOA.

•

"Checked LO Use Authorize Request" : permettre de télécharger ses OAs.

Le contrat indique également les types de requêtes que le SC permet à ce client
d’envoyer. Les types sont :
•

"LOM Query Request"

•

"LO Use Authorize Request"

•

"LO Use Execute Request"

•

"LO Use Acknowledge Request"

•

"LOM Publish Request"

•

"LOM Update Request"

•

"LOM Delete Request"

•

"LOM Compliance Test Request"

Chaque type de requêtes est associé avec un filtre permis au client indiquant les
types d’OAs (les métadonnées). C’est à dire, le contrat indique un sous-ensemble de MOA
pour chaque requête. Par exemple, un contrat indique le client n’exécute que des objets
dont les tailles sont inférieures ou égales à 30.000 Kilo-octet.
Il est possible que différentes requêtes partagent le même filtre, donc elles sont
groupées dans une clause unique. Une clause se compose d’une liste de requêtes et d’un
filtre correspondant.

2.2.

Schéma du contrat
La description d’un contrat par encodage XML permet facilement de faire des

échanges entre des environnements. Donc un XML schéma est utilisé pour spécifier cette
structure.


Contrats pour la recherche fédérée
a)

20

Introduction au schéma XML
Le schéma XML est une norme du W3C permettant de créer des modèles de

documents XML. Ces modèles permettent de décrire la structure de ces documents (quels
tags et arguments peuvent être utilisés, dans quel ordre, ...). Il est possible de créer autant
de documents XML à partir d'un seul modèle.
Logiquement, il faudrait toujours commencer par définir un schéma avant d'écrire
des documents XML qui en seront dérivés. Toutefois, il est tout à fait possible de faire un
Schema d'après un document existant, comme dans l'exemple ci-dessous.
Voici un document XML de base :
<étudiant>
<nom>Le</nom>
Tien Dung</prénom>
7</promotion>
</étudiant>

Voici le schéma peut être employé pour générer un tel catalogue d’étudiants.
<xs:schema xmlns:xs=" />elementFormDefault="qualified">
<xs:element name="étudiant">
<xs:complexType>
<xs:sequence>
<xs:element name="nom"/>
<xs:element name="prénom"/>
<xs:element name="promotion"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>

b)

Schéma du contrat
Nous proposons le schéma ci-dessous définissant des documents XML de contrats.

<xs:schema targetNamespace=" />xmlns:xs=" xmlns:jaxb=" />xmlns:xjc=" />xmlns:filter=" />xmlns=" elementFormDefault="qualified"
attributeFormDefault="unqualified" version="0.2" jaxb:extensionBindingPrefixes="xjc"
jaxb:version="1.0">
<xs:import namespace=" />schemaLocation=" /><!-- =================== -->
<!-- Element definition-->
<!-- =================== -->
<xs:element name="contract" type="ContractType">
<xs:annotation>
<xs:documentation>Contract element</xs:documentation>
</xs:annotation>


Contrats pour la recherche fédérée
</xs:element>
<xs:element name="clause" type="ClauseType"/>
<xs:element name="services" type="ServicesType"/>
<xs:element name="service" type="ServiceType"/>
<xs:element name="requests" type="RequestsType"/>
<xs:element name="request" type="RequestType"/>
<xs:element name="client" type="ClientType"/>
<!-- =================== -->
<!-- Complex Types definition-->
<!-- =================== -->
<xs:complexType name="ServicesType">
<xs:sequence>
<xs:element ref="service" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="ServiceType">
<xs:attribute name="type" use="required">

<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="CheckedLOMQueryRequest"/>
<xs:enumeration value="CheckedLOUseAuthorizeRequest"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
<xs:complexType name="RequestsType">
<xs:sequence>
<xs:element ref="request" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="RequestType">
<xs:attribute name="type" use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="VocabularyRequest"/>
<xs:enumeration value="LOMQueryRequest"/>
<xs:enumeration value="LOUseAuthorizeRequest"/>
<xs:enumeration value="LOUseExecuteRequest"/>
<xs:enumeration value="LOUseAcknowledgeRequest"/>
<xs:enumeration value="LOMPublishRequest"/>
<xs:enumeration value="LOMUpdateRequest"/>
<xs:enumeration value="LOMDeleteRequest"/>
<xs:enumeration value="LOMComplianceTestRequest"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>

<xs:complexType name="ClientType">
<xs:attribute name="id" type="xs:NMTOKEN" use="required"/>
<xs:attribute name="description" type="xs:string" use="required"/>
</xs:complexType>
<xs:complexType name="ClauseType">
<xs:sequence>
<xs:element ref="requests"/>
<xs:element ref="filter:filter" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="ContractType">
<xs:sequence>
<xs:element ref="client"/>

21


22

Contrats pour la recherche fédérée
<xs:element ref="services"/>
<xs:element ref="clause" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="schemaVersion" type="xs:decimal" use="required" fixed="0.2"/>
<xs:attribute name="contractId" type="xs:string" use="required"/>
<xs:attribute name="contractType" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="permanent"/>
<xs:enumeration value="temporary"/>

</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
<!-- =================== -->
<!-- Simple Types definition -->
<!-- =================== -->
</xs:schema>

L’image suivante est de faciliter la compréhension.

Figure 6.
c)

Schéma du contrat.

Schéma du filtre
Schéma du contrat se base sur le schéma du filtre qui est définit récursivement.
<xs:schema targetNamespace=" />xmlns=" />xmlns:xs=" elementFormDefault="qualified"
attributeFormDefault="unqualified" version="0.1">
<!-- =================== -->
<!-- Element definition-->
<!-- =================== -->
<xs:element name="comp" type="CompType"/>
<xs:element name="and" type="AndType"/>
<xs:element name="or" type="OrType"/>
<xs:element name="not" type="NotType"/>


Contrats pour la recherche fédérée

<xs:element name="filter" type="FilterType"/>
<xs:element name="op" type="OpType"/>
<xs:element name="field" type="FieldType"/>
<xs:element name="value" type="ValueType"/>
<!-- =================== -->
<!-- Complex Types definition-->
<!-- =================== -->
<xs:complexType name="CompType">
<xs:sequence>
<xs:element ref="op"/>
<xs:element ref="field"/>
<xs:element ref="value"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="AndType">
<xs:sequence>
<xs:choice>
<xs:element ref="comp"/>
<xs:element ref="and"/>
<xs:element ref="or"/>
<xs:element ref="not"/>
</xs:choice>
<xs:choice>
<xs:element ref="comp"/>
<xs:element ref="and"/>
<xs:element ref="or"/>
<xs:element ref="not"/>
</xs:choice>
</xs:sequence>
</xs:complexType>

<xs:complexType name="OrType">
<xs:sequence>
<xs:choice>
<xs:element ref="comp"/>
<xs:element ref="and"/>
<xs:element ref="or"/>
<xs:element ref="not"/>
</xs:choice>
<xs:choice>
<xs:element ref="comp"/>
<xs:element ref="and"/>
<xs:element ref="or"/>
<xs:element ref="not"/>
</xs:choice>
</xs:sequence>
</xs:complexType>
<xs:complexType name="NotType">
<xs:choice>
<xs:element ref="comp"/>
<xs:element ref="and"/>
<xs:element ref="or"/>
<xs:element ref="not"/>
</xs:choice>
</xs:complexType>
<xs:complexType name="FilterType">
<xs:choice>
<xs:element ref="comp"/>
<xs:element ref="and"/>
<xs:element ref="or"/>
<xs:element ref="not"/>

23


24

Contrats pour la recherche fédérée
</xs:choice>
<xs:attribute name="schemaVersion" type="xs:decimal" use="required" fixed="0.1"/>
</xs:complexType>
<!-- =================== -->
<!-- Simple Types definition -->
<!-- =================== -->
<xs:simpleType name="OpType">
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="eq"/>
<xs:enumeration value="ne"/>
<xs:enumeration value="lt"/>
<xs:enumeration value="gt"/>
<xs:enumeration value="le"/>
<xs:enumeration value="ge"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="FieldType">
<xs:restriction base="xs:NMTOKEN"/>
</xs:simpleType>
<xs:simpleType name="ValueType">
<xs:restriction base="xs:string"/>
</xs:simpleType>
</xs:schema>

L’image correspondante :

Figure 7.

Schéma du filtre.


Contrats pour la recherche fédérée
d)

25

Exemple
Le document XML suivant représente un contrat, assigné au client "giunti" qui peut

envoyer tous les types de requête, et indique que le client offre seulement le service "LOM
Search service". Seul l’utilisateur "teacher" est capable d’avoir accès aux OAs dont les
tailles sont inférieures ou égales à 30000. Le client peut éditer et mettre à jour des OAs qui
sont en italien. Aucun filtre ne s'applique à "LO Use Execute Request" et à "LO Use
Authorize Request" parce qu'ils sont d’accord avec ce qui a été déjà vérifié dans le
processus d'autorisation.
Le contrat du client "giunti" :
<contract xmlns=" />xmlns:jaxb=" xmlns:xjc=" />xmlns:xsi=" />xmlns:filter=" />xsi:schemaLocation=" />D:\dev\celebrate\XML\contract-0.2.xsd" schemaVersion="0.2" contractId="String"
contractType="permanent">
<client id="giunti" description="Giunti Labs"/>
<services>
<service type="CheckedLOMQueryRequest"/>
</services>
<clause>

<requests>
<request type="LOMDeleteRequest"/>
<request type="LOMPublishRequest"/>
<request type="LOMUpdateRequest"/>
</requests>
<filter:filter schemaVersion="0.1">
<filter:comp>
<filter:op>eq</filter:op>
<filter:field>general.language</filter:field>
<filter:value>italian</filter:value>
</filter:comp>
</filter:filter>
</clause>
<clause>
<requests>
<request type="LOMQueryRequest"/>
<request type="LOUseAuthorizeRequest"/>
</requests>
<filter:filter schemaVersion="0.1">
<filter:and>
<filter:comp>
<filter:op>eq</filter:op>
<filter:field>intendedenduserrole</filter:field>
<filter:value>teacher</filter:value>
</filter:comp>
<filter:comp>
<filter:op>lt</filter:op>
<filter:field>size</filter:field>
<filter:value>30000</filter:value>
</filter:comp>

</filter:and>