Développement d'un Full Registry français

Différents types de Registries

Searchable/publishing

• Searchable : Permet de rechercher des enregistrements de ressources par des critères sur leurs métadonnées (titre, sujet, auteur, ...). Une interface de type Web Service doit être présente pour servir des applications, et optionnellement une interface de type Web peut être présente pour l'humain.
• Publishing : Permet simplement de "montrer" aux autres Registries des enregistrements de ressources qui sont en général gérées localement. Un tel Registry doit donc supporter les requètes OAI d'harvesting venant des autres Registries.

Full/local

• Full : Contient en théorie les enregistrements de toutes les ressources existantes dans le VO. Un tel Registry harveste régulièrement les autres Registries afin de récupérer l'ensemble des enregistrements.
• Local : Contient seulement une partie des ressources existantes dans le VO, en l'occurrence les ressources gérées par l'organisme responsable du Registry.

Particularités

• Un Registry de type full DOIT être de type searchable.
• Un Registry de type searchable est en général de type full, ou au moins contient beaucoup d'enregistrements de ressources.
• Un Registry de type local peut dans certains cas être de type searchable (pour un domaine scientifique bien précis)
• Un Registry de type publishing DOIT être de type local

Registry of Registries

Le rôle du Registry of Registries (RoR) est de lister tous les Registries disponibles dans le VO en garantissant que chacun d'entre eux ait passé une phase de validation avant l'acceptation dans cette liste.

Validation d'un Registry

• Test de chaque enregistrement de ressource contenu dans le Registry (conformité au XMLSchema VOResource)
• Implémentaiton du protocole OAI-PMH : bonne réponse à chaque verbe, bonne gestion des erreurs, ...
• Pré-requis pour un harvestable Registry

Améliorations

Une interface de recherche de type XQuery devrait être présente afin de pouvoir selectionner des Registries selon plusieurs critères contenus dans les métadonnéees.

Harvestable Registry

OAI-PMH

OAI-PMH (Open Archives Initiative’s Protocol for Metadata Harvesting) est un protocole qui sert à l'échange de métadonnées entre différents fournisseurs de données. Le sytème de harvesting des Registries s'appuie sur ce protocole.

Pré-requis

Un Registry se prétendant harvestable doit respecter plusieurs choses :

• Il doit contenir un enregistrement de type vg:Registry décrivant ce Registry et récupérable via le verbe Identify d'OAI-PMH.
• L'enregistrement de type vg:Registry doit contenir autant d'éléments vg:ManagedAuthority que d'organisations gérées par ce Registry.
• Pour chaque organistation gérée par ce Registry, un enregistrement de type vg:Authority la décrivant doit être présent.
• Un set appelé "ivo_managed" contenant tous les enregistrements provenant de ce Registry doit être présent.

Spécifications

Type de Registry

Le futur Full Registry français devra être de type searchable et full.

Interface de saisie des enregistrements

C'est via cette interface que le responsable d'une ressource VO entrera les métadonnées associées et créera ainsi un nouvel enregistrement dans le Registry. Elle devra être de type Web "intelligente".

Système d'authentification

Une personne désirant déclarer une ressource devrait s'authentifier auparavant, ce qui permettrait de :

• Pré-remplir la partie curation de l'enregistrement
• En fonction de l'authoritiyId choisi, vérifier que cette personne ait le droit d'ajouter ou éditer cet enregistrement

Un système de groupe d'utilisateurs par authorityId pourrait être mis en place, ainsi un utilisateur devra faire partie du groupe de l'authorityId concerné afin d'ajouter ou éditer un enregistrement.

AuthorityId

Le choix de l'authorityId au moment de la déclaration d'une ressource est très important. Pour éviter les doublons, une liste des authorityId existants devrait être présentée à l'utilisateur afin qu'il puisse en selectionner un s'il est déjà présent. Sinon, un nouvel authorityId devra être créé, et l'utilisateur devra être ajouté au nouveau groupe correspondant.

Mode "bac à sable"

Il faudrait que l'utilisateur puisse ajouter un enregistrement sans que celui-ci soit visible du monde extérieur (harvesting depuis d'autres Registries et interface de recherche). Ceci permettrait à ce dernier de faire les tests préalables et d'être sûr que la ressource puisse être utilisée comme il faut via le Registry.

