CHAPITRE 7

Utiliser des protocoles de recherche

Les protocoles de recherche sont un autre élément faisant partie du processus de recherche de ressources dans l'ICDG. Étant donné que vous utiliserez des protocoles de recherche lorsque vous rendrez votre base de données consultable, il vous serait utile de comprendre leur fonction et leur structure. Le présent chapitre :

• présente une définition d'un protocole de recherche;
  
  
• explique l'architecture de la plupart des protocoles de recherche, et établit la différence entre les recherches avec état (stateful) et des recherches sans état (stateless); et
  
  
• décrit le profil GEO du protocole de recherche Z39.50.
  
  

7.1 En quoi consistent les protocoles de recherche?

Un protocole de recherche est un moyen«normalisé » de formuler des questions (ou requêtes), d'obtenir des réponses et d'échanger de l'information entre deux ordinateurs sur Internet. Un protocole de recherche s'apparente à un langage technique. Il spécifie le mécanisme de transport de l'information entre deux ordinateurs.

Par exemple, l'information peut être transmise selon le protocole de transfert hypertexte (HTTP), greffé au protocole de communication/protocole Internet (TCP/IP), à l'aide de connecteurs logiciels. Ce ne sont pas les seuls mécanismes de transport, mais ce sont les plus courants.

• Quand un protocole de recherche utilise le HTTP comme mécanisme de transport, les deux ordinateurs doivent employer cette norme pour s'échanger l'information. Ils utilisent leurs adresses IP respectives pour se«trouver » et utilisent le port HTTP « connu » sur l'ordinateur (p. ex. port 80) afin de pouvoir se connecter l'un à l'autre.
  
  
• Si les connecteurs logiciels TCP/IP sont utilisés comme protocole de transport, l'information est alors échangée par l'intermédiaire de paquets TCP/IP et, comme précédemment, les ordinateurs se«trouvent»en utilisant des adresses IP, mais cette fois-ci le numéro du port peut être variable.
  
  

Un protocole de recherche spécifie également l'information qui est transmise entre les ordinateurs. Le type d'information transmise comprend :

• comment les ordinateurs établissent le contact initial entre eux;
  
  
• quelle information est contenue dans une requête et exactement comment elle est spécifiée;
  
  
• quelle information est contenue dans la réponse à une requête et exactement comment elle est spécifiée; et
  
  
• comment les ordinateurs mettent fin à la communication.
  
  

Lorsque le serveur de recherche fait la traduction entre le protocole de recherche et la base de données, deux éléments entrent en jeu.

1. Étant donnée que les métadonnées se trouvent à l'intérieur de la base de données, le serveur de recherche doit savoir quoi rechercher dans celle-ci. Chaque serveur de recherche comprend le format de métadonnées ou la norme de contenu qui lui sont propres. Après configuration du serveur de recherche, celui-ci peut établir une mise en correspondance entre les champs de métadonnées du serveur et les champs de la base de données.
   
   
2. Le serveur de recherche doit pouvoir interpréter le message contenu dans une requête. Si le protocole de recherche est le langage utilisé, il peut y avoir plusieurs modes d'établissement des messages qui peuvent être formulés dans ce langage. Le serveur comprend un mode de messagerie spécifique (ou profil) qui est étroitement lié à la norme de contenu des métadonnées utilisée pour représenter les métadonnées dans le serveur de recherche.
   
   

7.1.1 Architecture d'un protocole de recherche

La figure 8 ci-dessous illustre la fonction du protocole de recherche dans le flot de communication entre l'utilisateur et la base de données du fournisseur :

Figure 8 Architecture d'un protocole de recherche

7.1.2 Recherche avec état et recherche sans état

Un protocole de recherche peut être soit avec état, soit sans état.

Un protocole avec état signifie que le mécanisme de découverte établit la communication avec votre serveur de recherche et la maintient active pendant toute la durée de la session de recherche. Ainsi, un utilisateur a la possibilité de sélectionner dix produits, d'examiner les résultats de la recherche après le retour des résultats pour le premier produit, sans attendre que les résultats de tous les produits soient retournés.

Un protocole sans état signifie que votre mécanisme de découverte établit la communication avec votre serveur de recherche, envoie un peu d'information, en reçoit un peu, puis coupe la communication. Ainsi, la session de recherche comprend une série de ces interactions ouvrir-envoyer-recevoir-fermer entre le mécanisme de découverte et votre serveur de recherche. Chaque interaction ouvrir-envoyer-recevoir-fermer est indépendante des autres. On dit que le protocole est«sans état»lorsque votre serveur de recherche s'occupe de chacune des interactions individuellement, sans conserver d'« historique»sur les interactions précédentes. Dans ce cas, un utilisateur qui effectue une requête pour dix produits ne pourrait pas examiner les résultats de la recherche avant d'avoir reçu les résultats pour l'ensemble des dix produits.

Pour savoir comment cette spécification de l'ICDG s'applique aux protocoles avec et sans état afin de retourner les métadonnées sur les données géospatiales, prière de voir l'annexe A1.9, Service de découverte de données geospatiales.

