Introduction

Carnivore (http://nvo.caltech.edu:8080/carnivore) est le registry implémenté par NVO. Il dispose de toutes les fonctionnalités requises pour un registry :

• harvesting
• harvesting vers les autres registry
• requètes XQuery et ADQL
• requète en mode texte
• publishing

Carnivore est implémenté sous forme d'applicatin Web et s'appuie sur une base de données XML native eXist pour stocker les enregistrements des ressources. Nous allons maintenant passer en revue les différentes fonctionnalités et technologies utilisées.

Harvesting

Carnivore est conforme au protocol OAI-PMH et peut être harvesté de deux manières :

• via un script Perl (même méthode que VizieR)
• via un service Web (IVOA compliant)

Script Perl

Un script Perl reçoit les requètes OAI-PMH et interroge la base eXist pour récupérer les résultats. Puis il formate le résultat en OAI-PMH et le renvoie au client. Ce script possède donc deux parties :

• OAI-PMH
  • sert à analyser la requète et à formater le résultat en OAI-PMH
  • OAI 2 Data Provider fourni par Hussein Suleman est utilisé (Sebastien s'en sert aussi pour le script de VizieR)

• récupération des données
  • permet de récupérer les méta-données des ressources demandées dans la requète OAI-PMH
  • accède à eXist via son interface SOAP (le package SOAP::Lite gère le SOAP)

Service Web

Le service Web de Carnivore propose toutes les fonctions OAI-PMH :

• KeywordSearch()
• Search()
• GetRegistries
• Identify()
• ListMetadataFormats()
• ListSets()
• GetRecord()
• ListIdentifiers()
• ListRecords()

Harvesting vers les autres registry

Carnivore propose une interface pour harvester les autres registry. Cette interface liste les registry pouvant être harvestés (information cherchée dans la base au niveau des ressources de type "Registry"), et propose pour chacun d'eux d'effectuer l'action d'harvesting. Cette action ajoute automatiquement les nouveaux enregistrements dans la base Carnivore et permet ainsi d'alimenter le registry.

OPS (Orbeon Presentation Server)

Carnivore s'appuie sur OPS pour présenter les pages de son application Web. OPS sert en fait à construire une application Web manipulant des fichiers XML (capture, traitement et renvoi au client). OPS s'appuie sur le modèle MVC (Model View Controller) pour présenter les pages, i.e. que toute page est construite à partir d'un modèle (données de la page) et d'une vue (fichier XSL pour mettre en forme la page). Le modèle peut être un simple fichier XML ou un pipeline XPL (expliqué dans la section suivante).

Un fichier de configuration de OPS (ici page-flox.xml) permet de spécifier logiquement les pages et de les mapper sur un chemin relatif à Carnivore. Voici un extrait :

<page id="register" path-info="/publish/register" model="publish/register-model.xpl" xforms="publish/register-xforms-model.xml" view="publish/register-view.xsl">
...
</page>

Cette portion définit la page d'enregistrement d'un nouvel utilisateur. L'attribut path-info permet le mapping de cette page avec l'URL. Pour accéder à cette page il faudra donc taper http://localhost:8080/carnivore/publish/register. L'attribut model permet de dire où OPS doit chercher les données pour construire la page (ici c'est un pipeline qui sera utilisé). L'attribut view permet de préciser quel fichier de transformation utiliser pour obtenir la page finale.

XPL (XML Pipeline Language)

Un fichier XPL sert à décrire une suite de traitements que va subir un fragment XML pour finallement arriver à un résultat sous forme XML ou autre. C'est OPS qui prends en charge l'exécution des fichiers XPL.

Un pipeline XPL est une suite de "processeurs", chacun prenant en entrée un fragment XML et en produisant un nouveau en sortie. Voici par exemple un extrait du pipeline effectuant une requète ADQL dans la base et renvoyant le résultat :

<!-- Dynamically build query -->
  <p:processor name="oxf:xslt">
    <p:input name="data" href="#instance#xpointer(/form/query)"/>
    <p:input name="config" href="adqlw2xquery.xsl"/>
    <p:output name="data" id="query"/>
  </p:processor>

  <!-- Run query -->
  <p:processor name="oxf:xmldb-query">
    <p:input name="datasource" href="../datasource.xml"/>
    <p:input name="query" href="#query"/>
    <p:output name="data" id="result"/>
  </p:processor>

  <p:processor name="oxf:identity">
    <p:input name="data" href="aggregate('results', #query, #result)"/>
    <p:output name="data" ref="data"/>
  </p:processor>

Trois processeurs sont définis : le premier transforme la requète ADQL en requète XQuery, le deuxième effectue la requète dans la base eXist et le troisième formate le résultat. En réalité chaque processeur est implémenté en Java, mais le développeur XPL n'a pas une seule ligne de java à écrire (à moins qu'il ait besoin de nouveaux processeurs).

XForms

Xforms est un langage XML permettant de définir un formulaire HTML tout en séparant les données de la présentation. S'il est mis en oeuvre côté client, c'est au navigateur d'interpréter XForms, d'afficher le formulaire et d'en renvoyer les données sous forme XML. Et tout l'intérêt est là : coté serveur les données pourront être exploitées en XML. Mais Carnivore a choisi une implémentation de XForms côté serveur, et c'est OPS qui la prends en charge.

Comment Carnivore organise les données du registry ?

Il y a une collection par type de ressource (TabularSkyService, OpenSkyNode...) et un fichier XML par ressource. Voici la structure d'un fichier XML décrivant une ressource :

<carn:RegistryEntry>
  <carn:RegistryData>
    ...
  </carn:RegistryData>
  <carn:RegistryItem>
    <Resource>
      ...<!-- méta-données de la ressource -->
    </Resource>
  </carn:RegistryItem>
</carn:RegistryEntry>

Des fichiers d'administration sont également présents :

• Users.xml : décrit les utilisateurs de Carnivore (pas ceux de la base eXist)
• HarvestLog.xml : liste les derniers harvesting effectués par Carnivore
• Inventory.xml : liste toutes les ressources répertoriées dans le registry en gardant quatre informations pour chacune d'elle : identifiant, type, titre et couverture.

-- BriceGassmann - 09 Jun 2005