Génération automatique du formulaire de saisie

Il faudrait trouver une librairie permettant de transformer automatiquement un XMLSchema en formulaire Web de saisie des données pour une instance du schéma. La technologie XSLT serait utilisée. Ce système permettrait d'une part de réaliser le travail initial de façon plus rapide, mais aussi de gagner du temps de maintenance lors de modifications apportées au schéma XML VOResource.

Technologie

Plusieurs technologies sont disponibles afin de rendre le formulaire de saisie "intelligent" et interactif. Ajax, XForms, simple Javascript + DOM, ...etc.

• XForms : technologie très prometteuse, dont le principe est de séparer (à la manière du modèle MVC) le modèle de données, le formulaire en lui-même et le traitement. Malheureusement XForms n'est pas supporté nativement dans les navigateurs actuels et nécessite des plugins pour fonctionner.
• Ajax : technologie permettant d'envoyer des requètes HTTP au serveur de manière asynchrone, afin par exemple de mettre à jour des parties de la page du client sans devoir recharger toute la page. Cette technologie basée sur Javascript a le gros avantage d'être supportée nativement sur tous les navigateurs principaux.

Chiba serait une solution de traitement des XForms coté serveur, et résoudrait le problème du non-support de XForms coté client. Chiba est une librairie java pouvant être intégrée à une application Web sous forme de "filtre de servlet", afin de filtrer certaines pages contenant des fragments XForms et de les transformer en XHTML/Ajax.

Interface de recherche

Il faut regarder l'existant pour les autres Registries. L'outil développé dans VOTECH et le VOExplorer d'Astrogrid sont des bons exemples de départ.

Choix techniques

Stockage des enregistrements

Carnivore et Astrogrid se servent d'une base de données XML eXist. Il faudra forcément une base de données XML, mais on pourrait la coupler à une base de données relationnelle afin de faciliter les opérations de recherche.

Solution actuelle : serveur d'applications Tomcat 6.0 + eXist 1.2.4 en tant qu'application Web.

Accès au Registry

La solution la plus naturelle est de développer l'accès au Registry en tant qu'application Web en se servant de la technologie Java coté serveur afin de communiquer facilement avec la base de données eXist.

Solution actuelle :

• serveur d'application Tomcat 6.0 pour héberger l'application
• l'accès au Registry est une application Web
• technologie Java servlet pour accéder à la base de donnée et générer les pages html pour l'interface client

Implémentation du protocole OAI-PMH

Des librairies existent en PERL et Python, et permettent de s'interfacer avec une base de données XML.

Génération d'un fichier XForms à partir d'un XMLSchema

Fichier XSLT

J'ai trouvé un fichier XSLT fourni par Chiba, ce dernier permet de générer un fichier XHTML contenant la partie XForms correspondant au schéma XML fourni en entrée. La partie instance est générée automatiquement, et comporte simplement un squelette de la structure XML. Mais la contrainte est qu'un élément parent doit obligatoirement être déclaré dans le schéma, or cela n'est pas la cas pour les VOResources. Ce fichier XSLT est assez rigide au niveau de ce que doit contenir le fichier XMLSchema, notamment pour les déclarations de préfixes et de labels. De plus, le fichier XForms résultant n'est pas satisfaisant.

XForms generator

XForms generator est un plugin Eclipse développé par IBM permettant de convertir une instance XML en XForms. Cela s'intègre parfaitement dans Eclipse où il suffit de faire un clique droit sur un fichier XML pour générer le XForms correspondant.Plus précisemment, l'instance XML ayant servie à la génération est pointée par le XForms (donc tous les champs seront pré-remplis en fonction de ce que contient l'instance), un ensemble de binding sont réalisés pour chaque élément de l'instance (le type d'un point de vue XMLSchema y est notamment précisé), et enfin tous les contrôles formant l'interface graphique sont définis.

J'ai testé un XForms généré à partir d'une ressource de type VODataService, et cela marche bien sous Firefox en se servant du plugin XForms afin que l'interprétation se fasse côté client. Par contre, cela lève une exception si j'utilise le filtre Chiba afin de réaliser le traitement du XForms côté serveur.

-- BriceGassmann - 20 Oct 2008