7.2 Protocoles de recherche de l'ICDG

Le Portail de découverte de GéoConnexions fonctionne essentiellement avec le protocole de recherche géospatiale suivant :

• Protocole de recherche de profil Z39.50 FGDC/GEO.
  
  

Les protocoles de recherche géospatiale suivants étaient acceptés auparavant par le Portail de découverte de GéoConnexions, mais ils ne le seront plus pour les nouveaux fournisseurs :

• Protocole Simple Search; et
  
  
• Protocole de recherche Information Management System (IMS).
  
  

Le protocole de recherche ANSI/NISO Z39.50 de l'American National Standards Institute/ National Information Standards Organization est un protocole de communication entre ordinateurs conçu pour permettre la recherche et l'extraction d'information, de documents plein texte, de données bibliographiques, d'images et d'information multimédia dans un environnement réseau réparti.

Une spécification du protocole normalise la syntaxe de requête, les identités des champs de recherche et le format par défaut des enregistrements retournés, et offre des mécanismes de contrôle des accès et d'autodescription des serveurs. S'appuyant sur une architecture client/serveur et exploité sur Internet, le protocole Z39.50 permet de prendre en charge un nombre croissant d'applications. Tout comme l'environnement réseau dynamique dans lequel cette norme est utilisée, elle évolue afin de répondre aux besoins changeants des créateurs, fournisseurs et utilisateurs d'information.

La norme Z39.50 est très exhaustive. Malheureusement, il peut s'avérer fort complexe pour un fournisseur de données d'installer un logiciel serveur Z39.50 et de le configurer pour effectuer des recherches dans un jeu de données. Cet inconvénient va à l'encontre de l'objectif de GéoConnexions, qui est de réduire le coût de la participation des fournisseurs à un minimum. Pour surmonter ce problème, on a mis au point une trousse d'outils pour les métadonnées du FGDC, contenant le logiciel Z39.50/GEO permettant aux fournisseurs de l'installer et de le configurer facilement.

Le protocole de recherche Z39.50 est basé sur les messages qui utilisent des paires requête/réponse pour chacun des services qu'il prend en charge. Ses services essentiels sont :

1. Init, qui établit une session entre le client et le serveur de la base de données;
   
   
2. Search, qui transmet les critères de recherche à la base de données visée et retourne des statistiques sur les correspondances, par exemple le nombre total de correspondances. La réponse à une requête de recherche ne comprend pas les enregistrements correspondants proprement dits, extraits de la base de données; et
   
   
3. Present, qui suit la réponse à une recherche et qui est utilisé pour demander les enregistrements correspondants trouvés ou un sous-ensemble de ceux-ci. Le mécanisme est très puissant, car l'ensemble des résultats est géré au niveau du serveur cible et n'a donc pas à être transmis sur le réseau.
   
   

D'autres services permettent le contrôle de l'accès, la gestion des ressources, l'autodescription des bases de données visées, etc. Toutefois, ces services sont moins couramment offerts par le logiciel client et serveur que les trois services de base décrits ci-dessus.

La séquence«requête Init»et«réponse Init»(c'est-à-dire le processus qui permet à deux serveurs de se synchroniser afin de pouvoir communiquer entre eux) permet aux deux ordinateurs de se reconnaître mutuellement et d'indiquer les services (ou fonctions) Z39.50 qu'ils offrent.

La requête de recherche contient les paramètres de la requête d'extraction d'information. Elle consiste en une (ou plusieurs) restrictions de type Attribut/Relation/Valeur (p. ex. hauteur > 5).

• Les attributs sont des paramètres dont on permet l'utilisation dans une requête de recherche (p. ex. auteur, titre, résumé, date de publication). À chaque attribut, on assigne un identificateur numérique qui lui permet d'être compris de façon universelle par toutes les implémentations de serveurs Z39.50. Pour simplifier les choses, les attributs sont groupés dans de grands ensembles d'attributs, de façon à ce qu'un serveur Z39.50 particulier puisse indiquer quel ensemble d'attributs il accepte. Ces ensembles d'attributs sont officiellement inscrits auprès des responsables de la norme Z39.50.
  
  
• Les relations (p. ex. plus grand que, égal à) se voient également attribuer des identificateurs uniques par la norme Z39.50.
  
  

La réponse contient soit l'ensemble des enregistrements résultant de la recherche, soit seulement le nombre d'enregistrements correspondants. Si la réponse ne comporte que le nombre d'enregistrements, la requête peut être utilisée pour demander des ensembles de ces enregistrements correspondants.

Pour en connaître plus sur le protocole de recherche Z39.50, veuillez consulter :

• Le site de la National Information Standards Organization :
  
  

  http://www.cni.org/pub/NISO/docs/Z39.50-brochure/

  Actuellement, deux versions officielles de la norme ANSI/NISO sont couramment utilisées : la version 2 est la norme ANSI/NISO Z39.50-1992, et la version 3 est la norme ANSI/NISO Z39.50-1995. Le Portail de découverte de GéoConnexions utilise la version 2. On peut consulter une copie HTML de la version 2 à l'adresse :

  http://www.cni.org/pub/NISO/docs/Z39.50-1992/

• La « Library of Congress » des États-Unis :

  http://lcWeb.loc.gov/z3950/agency/

7.2.1 Le profil GEO de la norme Z39.50

Certains protocoles ont plusieurs profils. Un profil identifie un jeu de normes de base ainsi que les options et les paramètres appropriés, nécessaires à l'accomplissement de fonctions identifiées, incluant : a) l'interopérabilité et b) la méthodologie de référence de diverses utilisations de normes de base, significative à la fois pour les utilisateurs et les fournisseurs.

Le modèle d'extraction de l'information énoncé dans la norme Z39.50 est dit indépendant du domaine (ou de son domaine). Les spécialisations par domaine sont fournies par un mécanisme additionnel, appelé«profils d'application ». Des profils spécifiques existent pour les schémas de messagerie des requêtes et des résultats portant sur des données géospatiales. Ces profils sont étroitement associés à des normes sur le contenu de métadonnées spécifiques aux métadonnées géospatiales. Le FGDC a mis au point un profil d'application Z39.50 pour les métadonnées géospatiales appelé GEO. Celui-ci contient des spécifications sur la façon d'implanter les éléments de métadonnées CSDGM (Content Standard for Digital Geospatial Metadata) dans un service Z39.50.

L'utilisation de ce profil assure l'interopérabilité avec le centre d'échange de données (Clearinghouse) du FGDC, entre autres. De plus, le secteur de l'observation de la Terre, représenté par les organismes qui composent le CEOS (Comité sur les satellites d'observation de la Terre) travaille à assurer l'interopérabilité des protocoles GEO et CIP (lesquels sont tous deux basés sur la norme Z39.50). Le protocole CIP (Catalogue Interoperable Protocol) définit une seule interface pour les catalogues d'observation de la Terre. Le profil GEO uniformise (en plus de la norme Z39.50) le modèle de données pour la recherche et l'extraction, les opérateurs du langage de recherche (y compris les opérateurs spatiaux), etc.

Le profil Z39.50 GEO indique qu'un serveur de profil Z39.50 GEO doit :

• utiliser Init, Request, Present : c.-à.-d. 3 des 10 services/opérations disponibles;
  
  
• reconnaître 340 attributs pouvant être utilisés par le profil. De ce nombre, 17 doivent être acceptés par le serveur pour être utilisés dans les requêtes de recherche client. Chaque attribut correspond aussi à un type de données recommandé (p. ex. chaîne [string], entier [integer]); et
  
  
• reconnaître 18 relations (p. ex.«égal à », « proche ») qui doivent être acceptées dans une requête de recherche client.
  
  

En outre, le profil Z39.50 GEO présente les caractéristiques suivantes :

• Extensions : le profil GEO a comme base le profil BIB-1 de la norme Z39.50. Certains des profils de la norme Z39.50, comme le profil Z39.50 GEO, se fondent sur le BIB-1 de base dont ils utilisent un sous-ensemble et en définissent des extensions.
  
  
• Usage international : Le profil de recherche Z39.50 GEO est largement utilisé par de nombreuses organisations dans le monde. D'autres infrastructures de données spatiales qui utilisent ce protocole pourraient se connecter directement à n'importe quel serveur de recherche Z39.50 ou encore au serveur de recherche distribuée à titre de clients pairs.
  
  
• Profil enregistré : Le profil Z39.50 GEO est un profil enregistré de la norme Z39.50-1992, qui incorpore les métadonnées CSDGM du FGDC (version de juin 1994).
  
  
• Implantation : En supposant que vous disposez déjà d'une base de données ou d'un inventaire de produits consultables, la création d'une connexion de recherche FGDC/GEO devrait prendre de trois à dix jours de travail.
  
  
• Nul besoin d'un serveur WWW : Le protocole de recherche Z39.50 GEO est un protocole utilisant des connecteurs logiciels TCP/IP et, à ce titre, n'exige pas l'installation d'un serveur WWW à votre site. Les ordinateurs qui se connectent à votre serveur de recherche peuvent se connecter directement à son port, sans nécessiter un serveur WWW intermédiaire.
  
  
• Commandes par courriel : Votre bureau de commande peut recevoir des commandes électroniques des utilisateurs du Portail de découverte de GéoConnexions qui ont découvert vos produits à la suite d'une recherche.
  
  

La version complète du profil Z39.50 GEO est disponible à l'adresse :

http://www.blueangeltech.com/standards/GeoProfile/geo22.htm

Les nombreux profils de la norme Z39.50 sont énumérés à l'adresse :

http://lcWeb.loc.gov/z3950/agency/profiles/profiles.html

L'architecture Z39.50 GEO telle qu'implantée dans le Portail de découverte de GéoConnexions est illustrée à figure 9.

Figure 9 Architecture Z39.50 GEO