La recherche fédérée et les protocoles en usage dans les bibliothèques

Présentation au sujet: "La recherche fédérée et les protocoles en usage dans les bibliothèques"— Transcription de la présentation:

1 La recherche fédérée et les protocoles en usage dans les bibliothèques
Gestion informatisée des bibliothèques Cycle T. – avril – ENSSIB, Villeurbanne La recherche fédérée et les protocoles en usage dans les bibliothèques pour un dialogue entre applications *

2 Une nouvelle donne technologique

3 Problèmes d’intégration des outils de référencement dans les systèmes d’information
Périodiques en ligne Catalogue collectif Catalogue Catalogues de bibliothèques associées ou partenaires Enregistrements sonores e-books Ressources multimédias Bases de signets Ressources pédagogiques Archives ouvertes Thèses en ligne

4 Sources hétérogènes Imprimés : appareil de description bibliographique évolué (+) Documents électroniques : contrainte éditoriale forte Appareil de description bibliographique faible (-) Cédéroms : type hybride (« semi-dématérialisé ») car il reste un objet de prêt ou de circulation E-books Thèses en ligne (pdf, html, xml, …) Ressources pédagogiques ou informationnelles produites par une institution Périodiques en ligne Images fixes/images animées Documents sonores (musicaux/non musicaux) Ces ressources électroniques sont prisonnières de plates-formes ce qui les range aussi, d’une certaine façon dans le web invisible, mais qui ne communique pas pour autant avec les OPAC…

5 Problématiques émergentes
Passage dans la dénomination des bibliothécaires, du terme de « LECTEUR » au terme d’ « USAGER » Marginalisation de l’imprimé avec les collections numériques ; ce qui peut-être vécu comme un paradoxe par la profession car l’imprimé mobilise la plus grande partie du temps/homme disponible alors que le volume des collections numériques est bien supérieur : Exemple d’un bibliothèques de recherche : 700 titres de périodiques papier conservés sur une période de 5 ans. Service de 4 personnes 14500 titres de périodiques électroniques dont des archives supérieures à 20 ans. Service de 0.5 personne Soit : 5% du nombre de titres pour l’imprimé Ces ressources restent invisibles quand elles sont fournies sous forme de flux, prisonnières de bouquets qui ne se manifestent pas dans un OPAC - L’OPAC reste un réservoir d’informations sur l’imprimé - Le « système d’information » ne permet pas toujours de naviguer d’une source à l’autre…

6 Sur le parcours de l’usager…
rq1 rq2 rq3 rq4 rq5 rq6 rq7 rq8 rq9 Ori-OAI OPAC Images E-books Cédéroms Thèses en ligne Z39-50 Périodiques en ligne Documents sonores Ressource électroniques Ressource pédagogiques Catalogue local Catalogue collectif Bouquet 1 Bouquet 2 Bouquet 3

7 Alors que l’on aimerait avoir :
Point d’entrée unique OPAC Images E-books Cédéroms Thèses en ligne Z39-50 Périodiques en ligne Documents sonores Ressource électroniques Ressource pédagogiques Catalogue local Catalogue collectif Bouquet 1 Bouquet 2 Bouquet 3

8 Alors que l’on aimerait avoir :
Point d’entrée unique OPAC Images E-books Cédéroms Thèses en ligne Z39-50 Périodiques en ligne Documents sonores Ressource électroniques Ressource pédagogiques Catalogue local Catalogue collectif Bouquet 1 Bouquet 2 Bouquet 3

9 Déclaration des bouquets par un tiers Base de données bibliographiques
Résolveurs de liens SID Déclaration des bouquets par un tiers Base de données bibliographiques Affichage d’icones Résolveur de liens SFX, EBSCO,…

10 Schémas de mise en œuvre de l’interopérabilité (1)
BDD Import de notices UNM Via iso 2709 (SUDOC, Moccam,BnF, Zebris…) OPAC Import de notices d’autorité iso2709 Imports de notices de documents électroniques Iso 2709 Avec une bibliothèque JAVA ou php, il est possible de générer un fichier iso 2709 à partir d’un fichier .csv Problème : les états de collections : leur mise à jour est difficile grande mouvance dans les titres. peu de visibilité sur les titres, pour une institution : il est difficile d’obtenir une liste précise et à jour. Un exemple à ne pas suivre !

11 Schémas de mise en œuvre de l’interopérabilité (2)
Interopérabilité de niveau 1 Catalogue d’imprimés (oracle/Mysql) IGP OPAC connecteurs Catalogue de périodiques en ligne (Mysql) Interopérabilité de niveau 2 Recherche frédérée Catalogue d’e-books (Mysql) Ressources pédagogiques Ori-OAI Thèses électroniques Exemple : l’utilisateur peut choisir ses sources à l’aide de cases à cocher : c’est une recherche fédérée

12 Pour conclure… L’effort de construction de l’interopérabilité est indispensable, sinon nous « perdons » l’usager… = nous l’égarons un peu plus = nous le voyons préférer des moteurs commerciaux Il est possible de se positionner sur le marché en tant qu’institution (=source fiable ) grâce à des WebServices qui « déportent » nos bases de données dans d’autres environnements (une occasion à saisir ?)

13 Systèmes documentaires classiques
Tableau comparatif des caractéristiques des systèmes documentaires « classiques » et des plates-formes disponibles sur Internet Pour les professionnels de l’info-doc, en particuliers pour les administrateurs de systèmes, ces oppositions peuvent être résumées ainsi : Systèmes documentaires classiques Internet Taille de la base limitée – croissance linéaire avec le temps Milliers de Go - croissance exponentielle Informations secondaires Bases externes sur lesquelles aucune action n’est possible, en particulier pour l’indexation Bases internes : responsabilité de constitution, de mise à jour et d’indexation de la base Homogénéité des sources et des informations : la base recouvre un ou plusieurs domaines bien circonscrits avec une approche précise (commerciale, scientifique ou autre) Hétérogénéité des sources et des informations : on trouve tout sur les réseaux – plus de domaines restreints, toutes les approches (scientifique, commerciale, vulgarisation, etc.)

14 Systèmes documentaires classiques
Internet Format unique de présentation des données Formats multiples en évolution incessante Bases structurées (champ de catalogage renseigné) Sites web non structurés – utilisation minimale des balises méta Existence d’un langage d’indexation (thésaurus) adapté au domaine et à la base Pas de langage d’indexation : pas de thésaurus couvrant l’ensemble des domaines de connaissance – trop d’acteurs différents interviennent Indexation avec un thésaurus adapté Indexation des moteurs de recherche sur le web de très bas niveau (0 ou 0+ selon les sites) Indexation de la totalité des corpus Indexation d’une partie. Il existe 2 formes de sites : web accessible (visible) et web invisible (pages générées par une requête, pages dont on a refusé qu’elles soient référencées, pages intranet protégées par un firewall) Informations vérifiées (sources connues) Informations non validées Monolinguisme, au moins des index ou descriptions Multilinguismes Outils d’interrogation unique, adapté à la base et au langage utilisé Mélange des modes de recherche : répertoires, mots, navigation Souci de la cohérence des informations (travail de documentaliste/bibliothécaire) Alimentation réalisée par un webmaster , pas forcément les mêmes problématiques (souci de présentation, de diffusion, d’impact des informations (1)Abderrazak Mkadmi, Imad Saleh, Bibliothèque numérique et recherche d’informations

15 Problème majeur : chacune des sources qui gravitent autour du catalogue disposent de leurs propres outils de recherche, de leurs propres index, de leur propre appareil de description Exemples de recherche dans des sources hétérogènes : Je cherche des articles sur les langages de programmation informatique à l’usage des linguistes, en français ou en anglais (les deux langues que je parle), publiés ces 10 dernières années FRANCIS : linguistique.df. or linguistique.pb. or linguistique.cf. or linguistique.hw. or linguistique.in. or linguistique.ti. or linguistique.ca. or linguistique.tt. or linguistique.if. or linguistique.ar. or linguistique.da. or linguistique.ab. or linguistique.ts. or linguistique.jx. or linguistique.de.} & {programmation.df. or programmation.ti. or programmation.cf. or programmation.hw. or programmation.jx. or programmation.tt. or programmation.ca. or programmation.in. or programmation.ar. or programmation.da. or programmation.ab. or programmation.pb. or programmation.de.}&{ article.pt.}&{ (french or english).lg.}&{ ("1999" or "2004" or "2006" or "2003" or "2000" or "2001" or "2008" or "2007" or "2002" or "2009" or "2005").yr.} Je cherche l’ensemble des thèses soutenues devant l’Université du Maine en 2008 et disponibles sous format électronique SUDOC :

16 Le « web invisible » O P Site A x institutionnel C s x Éditeurs
Inconvénient majeur des systèmes interopérables : on reste tout de même dans le « web invisible » Le Web invisible ou Web caché est la partie du Web correspondant à l'ensemble des documents qui ne sont pas indexés par les outils de recherche traditionnels. « Les ressources du Web invisible comprennent, entre autres, les sites Web construits autour d'une base de données (interrogeable uniquement par un moteur de recherche interne), les pages accessibles par un formulaire de recherche, les pages protégées par un mot de passe, les pages interdites aux robots d'indexation, les pages écrites dans des formats propriétaires, les intranets et les extranets. » O P A C s Bases de données Site institutionnel x Ressources électroniques x Éditeurs

17 Les bases de données Un ensemble structuré d'informations, regroupées sous la forme d'enregistrements stockés sur un système de fichiers logique ou physique, conçu pour permettre une consultation et une modification aisée de son contenu. On la gère avec un SGBD (Système de gestion de bases de données). Les informations sont stockées dans des tables. Chaque table a un nom unique. Il n'y a pas de vide : toutes les cases ont une valeur, qui par défaut est "null" (!). Les champs (attributs) sont disposés en colonne. Une ligne, l'ensemble des valeurs contenues dans un enregistrement, est appelée "tuple" ou "n_uplet". Chaque tuple a un identifiant, ou "clé primaire". Chaque clé primaire répond à 3 grands principes : - minimalité (inutile d'avoir plusieurs clés) - unicité - valeur obligatoire (= non "null") Il peut y avoir des relations entre les tables (!). Une table peut gérer des clés étrangères : c'est l'expression du lien. La clé étrangère est la clé primaire d'une autre table, par convention identifiée par un #. Tout clé étrangère est caractérisée par une règle ; elle a le même domaine que les clés primaires des attributs référencés.

18 L'atomicité (Première fonction)
Chaque attribut d'une relation (paradigmatique) appartient à un seul domaine de valeur, qui est défini par : - un type (intervalle de valeurs) - une longueur (pour les valeurs caractères) - un format La donnée de l'attribut (ou champ) doit être élémentaire : elle ne prend qu'une valeur dans l'intervalle de donnée autorisé. Ex. domaine={bleu;rouge;vert;jaune} L'attribut COULEUR est défini sur ce domaine Un MCD (modèle conceptuel de données) est un schéma de structure des tables et des relations :

19 Dans les bibliothèques, comme dans la plupart des systèmes qui gèrent un volume important, on parle de SGBDr pour des "bases de données relationnelles". Ne pas confondre "relation entre les tables" et "relationnel" qui fait référence à la théorie relationnelle ! Les Langages SQL (structured query language) Il a 4 formes : LDD, langage de définition des données : create, alter, drop LMD, langage de manipulation des données : insert, update, delete LID, langage d'interrogation des données : select [< algèbre relationnelle - théorie ensembliste / langage des prédicats : "tout", "il existe", "appartient", "and", "or", "not", "P(x)", "P(x,y)"] LCD, langage de contrôle des données : grant revoke CREATE TABLE COMMANDE ( no_commande char (3) date_commande date montant numeric (9,2) ); montant numeric (9,2) <=> 9 caractères en tout dont 2 décimales

20 Les relations vont être gérées par un outil spécifique.
Le produit cartésien sert à gérer des jointures. Une jointure est un produit cartésien + un select où clé étrangère = clé primaire Le résultat d'un select d'une jointure est le nombre de tuples qui correspond au nombre de clés étrangères non nulles Ex. Les titres de notices bibliographiques d'exemplaires prêtés à un moment donné avec une table UNIMARC qui gère les notices bibliographiques et une table EXEMPLAIRE qui gère les exemplaires : select distinct TITRE from from UNIMARC U,EXEMPLAIRE E where U.UNIQUE_KEY=E.UNIMARC_KEY and ETAT='2'; Des opérations comme l'UNION (union all- union - distinct) et la DIFFERENCE (MINUS) sont possibles Les données sont prisonnières de bases de données qui imposent leur propre schéma de fonctionnement ; elles sont insérées dans des tables. Les relations vont être gérées par un outil spécifique. Pour manifester ces données, on a besoin d’un moteur et d’un modèle de sortie (output).

21 L’interopérabilité des systèmes

22 La coopération entre les bibliothèques : une vieille histoire.
L’interopérabilité des catalogues vise d’abord l’échange de données. facilite la production des informations facilite l’échange d’informations facilite la circulation des documents eux-mêmes Motivée par des nécessités économiques (baisse des coûts de production). Les nombreux efforts de normalisation en sont la conséquence. On discerne déjà la nécessité de pratiques harmonisées entre les bibliothèques avec l’utilisation de normes formats protocoles Tous très richement documentés !

23 Normes en vigueur dans les bibliothèques pour la description bibliographique :
Z Catalogage des monographies - texte imprimé   Z Catalogage des ressources continues Z Catalogage des monographies anciennes Z   Catalogage des vidéogrammes Z   Catalogage des enregistrements sonores Z Catalogage des documents cartographique Z Catalogage de la musique imprimée Z Catalogage des images fixes Z Catalogage des parties composantes Z   Catalogage des ressources électroniques Z Catalogage des monographies - texte imprimé (description allégée ) Z   Catalogage - Choix des accès à la description bibliographique Z Catalogage d’auteurs et d’anonymes :   forme et structure des vedettes de collectivités auteurs Z   Catalogage d’auteurs et d’anonymes : Forme et structure des vedettes noms de personne, des vedettes titres, des rubriques de classement et des titres forgés Z Catalogage - Forme et structure des vedettes titres musicaux Z Z Catalogage - Forme et structure des vedettes : Noms géographiques Z Documentation - Indexation analytique par matières Z Documentation - Références bibliographiques : contenu, forme et structure  

24 Formats utilisés en bibliothèque
MARC (MARC 21, UNIMARC) DublinCore (format normalisé!), XML Protocoles utilisés en bibliothèque : Par exemple pour l’échange de données : Z39-50, SRU/SRW ; WAIS(Wide area information service), FTP (File transfert protocol); HTTP 24

25 L’interopérabilité, qu’est-ce que c’est ?
« L’ interopérabilité est la capacité que possède un produit ou un système, dont les interfaces sont intégralement connues, à fonctionner avec d'autres produits ou systèmes existants ou futurs et ce sans restriction d'accès ou de mise en œuvre . » (AFUL) vs compatibilité interopérabilité Cela nécessite une grande transparence sur les mécanismes ou les formats employés…

26 L’intéropérabilité en trois mouvements
Elle met en jeu trois niveaux techniques complémentaires(1) : 1. Une description des ressources avec des sémantiques communes 2. Un contexte générique d’implémentation des descriptions dans des langages structurés standardisés, interprétables par des machines 3. Un ou plusieurs protocoles informatiques d’échange de ces données normalisées (1)Abderrazak Mkadmi, Imad Saleh, Bibliothèque numérique et recherche d’informations

27 <Cadre générique d’implémentation>
ISO 2709 XML, MarcXchange URL RDF (Resource Description and Framework) <Jeu de métadonnées> MARC (< Z44-050) Standards traditionnels DublinCore, MODS EAD LOM (Learning Object Metadata) SCORM Standards plus récents <Protocoles> WAIS, FTP, Z39.50 http OAI-PMH SRU/SRW

28 Dispositifs « synchrones » et dispositifs « asynchrones »
Pour construire l’interopérabilité entre les systèmes on peut mettre en œuvre des dispositifs : Synchrones : Z3950, SRU/SRW, OpenURL, API, Webservices,… Ces dispositifs permettent une interrogation  « à chaud » des données. Des moteurs de recherche pointent vers des bases toujours à jour : le service distant peut remonter une information juste après sa création ou sa modification. Cette immédiateté est un avantage, mais la gestion des protocoles qui permettent cette interrogation est plus lourde. Asynchrones : les données sont recopiées (par exemple dans un entrepôt) et pour être interrogées doivent attendre un reversement, en général planifié : une fois par jour, une fois par semaine, une fois par mois. C’est le cas d’un entrepôt OAI. On peut mesurer cette différence en se rappelant le schéma de signalisation des notices dans le SUDOC : les modifications ou créations sur les notices du réseau sont prises en compte après le transfert régulier dans le système local des membres du réseau : ce dispositif est asychnchrone. Mais si l’établissement cible a monté un serveur Z39.50, les données, une fois insérées dans le système local sont interrogeables « à chaud », en temps réel par un système distant.

29 Dispositifs « synchrones » et dispositifs « asynchrones »
On sera amené à choisir l’un ou l’autre mode pour construire l’interopérabilité, en fonction de la nature des informations qui doivent être fournies, et de la variabilité de ces données. Document électronique Peu de clés étrangères Pas de transactions de prêt Données à faible variabilité Données pour une utilisation immédiate Périodicité de mise à jour >= 1 semaine Réindexation peu fréquente Protocole de grande fiabilité Imprimé Objets de prêt Données à grande variabilité Données normalisées de grande fiabilité Réindexations courantes

30 Schéma global d’un SID (théorique)
moissonnage Entrepôt OAI-PMH « ingest » Autres catalogues de bibliothèques SRU Z 39.50 Sources « hétérogènes » SIGB Fournisseurs de notices MARC BnF, ABES, Electre, Zebris, … import connecteurs OPAC API

31 Schéma global d’un SID (existant)
Les Bibliothèques nationales et l’accès à l’information : le rôle de TEL et de MACS / Genevieve Clavel-Merrin

32 Dispositifs SYNCHRONES

33 Z39.50

34 Le protocole Z39-50 Protocole d’échange pour une utilisation bibliographique qui régit le « dialogue » entre clients et serveurs, décrit et utilisé aux États-unis à partir de 1984. La norme date de 1988, provient du « New York Item » ; Elle est maintenue par la Bibliothèque du Congrès avec la « Z39.50 Maintenance Agency ». Ce protocole permet l’interrogation en temps réel de bases bibliographiques pour un usage de consultation et de récupération de notices, sans que l’usager ne soit obligé de changer d’environnement.

35 Utilisateur / bibliothécaire
Rq 1 Catalogue local (C/S ou émulation telnet) Base de données locale (MARC) SIGB 1 Bibliothèque 1

36 Règles de filtrage Utilisateur / bibliothécaire Rq 1 Rq 1
Catalogue local (C/S ou émulation telnet) Catalogue Z39.50 (port ) Base de données locale (MARC) Base de données locale (MARC) SIGB 1 SIGB 2 Bibliothèque 1 Bibliothèque 2

37 Utilisateur / bibliothécaire
Rq 1 Rs 2 Rq 1 Catalogue local (C/S ou émulation telnet) Catalogue Z39.50 (port ) Rs 2 Base de données locale (MARC) Base de données locale (MARC) SIGB 1 SIGB 2 Bibliothèque 1 Bibliothèque 2

38 Utilisateur / bibliothécaire
Rq 1 Rs 1 Rs 2 Rq 1 Catalogue local (C/S ou émulation telnet) Catalogue Z39.50 (port ) Rs 2 Base de données locale (MARC) Base de données locale (MARC) SIGB 1 SIGB 2 Bibliothèque 1 Bibliothèque 2

39 Utilisateur / bibliothécaire
Rq 1 Rs 1 Rs 2 Rq 1 Catalogue local (C/S ou émulation telnet) Catalogue Z39.50 (port ) Rs 2 Base de données locale (xMARC) Base de données locale (xMARC) ? SIGB 1 SIGB 2 Bibliothèque 1 Bibliothèque 2

40 Z39.50 utilise à l’origine le modèle OSI (Open Systems Interconnection)
qui regroupe 7 couches : 7 Application 6 Présentation 5 Session 4 Transport 3 Réseau 2 Liaison de données 1 Physique TCP/IP (Unix) Port 210 : le client ouvre directement une connexion TCP avec le serveur Z39.50 Croît avec Internet !

41 Ici, la « sémantique commune » est déjà presque acquise :
Avec Z39-50, on a deux systèmes qui dialoguent facilement car ils manipulent des valeurs communes… Système A Système B TITRE T TITRE T Unimarc.200a Unimarc.200a Index: ’TitreM’ Index: ’MTitre’ Interpréteur : TitreM.A=Mtitre.B La liaison fonctionne avec un simple interprète. Le protocole d’échange est solide comme il repose sur des données normalisées (qui sont la garantie de l’interopérabilité).

42 Un protocole de liaison : Search/Retrieve Protocol
Utilisateur / bibliothécaire Rq 1 Rs 1 Rs 2 Rq 1 Catalogue local (C/S ou émulation telnet) Catalogue Z39.50 (port ) Rs 2 Base de données locale (MARC) Base de données locale (MARC) SIGB 1 SIGB 2 Bibliothèque 1 Bibliothèque 2

43 Utilisateur / bibliothécaire
Rq 1 Rs 1 Rs 2 Rq 1 Catalogue local (C/S ou émulation telnet) BASE D’INFORMATION Rs 2 Mais se focalise sur le dialogue entre les plates-formes. Il pourrait très bien s’adapter à la recherche d’information en général, mais il est totalement ignoré en dehors des sphères des bibliothèques. Autre particularité : il gère des opérateurs booléens Base de données locale (xMARC) Le protocole Z39.50 ne s’occupe pas du fonctionnement interne de la plate-forme distante… SIGB 1 Bibliothèque 1 43

44 ANS1 : Abstract Notation Syntax 1 (ISO 8824)
L’utilisateur n’a pas à se soucier des différences entre les systèmes : sa requête sera traduite avec précision grâce à la définition booléenne « embarquée » par le protocole. La norme fait état de : ANS1 : Abstract Notation Syntax 1 (ISO 8824) Un langage de description de données indépendant des matériels et logiciels permettant de décoder des messages entre clients et serveurs BER : Basic Encoding Rules (ISO 8825) Des règles de conversion de syntaxes abstraites en une syntaxe spécifique de transfert de données De même le professionnel de l’information s’y retrouve aussi car la complexité du modèle repose sur le paramétrage de notions spécifiquement bibliothéconomiques… 44

45 Systèmes de requêtes HTTP
RFC MIME-SMTP HTTP 1.0 Les requests for comments (RFC), littéralement « demande de commentaires », sont une série numérotée de documents officiels décrivant les aspects techniques d'Internet. Peu de RFC sont des standards, mais tous les standards d'Internet sont des RFC. RFC 1945 : Hyper text Transfer Protocol – HTTP/1.0 (Specifications) RFC 1738 : Adresses universelles (URL, Uniform Resource Locators) La RFC qui a longtemps servi de base à la définition des URL et des URI. Elle définissait le format des URL pour différents protocoles, comme Gopher, Mailto, etc. Le format des URL pour les requêtes de ces différents protocoles, sont maintenant traités à part des dans documents propres à chacun. Obsolète, remplacée par la RFC 3986 : Identifiant de Ressource Uniforme (URI) : Syntaxe générique RFC 1808 : pour les URL relatives (Memo) ./ correspond au dossier actuel ; ../ correspond au dossier parent ; / correspond au dossier racine

46 RFC 1945 : Hyper text Transfer Protocol – HTTP/1.0 (Specifications)
Terminologie Connexion Un circuit virtuel s'appuyant sur une couche de transport pour la communication d'information entre deux applications. Message L'unité de base d'une communication HTTP, consistant en une séquence structurée d'octets transmis via la connexion. Requête Un message de requête HTTP Réponse Un message de réponse HTTP Ressource Un service ou objet du réseau pouvant être identifié par une URI Entité Une représentation particulière de données, ou la réponse d'une ressource de type service, incluse dans une requête ou une réponse. Une entité représente une métainformation sous la forme d'un en-tête et d'un contenu (corps, ou « body » ). Client Un programme applicatif dont la fonction principale est d'émettre des requêtes. Utilisateur Le client qui a émis la requête. Celui-ci peut être un navigateur, un éditeur, un "spider" (robot d'exploration), ou autre utilitaire.

47 Utilisateur final L'utilisateur humain pilotant le programme utilisateur. Serveur Un programme applicatif acceptant des connexions dans le but de traiter des requêtes des délivrer des réponses Serveur d’origine Le serveur dans lequel se situe physiquement une ressource. Proxy Un programme intermédiaire qui cumule les fonctions de serveur et de client. Les requêtes sont soit traitées en interne ou répercutées, éventuellement converties, sur d'autres serveurs. Un proxy doit interpréter, puis reconstituer un message avant de le réemettre. Les proxies sont souvent utilisés comme portes d'accès côté utilisateur à des réseaux protégés par un "firewall" ou comme intermédiaire pour convertir des protocoles non supportés du côté utilisateur. Gateway ou routeur Un serveur jouant le rôle d'intermédiaire pour d'autres serveurs. Contrairement à un Proxy, un routeur reçoit les requêtes comme s'il était le serveur d’origine pour la ressource ; le client n’est pas nécessairement conscient de "communiquer" avec un routeur. Les routeurs sont souvent utilisés comme porte d'accès, côté serveur ,d'un réseau protégé par "firewall" et comme convertisseur de protocole pour accéder à des ressources hébergées sur des systèmes non-HTTP. Tunnel Programme applicatif servant de relais "transparent" entre deux connexions. Une fois actif, cet élément n'est plus considéré comme faisant partie de la connexion HTTP, bien qu'il soit issu d'une requête HTTP. Le tunnel cesse d'exister lorsque les deux sens de la connexion ont été fermés. Les tunnels sont utilisés lorsqu'une "porte" est nécessaire et que l'intermédiaire ne peut, ou ne doit pouvoir interpréter la communication.

48 HTTP et MIME (Multipurpose Internet Mail Extensions)
Cache Espace de stockage local destiné à enregistrer les réponses ; sous-système contrôlant ces enregistrements, leur relecture et leur effacement. Un cache enregistre des réponses dans le but de diminuer le temps d'accès et la charge si d’éventuelles requêtes identiques se présentent ultérieurement. HTTP et MIME (Multipurpose Internet Mail Extensions) standard internet qui étend le format de données des courriels pour supporter des textes en différents codage de caractères autres que l'ASCII, des contenus non textuels, des contenus multiples, et des informations d'en-tête en d'autres codages que l'ASCII. Les courriels étant généralement envoyés via le protocole SMTP au format MIME, ces courriels sont souvent appelés courriels SMTP/MIME. Les types de contenus définis par le standard MIME peuvent être utilisés à d'autres fins que l'envoi de courriels, dans les protocoles de communication comme le HTTP pour le World Wide Web. MIME a inspiré WWW pour standardiser le flux d’information émises via HTTP, et rend interopérables les différents encodages. charset            = "US-ASCII" | "ISO " | "ISO "                     | "ISO " | "ISO " | "ISO "                     | "ISO " | "ISO " | "ISO "                     | "ISO " | "ISO-2022-JP" | "ISO-2022-JP-2"                     | "ISO-2022-KR" | "UNICODE-1-1" | "UNICODE-1-1-UTF-7"                     | "UNICODE-1-1-UTF-8" | autre_nom

49 Utilisation de BNF étendue
BNF est une description normalisée des expressions rationnelles. Il provient du langage formel (met en œuvre une notation qui crée du sens) Ex. a* = répétion [éventuellement nulle] de a jusqu’à +∞ a+= au moins 1a Instructions de bas niveau CR LF = marqueur de fin de ligne (Carriage Returne Line Feed) LWS = en-tête TEXT = utilisée pour décrire des informations descriptives. ISO implicite HEX = "A" | "B" | "C" | "D" | "E" | "F" | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT

50 url = httpurl | ftpurl | newsurl | nntpurl | telneturl | gopherurl | waisurl | mailtourl | fileurl | prosperourl | otherurl = 1*[ lowalpha | digit | "+" | "-" | "." ] schemepart = *xchar | ip-schemepart ; schemeparts d’URL pour protocoles fondés sur ip: ip-schemepart = "//" login [ "/" urlpath ] login = [ user [ ":" password ] ] hostport hostport = host [ ":" port ] host = hostname | hostnumber hostname = *[ domainlabel "." ] toplabel domainlabel = alphadigit | alphadigit *[ alphadigit | "-" ] alphadigit toplabe = alpha | alpha *[ alphadigit | "-" ] alphadigit alphadigit = alpha | digit hostnumber = digits "." digits "." digits "." digits port = digits user = *[ uchar | ";" | "?" | "&" | "=" ] password = *[ uchar | ";" | "?" | "&" | "=" ] urlpath = *xchar ; dépend du protocole, voir le paragraphe 3.1 ; Les schémas prédéfinis : ; FTP (voir aussi la RFC 959) ftpurl = "ftp://" login [ "/" fpath [ ";type=" ftptype ]] fpath = fsegment *[ "/" fsegment ] fsegmen = *[ uchar | "?" | ":" | | "&" | "=" ] ftptype = "A" | "I" | "D" | "a" | "i" | "d" ; FILE fileurl = "file://" [ host | "localhost" ] "/" fpath ; HTTP httpurl = " hostport [ "/" hpath [ "?" search ]] hpath = hsegment *[ "/" hsegment ] hsegment = *[ uchar | ";" | ":" | | "&" | "=" ] search = *[ uchar | ";" | ":" | | "&" | "=" ] HTTP

51 ; GOPHER (voir aussi la RFC 1436)
gopherurl = "gopher://" hostport [ / [ gtype [ selector [ "%09" search [ "%09" gopher+_string ] ] ] ] ] gtype = xchar selector = *xchar gopher+_string = *xchar ; MAILTO (voir aussi la RFC 822) mailtourl = "mailto:" encoded822addr encoded822addr = 1*xchar ; mieux défini dans la RFC 822 ; NEWS (voir aussi la RFC 1036) newsurl = "news:" grouppart grouppart = "*" | group | article group = alpha *[ alpha | digit | "-" | "." | "+" | "_" ] article = 1*[ uchar | ";" | "/" | "?" | ":" | "&" | "=" ] host ; NNTP (voir aussi la RFC 977) nntpurl = "nntp://" hostport "/" group [ "/" digits ] ; TELNET telneturl = "telnet://" login [ "/" ] ; WAIS waisurl = waisdatabase | waisindex | waisdoc waisdatabase = "wais://" hostport "/" database waisindex = "wais://" hostport "/" database "?" search waisdoc = "wais://" hostport "/" database "/" wtype "/" wpath database = *uchar wtype = *uchar wpath = *uchar WAIS : Wide Area Information Servers, ou Service, ou System ou Searching, aussi connu sous l'acronyme WAIS, est un système informatique client-serveur permettant à un logiciel client WAIS de se connecter à un serveur répertoriant des bases de données documentaires distribuées sur un réseau informatique et de lancer une recherche dans le texte des documents. Les recherches peuvent s'effectuer par mots clés ou en langage courant. La réponse est donnée sous la forme d'une liste de documents consultables triés par ordre de pertinence. WAIS utilise une extension du protocole de communication ANSI Z39.50.

52 […] ; Définitions diverses lowalpha = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" | "y" | "z" hialpha "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" | "J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" | "S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z" alpha = lowalpha | hialpha digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" safe = "$" | "-" | "_" | "." | "+" extra = "!" | "*" | "'" | "(" | ")" | "," national = "{" | "}" | "|" | "\" | "^" | "~" | "[" | "]" | "`" punctuation = "<" | ">" | "#" | "%" | <"> reserved = ";" | "/" | "?" | ":" | | "&" | "=" hex = digit | "A" | "B" | "C" | "D" | "E" | "F" | "a" | "b" | "c" | "d" | "e" | "f" escape = "%" hex hex unreserved = alpha | digit | safe | extra ucha = unreserved | escape xchar = unreserved | reserved | escape digits = 1*digit

53 Mémo ? Introduit un paramètre = attribue une valeur à un paramètre & enchaîne deux paramètres @ termine les données d’identification / déplace dans l’arborescence // introduit un protocole : introduit un mot de passe + opérateur booléen ‘’ ‘’ introduit une chaîne # introduit une ancre % HEX HEX introduit un caractère codé

54 ?halsid=0s9v93i6o5altejbh58n9j2845
?halsid=0s9v93i6o5altejbh58n9j2845 &view_this_doc=tel &version=1 &CRIT1=VICTOR%20HUGO&OPER1=and &CRIT1=VICTOR%20HUGO&OPER1=and ?query=EXPERT &INDEX_LIV1=DLIV_MOTSUJ Ouvrages disponibles sur Victor Hugo &CRIT1=VICTOR%20HUGO &OPER1=and

55 Requêtes HTTP GET C'est la méthode la plus courante pour demander une ressource. Une requête GET est sans effet sur la ressource, il doit être possible de répéter la requête sans effet. HEAD Cette méthode ne demande que des informations sur la ressource, sans demander la ressource elle-même. POST Cette méthode doit être utilisée lorsqu'une requête modifie la ressource. OPTIONS Cette méthode permet d'obtenir les options de communication d'une ressource ou du serveur en général. CONNECT Cette méthode permet d'utiliser un proxy comme un tunnel de communication. TRACE Cette méthode demande au serveur de retourner ce qu'il a reçu, dans le but de tester et d'effectuer un diagnostic sur la connexion. PUT Cette méthode permet d'ajouter une ressource sur le serveur. DELETE Cette méthode permet de supprimer une ressource du serveur.

56 SRU

57 Contexte SRU peut être présenté comme une extension de Z39.50, mais qui ne sort pas de la couche web. Z39.50 est lourd à maintenir et à implémenter. Il nécessite une entente stricte entre le client et le serveur. SRU répond à un besoin d’interroger des sources distantes et hétérogènes sans se plier à un environnement technique défini, et offre plus de souplesse en exploitant des données étrangères. S’inscrit dans un cadre universel : XML S’appuie sur un ensemble de formats pivots universels : DC, MODS, MarcXML, … Appelle un protocole de transfert largement répandu : HTTP Utilise un langage de requête simple et intuitif : CQL Son application permet d’envisager une recherche fédérée

58 au navigateur SRU (Search/Retrieve via URL) et SRW (Search/Retrieve Web service) ReST = Representational State Transfer SOAP = Simple Object Access Protocol Encode une requête au sein d’une URL Encode une requête au sein d’une URL Renvoie un fichier XML (entre autres formats) Base au format hétérogène Base de nature hétérogène : Tout objet (msg, archive,…)

59 SRU et SRW utilisent le protocole HTTP pour l’échange de requêtes
SRU et SRW utilisent le protocole HTTP pour l’échange de requêtes. Plus spécifiquement, SRU permet de faire circuler des requêtes à l’intérieur des URLs en utilisant l’architecture REST (Representational State Transfer) là où SRW, variante de SRU, fait transiter les requêtes sous SOAP (Simple Object Access Protocol). Pour ce qui concerne REST et SOAP, le premier permet de spécifier l’encodage d’une requête au sein même d’une URL, alors que le second encapsule la requête sous XML. REST ne fonctionne qu’avec le protocole HTTP, là où SOAP autorise en plus l’usage de nombre d’autres protocoles ( , SSH, telnet). SRU/SRW utilisent tous les deux les mêmes instructions, qui permettent l’expression de la requête et de la réponse à cette requête. Les trois opérations principales sont « explain », « scan », et « searchRetrieve »

60 Il repose sur des standards :
REST Rest est un style d’architecture, pas un standard, mais décrit des principes fondamentaux qui permettent de bien former une application. Il repose sur des standards : • URI, syntaxe universelle pour « adresser » les ressources, • HTTP un protocole sans état (stateless) avec un nombre très limité d'opérations, • Des liens hypermedia dans des documents (X)HTML et XML pour représenter à la fois le contenu des informations et la transition entre états de l'application, • Les types MIME comme text/xml, text/html, image/jpeg, application/pdf, video/mpeg pour la représentation des ressources SOAP Il permet la transmission de messages entre objets distants, et autorise un objet à invoquer des méthodes d'objets physiquement situés sur un autre serveur. Le transfert se fait le plus souvent à l'aide du protocole HTTP, mais peut également se faire par un autre protocole, comme SMTP. Le protocole SOAP est composé de deux parties : une enveloppe, contenant des informations sur le message lui-même afin de permettre son acheminement et son traitement, un modèle de données, définissant le format du message, c'est-à-dire les informations à transmettre. Avantages de SOAP : assez ouvert pour s'adapter à différents protocoles de transport. indépendant de la plate-forme. indépendant du langage. simple et extensible.

61 SRU (et SRW) http://www.loc.gov/standards/sru/
Utilisent tous deux le protocole HTTP pour l’échange de requêtes SRU propose une interface pour l’interaction avec des bases de données distantes, sans qu’il y ait besoin de connaître la logique interne de la base de donnée consultée pour trouver des résultats S’appuie sur un langage de requêtes CQL (Contextual Query Language, anciennement Common Query Language). Les requêtes sont acheminées via le protocole HTTP Les résultats sont transmis en XML SRU gère des paramètres, au nombre de 12 Nom Obligatoire/facultatif Description operation Obligatoire La chaîne : ‘SearchRetrieve’ version La version de la requête. Si le serveur ne peut pas fournir une réponse dans la version spécifiée ou une version inférieure, il doit retourner un diagnostique

62 Nom Obligatoire/facultatif Description request Obligatoire Contient une requête exprimée en CQL, qui demande à être traitée par le serveur. Une requête CQL peut contenir une ou plusieurs clauses reliée par des opérateurs booléens startRecord Facultatif* Spécifie la position du premier enregistrement visé. Doit être > 0. La valeur par défaut 1 est attribuée par le serveur si elle n ’est pas spécifiée dans la requête. maximumRecord Le nombre maximum de notices à être retourné. La valeur doit être 0 ou plus. Une valeur par défaut est attribuée par le serveur si elle n’est pas définie dans la requête. La valeur retournée peut être inférieure à celle qui est tolérée, mais ne doit pas être supérieure. recordPackinq Facultatif Spécifie la façon dont les notices doivent être empaquetées : chaîne de caractère simple(‘string’) ou XML (‘xml’). recordSchema Schéma dans lequel la notice doit être fournie. La valeur est l’URI du schéma ou son affichage abrégé défini par le serveur (*) [voir tableau] recordXPath (V1.1) Une expression Xpath (chemin XML) peut être appliquée aux notices avant qu’elles soient retournées, relativement au schéma spécifié dans le paramètre recordSchema. Sert à préparer la conversion XSL.

63 Exemple de requête Paramètres :
Nom Obligatoire/facultatif Description resultSetTTL Facultatif Nombre de secondes pendant lesquelles la requête du client doit être maintenue. Le serveur peut être programmé pour ignorer ce paramètre et offrir un temps de réponse qui ne correspond pas à celui spécifié. sortKeys (V1.1) Contient une séquence de clés de classement appliquée au résultat. Stylesheet Spécifie une URL pour appliquer une feuille de styles. extraRequestData Emplacement prévu pour des informations supplémentaires … Exemple de requête Paramètres : obligatoires facultatifs version=1.1 operation=searchRetrieve query=balzac maximumRecords=3000 recordSchema=dc

64 Réponse pour

65 Réponse pour […]

66 Réponse pour […]

67 Paramètre de contrôle du schéma
Schema (and link/reference) Short Name Identifier Dublin Core Record Schema (.xsd   .html ) dc info:srw/schema/1/dc-v1.1 SRU Diagnostic Schema diag info:srw/schema/1/diagnostic-v1.1 Explain Schema zeerex MODS Schema Version > Version 3.3 mods info:srw/schema/1/mods-v3.x ONIX DTD Version 2.0 onix info:srw/schema/1/onix-v2.0 MARCXML: The MARC 21 XML Schema marcxml info:srw/schema/1/marcxml-v1.1 EAD DTD Version 2002 ead info:srw/schema/1/ead-2002 Zthes DTD, version 0.5 Zthes UNIMARC XML Schema unimarcxml info:srw/schema/8/unimarcxml-v0.1 The Bibliographic Class DTD dlxs-bib info:/srw/schema/10/dlxs-bib-v1.0 Dublin Core Extended (DCX) dcx info:/srw/schema/1/dcx-v1.0 PICA XML Version 1.0   pica-xml-v1-0.xsd) pica-XML info:srw/schema/5/picaXML-v1.0 MADS Schema Version 1.0 reference | schema mads info:srw/schema/1/mads-v1.0 Zthes Schema Version 1.0 reference | schema zthes ISO Schema for holdings reference | schema isohold info:srw/schema/5/iso20775-v1.0 PRISM Aggregator Message Record Schema Version 2.0 pam info:srw/schema/11/pam-v2.0 Document Availability Information API (DAIA/XML) reference | schema PRISM Aggregator Message Record Schema Version 2.1 info:srw/schema/11/pam-v2.1

68 La 1ère notice du même lot avec le paramètre &recordSchema=marcxml :
  <?xml version="1.0" ?> <zs:searchRetrieveResponse xmlns:zs="   <zs:version>1.1</zs:version>   <zs:numberOfRecords>415</zs:numberOfRecords> <zs:records> <zs:record>   <zs:recordSchema>info:srw/schema/1/marcxml-v1.1</zs:recordSchema>   <zs:recordPacking>xml</zs:recordPacking> #Début de la notice <zs:recordData> <record xmlns="   <leader>01100nam a a 4500</leader>   <controlfield tag="001"> </controlfield>   <controlfield tag="005"> </controlfield>   <controlfield tag="008">940127s1993 quca b fre</controlfield> <datafield tag="035" ind1="" ind2="">   <subfield code="9">(DLC) </subfield> […] <datafield tag="245" ind1="0" ind2="4">   <subfield code="a">Les Accros du langage /</subfield>   <subfield code="c">sous la direction de Michèle Nevert.</subfield> Il existe aussi une « classe » unimarcxml…

69 Le paramètres pour la réponse
Le réponses SRU sont fournies au format XML Nom Type Obligatoire / Facultatif Description version xsd:string Obligatoire La version de la réponse. Doit être égale à la version demandée par le client. numberOfRecords xsd:integer Le nombre de notices correspondant à la requête. Valeur= 0 en cas d’échec de la requête resultSetId Facultatif L’identificateur de l’ensemble des résultats créé par l’exécution de la requête. resultSetIdleTime Le nombre de secondes entre la création et la suppression d’un résultat. Après ce délai, le résultat ne sera plus disponible. records Séquence de <notices> Série de notices qui correspondent à la requête. nextRecordPosition Xsd:integer La position qui suit le résultat final. S’il n’y a pas de « reste », ce paramètre doit être fixé à 0. XSD = XML Schema Document = fichier de description de structure

70 Nom Type Obligatoire / Facultatif Description diagnostics Séquence de <diagnostique> Facultatif Si les choses tournent mal, le serveur doit signaler ce qui n’a pas fonctionné, expliquer ce qui s’est passé. Les diagnostiques sont retournés dans un schéma très simple, qui ne dispose que de 3 éléments: « URI », « details » et « message ». extraReponseData <xmlFragment> Information supplémentaire retournée par le serveur. echoedSearchRetrieveRequest <echoedSearch RetrieveRequest> Les paramètres de la requête sont renvoyés au client dans un simple formulaire. Exemple :requête SRU qui renvoie des métadonnées d’un document dont la mention de responsabilité somprend la chaîne de cactères « spurr »

71 Réponse : <searchRetrieveResponse>
<version>1.1</version> <numberOfRecords>1</numberOfRecords> <records> <record> <recordSchema>info:srw/schema/1/dcv1.1</recordSchema> <recordPacking>xml</recordPacking> <recordData> <srw_dc:dc xmlns:dc=" xmlns:srw_dc=" <dc:title>Introduction to the study of literature</dc:title> <dc:creator>Spurr David</dc:creator> <dc:publisher>Faculté des lettres</dc:publisher> <dc:date> </dc:date> <dc:type>cours</dc:type> <dc:format>audio</dc:format> <dc:identifier>AN3-SPUR </dc:identifier> <dc:source> 14.3.mp3</dc:source> <dc:relation>AN3-SPUR </dc:relation> <dc:coverage> </dc:coverage> <dc:rights>Spurr David</dc:rights> </srw_dc:dc> </recordData> <recordPosition>1</recordPosition> </record> </records> </searchRetrieveResponse>

72 Exemples d’erreurs : <?xml version="1.0" ?> - <zs:searchRetrieveResponse xmlns:zs="   <zs:version>1.1</zs:version>   <zs:numberOfRecords>0</zs:numberOfRecords> - <zs:diagnostics xmlns=" - <diagnostic>   <uri>info:srw/diagnostic/1/10</uri>   <message>Query syntax error</message>   <details />   </diagnostic>   </zs:diagnostics>   </zs:searchRetrieveResponse> 1   <?xml version="1.0" ?> - <zs:searchRetrieveResponse xmlns:zs="   <zs:version>1.1</zs:version>   <zs:numberOfRecords>0</zs:numberOfRecords>   </zs:searchRetrieveResponse> 2

73 3 <?xml version="1.0" ?> 4 5 <?xml version="1.0" ?>
- <zs:searchRetrieveResponse xmlns:zs="   <zs:version>1.1</zs:version> - <zs:diagnostics xmlns=" - <diagnostic>   <uri>info:srw/diagnostic/1/8</uri>   <message>Unsupported parameter</message>   <details>maximumRecords2000&recordSchema</details>   </diagnostic>   </zs:diagnostics>   </zs:searchRetrieveResponse> 3   <?xml version="1.0" ?> - <zs:searchRetrieveResponse xmlns:zs="   <zs:version>1.1</zs:version>   <zs:numberOfRecords>0</zs:numberOfRecords> - <zs:diagnostics xmlns=" - <diagnostic>   <uri>info:srw/diagnostic/1/28</uri>   <message>Masking character not supported</message>   <details>2</details>   </diagnostic>   </zs:diagnostics>   </zs:searchRetrieveResponse> 4   <?xml version="1.0" ?> - <zs:searchRetrieveResponse xmlns:zs="   <zs:version>1.1</zs:version>   <zs:numberOfRecords>10000</zs:numberOfRecords>   </zs:searchRetrieveResponse> 5

74 SRU Termes de recherche : Ok Bibliothèque du Congrès JSTOR

75 SRU balzac literature | v Termes de recherche : Ok
Bibliothèque du Congrès JSTOR

76 Construction d’une requête type SRU à partir des termes saisis :
Termes de recherche : balzac literature | Ok v Bibliothèque du Congrès JSTOR Construction d’une requête type SRU à partir des termes saisis : ?version=1.1 &operation=searchRetrieve &query=balzac+and+literature &maximumRecords=2000 &recordSchema=marcxml = URL de base = version de la requête = opération demandée = paramètres de la requête = nb. max. de rép. souhaitées = format de réponse souhaité NB : ici, le format souhaité est le paramètre « marcxml ». Schéma dans lequel la notice doit être fournie. La valeur est l’URI du schéma ou son affichage abrégé défini par le serveur.

77 CQL Langage formel qui permet de présenter des requêtes à des systèmes de recherche comme des catalogues bibliographiques, des collections de musées ou des index web. Langage intuitif, aisé à composer et lisible par les humains (HR) Définition formelle : CQL BNF (Backus-Naur Form)

78 Recherches simples: dinosaur "complete dinosaur" title = "complete dinosaur" title exact "the complete dinosaur" Requêtes utilisant des opérateurs booléens: dinosaur or bird dinosaur and "ice age" dinosaur not reptile dinosaur and bird or dinobird (bird or dinosaur) and (feathers or scales) "feathered dinosaur" and (yixian or jehol) Recherches visant des critères de publication: publicationYear < 1980 lengthOfFemur > 2.4 bioMass >= 100 Recherches de proximité de termes: ribs prox/distance<=5 chevrons ribs prox/unit=sentence chevrons ribs prox/distance>0/unit=paragraph chevrons Recherches à plusieurs dimensions: date within " " dateRange encloses 2003 Recherches basées sur la pertinence: subject any/relevant "fish frog" subject any/rel.lr "fish frog"

79 Quelques plates-formes SRU disponibles…
En France ABES Ailleurs en Europe Finlande : NELLI Dutch union Catalog Espagne : Biblioteca Virtual del Patrimonio Bibliográfico Au niveau européen projet TEL, la Bibliothèque européenne Aux Etats-Unis J-STOR ARTstor Worldcat Beta Library of Congress

80 Les « grammaires » de l’interopérabilité (synthèse)
API : Application Programming Interface Une API est un outil utile au programmeur qui va y trouver une description du comportement d’un programme informatique. Elle définit des méthodes et des fonctions (onparle aussi de « signature ». Elle décrit les paramètres attendus pour lancer une méthode et le résultat produit, le plus souvent : sa forme son type son « sens » On peut aussi y trouver les conditions que l’utilisation du programme impose et des indications sur l’environnement requis. Exemple : On trouve des indications sur le connecteur SQL

81 Les « grammaires » de l’interopérabilité (synthèse)
Jeu de métadonnées Cadre générique d’implémentation protocoles Langage(s) de requêtes Divers J2EE – PHP – Html… API SQL – SQL + - MySQL MARC < Z … ISO 2709 Z39.50 Internes aux applications LOM – DC – TEF – MarcXml… XML OAI-PMH HTTP - index RDF SPARQL for RDF SPARQL Query for RDF DC – MarcXml … SRU/SRW SOAP/REST CQL DC – XML - URL WebServices Divers langages possibles

82 RDF et SPARQL RDF est un modèle, plus qu’un format : il permet une description « étoilée » d’un objet ou d’une ressource et ménage une relation privilégiée entre des sous-éléments. RDF peut être exprimé avec la théorie des ensemble ou la théorie des modèles (formation d’arcs) et ne gère pas forcément du XML, mais W3C l’a orienté comme tel dans son exploitation pour le web. Un document structuré en RDF est un « triplet », une association de 3 éléments : sujet = représente la ressource décrite (URI) prédicat = une propriété applicable à la ressource (URI) objet = la valeur du prédicat (URI) On parle aussi de représentation par graphe (ou graphe RDF) Pour décrire un site web, par exemple « European Society for Oceanists », il faut isoler : le sujet (la ressource) : le prédicat (propriété) : l’objet : «  European Society for Oceanists » Ce triplet permet d’identifier le sème suivant : (voici) un site web dont la localisation est et dont le titre est ; «  European Society for Oceanists »

83 « Notice » RDF : <?xml version="1.0"?> <rdf:RDF xmlns:rdf=" xmlns:dc=" <rdf:Description rdf:about=" "> <dc:title> European Society for Oceanists </dc:title> <dc:author>ESfO Directory Membership</dc:author> <dc:subject>Oceanography</dc:subject> <dc:subject>Oceans</dc:subject> <dc:subject>Digital humanities</dc:subject> </rdf:Description> </rdf:RDF> Liste des assertions utilisées dans ce cas : TITRE European Society for Oceanists AUTEUR = ESfO D.M. MOT SUJET = Oceanography MOT SUJET = Oceans

84 Son langage dédié : SPARQL
Recommandation W3C (qui tente de déboucher rapidement sur une normalisation) Principales spécifications: SPARQL protocol for RDF Décrit le protocole d’accès distant pour créer des requêtes et recevoir des réponses SPARQL Query Results XML Format Définit le format de document XML pour représenter les résultats des requêtes SELECT et ASK. Introduction de requêtes simples Soit la donnée : ‘’ Titre de mon ouvrage’’ . Requête : SELECT ?title WHERE { 1 ?title } Réponse : title ‘Titre de mon ouvrage’

85 Requêtes sur des personnes
Pour définir des personnes, on peut utiliser plusieurs balises : title, nickname, gender, etc. Une personne est identifiée par un fichier FOAF, qui peut être placé n’importe où sur le Web, et qui contient, dans des champs normés et en XML, des informations la décrivant. Chacun peut choisir le nombre et la profondeur des informations le concernant, parmi : le nom, l’adresse , l’adresse du site Web et/ou du blog, les adresses des photos, les études suivies, les centres d’intérêt, les , etc. (plusieurs dizaines de champs possibles, répartis en cinq grandes catégories : - les données de base (nom, prénom, etc.), les informations personnelles (centres d’intérêt, connaissances...), les comptes en lignes ( , messageries instantanées...), les documents et images (textes produits par la personne, photos personnelles...), les groupes et projets. Pour la dernière il est possible d’exprimer le rattachement d’une personne à une organisation (association, entreprise) mais surtout, plus généralement, à un groupe quelconque. Il peut s’agir d’un groupe structuré (parti politique), informel, ou simplement d’une communauté en ligne. Les champs FOAF sont conçus pour exprimer de façon détaillée les caractéristiques d’un individu et « ses liens » avec d’autres éléments ou entités du réseau (documents, images, ou d’autres individus. Présente un intérêt pour le web sémantique et permet de répondre à des questions complexes du type : y-a-t-il quelqu’un qui travaille dans un BU, qui catalogue des ouvrages anciens, qui a des connaissances expertes en paléographie et qui fasse partie d’un groupe de normalisation ?

86 FOAF permet la fusion et le rebond sur une base de connaissance qui peut s’enrichir très aisément et rapidement. (« cit. F. Lapique) : «  Supposons que Pierre crée son fichier FOAF, et qu’il ne dispose pas de photos de lui-même. L’un de ses amis, Paul, a lui aussi un fichier FOAF, dans lequel il indique l’adresse d’une photo le montrant en compagnie de Pierre. Il est alors très facile, de façon automatisée, de fusionner les deux fichiers FOAF pour que la question « Où peut-on consulter une photo de Pierre ? » fournisse une réponse, en renvoyant sur la photo présentant Pierre et Paul ». Même si l’on ne dispose pas d’un annuaire centralisé ou d’un fichier complet d’autorités, il est possible de lier des personnes , de lier leurs attributs, comme si toutes ces entrées figuraient dans un même base de données.

87 Soit une notice RDF pour le graphe foaf:blogger
<foaf:Agent rdf:nodeID="id "> <foaf:name>Dave Beckett</foaf:name> <rdf:type rdf:resource=" <foaf:weblog> <foaf:Document rdf:about=" <dc:title>Journalblog by Dave Beckett</dc:title> <rdfs:seeAlso> <rss:channel rdf:about=" <foaf:maker rdf:nodeID="id "/> <foaf:topic rdf:resource=" <foaf:topic rdf:resource=" </rss:channel> </rdfs:seeAlso> </foaf:Document> </foaf:weblog> <foaf:interest rdf:resource=" <foaf:interest rdf:resource=" </foaf:Agent> Je cherche l’URL du Blog de Dave Beckett PREFIX foaf: < SELECT ?url FROM < WHERE { ?contributor foaf:name "Dave Beckett" . ?contributor foaf:weblog ?url . } | url | ============================= | < |

88 Ex: rapatrier le nom d’une personne et éventuellement son pict
Le requêtage SPARQL s’inspire de SQL (modèle simple). On peut ajouter une clause DISTINCT après SELECT ou LIMIT, OFFSET, et ORDER après WHERE Clauses : OPTIONAL UNION FILTER Ex: rapatrier le nom d’une personne et éventuellement son pict Ex. Trouver les personnes qui ont un et celles qui ont un pict Impose des contraintes sur les variables (Ex. on veut trouver toutes les auteurs des publications du mois de septembre 2009) Dans la documentation SPARQL, il est fait mention d’une autre syntaxe un peu différente : Turtle (pour « Terse RDF Triple Language) Soit l’ensemble de données : @prefix dc: < . @prefix : < . @prefix ns: < . :book1 dc:title "SPARQL Tutorial" . :book1 ns:price 42 . :book2 dc:title "The Semantic Web" . :book2 ns:price 23 . Soit la requête : PREFIX dc: < PREFIX ns: < SELECT ?title ?price FROM <ex1.ttl> WHERE { ?x dc:title ?title . OPTIONAL { ?x ns:price ?price . FILTER (?price < 30) } } Résultat : | title | price | ============================== | "The Semantic Web" | 23 | | "SPARQL Tutorial" | |

89 Je veux un service qui m’indique les 10 derniers articles des personnes que Pierre Gille connaît :
PREFIX foaf: < PREFIX rss: < PREFIX dc: < SELECT ?title ?known_name ?link FROM < FROM NAMED <profil.rdf> WHERE { GRAPH <profil.rdf> { ?me foaf:name "Pierre Gille" . ?me foaf:knows ?known_person . ?known_person foaf:name ?known_name . } . ?item dc:creator ?known_name . ?item rss:title ?title . ?item rss:link ?link . ?item dc:date ?date. } ORDER BY DESC(?date) LIMIT 10 1. On cherche dans le graphe profil.rdf, : 2. on cherche dans le dataset les contributions de ses connaissances (on précise que l’on veut un résultat au format XML 3. On classe les résultats par date pour avoir les derniers, que l’on limite à 10 Si les personnes trouvées ont indiqué leur localisation (eg: <geo:Point geo:lat="51.473" geo:long=" "/>), on peut imaginer des possibilités encore plus étendues avec l’intégration de l’API Google Maps ! Et répondre à des questions encore plus complexes sous forme de service : Je cherche la localisation sur une carte des bibliothèques dépositaires des 3 derniers articles produits par les auteurs de tel séminaire…

90 SPARQL : les formes de recherche
SELECT Retourne toutes ou une partie des informations qui correspondent à une requête formulée CONSTRUCT Retourne un graphe RDFconstruit par substitution de variables dans un modèles à trois dimensions (triplet) : _:a foaf:name ‘Alice’ _:a foaf:mbox CONSTRUCT { < .org/person#Alice > vcard:FN ?name } WHERE { ?x foaf:name ?name } Crée des propriétés vcard à partir des informations FOAF: => < .org/person#Alice > vcard FN ‘Alice’ ASK Retourne un indicateur booléen qu’une requête ait des réponses ou pas ASK { ?x foaf:name ‘Alice’} S’il en existe une, la réponse sera ‘yes’ La réponse est enveloppée dans le code : <?xml version=1.0 <sparql xmlns= « – results# » > <head></head> <results> <boolean>true</boolean> </results> </sparql> DESCRIBE Retourne un graphe RDF qui décrit la ressource trouvée : fonction informative

91 OpenURL Le but d’openURL est de créer un lien entre une référence et une ressource plein-texte présente dans un bouquet auquel une bibliothèque est abonnée ou dans une archive ouverte. Propose une syntaxe pour exprimer une référence au sein d’une URL Une base bibliographique doit être capable de produire une URL qui ne point pas vers une ressource donnée, mais qui la décrive d’un point de vue purement bibliographique. Réunit une ensemble de métadonnées qui décrivent une ressource. Ces métadonnées véhiculées par une requête HTTP peuvent être interprétées par le fournisseur de contenu. Construction d’une URL avec un vocabulaire de requête normalisé: ?genre=article&aulast=lecomte&aufirst=Sébastien&title=XML et l’expression de la temporalité&isbn= xxxx-xxxx nom=Lecomte auteur prénom=Sébastien titre= XML et l’expression de la temporalité isbn= xxxx-xxxx

92 Requête d’utilisateur (web)
openURL Service lié aux extensions des « OPAC de nouvelle génération », OpenURL permet à un catalogue de manifester l’existence d’un ressource accessible pour un utilisateur donné Requête d’utilisateur (web) Base de références Résolveur openURL Signale l’existence de la ressource si elle est accessible Base de contenus: - Bouquet de périodiques électroniques - Archive ouverte Crée un lien vers la ressource

93 WebServices Un serveur propose des fonctions qui peuvent être invoquées à distance via le web. Méthode héritée de RPC (Remote Procedure Call), famille UNIX. S’appuient sur HTTP et ne nécessitent pas d’ouverture de ports particuliers sur les firewalls. Protocoles utilisés : SOAP, XML-RPC Offrent la possibilité de manifester des fonctions agrégées dans une page web, et d’embarquer un contexte (par exemple un ticket d’authentification). Les bibliothèques pourraient par exemple proposer une consultation de leur catalogue à travers un environnement particulier ou un ENT, via WebService.

94 Pratiques des usagers : émergence de nouveaux besoins
Exemple avec iGoogle

95 Exemple avec NetVibes

96 Dispositifs ASYNCHRONES

97 La récupération de données

98 Une notice enregistrée au format ISO 2709 présente le schéma suivant :
L’échange de données en iso2709 Une notice enregistrée au format ISO 2709 présente le schéma suivant : Voir aussi :

99 Exemple de notice : de l’isbd à iso2709
XML par la pratique [Texte imprimé] : bases indispensables, concepts et cas pratiques / [Sébastien Lecomte]. - Nantes : Éd. ENI, cop vol. (353 p.) : ill., couv. ill. ; 21 cm. - (Ressources informatiques, ISSN ). Index ISBN (br.) : 27,14 EUR. - EAN Label 01510nam i ­a ­bBr.­d EUR- ­a d2008 m |0fre|01 ||||ba-0 ­afre- ­aFR- ­aa 0||y|-1 ­aXML par la pratique­ebases indispensables, concepts et cas pratiques­fSÂebastien Lecomte- ­a2e Âed.- ­aNantes­cENI­ d2008- ­a ­a353 p.­cillustrations en noir et blanc­d22 x 18 cm-2 ­aRessources informatiques­x ­aPrÂesentation des concepts fondamentaux de XML au travers de cas pratiques Áa implÂementer. Aborde notamment la syntaxe du langage XML, montre comment concevoir des documents et des grammaires XML simples, comment lier des documents XML entre eux, et comment mettre en forme des documents XML.- ­aTous niveaux- ­b ­ ­tRessources informatiques­x ­aXML (langage de balisage)-0 ­aInternet­alangage de programmation­astructure de donnÂees ­adocument multimÂedia- ­a005.3­v99- ­a004­v99a- 1­ ­aLecomte­bSÂebastien­ ­aFR­bElectre­c ­gAFNOR- ­ ­aExtendible markup language­ ­aExtensible markup language- ­aTous niveaux- ­aTechniques Informatique- ­ aLivres pratiques Autoformation- ­c27.14- Répertoire Zones Séparateur de notices (invisible)

100 le LABEL (taille fixe : 24 octets)
nombre d’octets! Si on décompose le label de la notice de la façon indiquée, on a 8 "groupes" d'information. 01510nam1· i·450· Ce qui nous donne : 1 2 3 4 5 6 7 8 01510 nam am1- 00361 2i· 450·

101 le répertoire (taille variable)
Le répertoire comprend les éléments suivants : a/ une étiquette (=3 octets) b/ une longueur de zone qui correspond à la position 20 du label (=4 octets) c/ la position du premier caractère qui correspond à la position 21 du label (=5 octets) d/ longueur de la partie relative à l'application qui correspond à la position 22 du label (=0 octet) b+c+d= « 450 » du label UNIMARC Si on lit le répertoire de notre notice en suivant la fréquence de 3/4/5/0 octets :

102 … on obtient :

103 XML par la pratique [Texte imprimé] : bases indispensables, concepts et cas pratiques / [Sébastien Lecomte]. - Nantes : Éd. ENI, cop vol. (353 p.) : ill., couv. ill. ; 21 cm. - (Ressources informatiques, ISSN ). Index ISBN (br.) : 27,14 EUR. - EAN

104 01510nam i ­a ­bBr.­d EUR- ­a d2008 m |0fre|01 ||||ba-0 ­afre- ­aFR- ­aa 0||y|-1 ­aXML par la pratique­ebases indispensables, concepts et cas pratiques­fSÂebastien Lecomte- ­a2e Âed.- ­aNantes­cENI­ d2008- ­a ­a353 p.­cillustrations en noir et blanc­d22 x 18 cm-2 ­aRessources informatiques­x ­aPrÂesentation des concepts fondamentaux de XML au travers de cas pratiques Áa implÂementer. Aborde notamment la syntaxe du langage XML, montre comment concevoir des documents et des grammaires XML simples, comment lier des documents XML entre eux, et comment mettre en forme des documents XML.- ­aTous niveaux- ­b ­ ­tRessources informatiques­x ­aXML (langage de balisage)-0 ­aInternet­alangage de programmation­astructure de donnÂees ­adocument multimÂedia- ­a005.3­v99- ­a004­v99a- 1­ ­aLecomte­bSÂebastien­ ­aFR­bElectre­c ­gAFNOR- ­ ­aExtendible markup language­ ­aExtensible markup language- ­aTous niveaux- ­aTechniques Informatique- ­ aLivres pratiques Autoformation- ­c27.14-

105 La zone comporte (00)93 octets
01510nam i ­a ­bBr.­d EUR- ­a d2008 m |0fre|01 ||||ba-0 ­afre- ­aFR- ­aa 0||y|-1 ­aXML par la pratique­ebases indispensables, concepts et cas pratiques­fSÂebastien Lecomte- ­a2e Âed.- ­aNantes­cENI­ d2008- ­a ­a353 p.­cillustrations en noir et blanc­d22 x 18 cm-2 ­aRessources informatiques­x ­aPrÂesentation des concepts fondamentaux de XML au travers de cas pratiques Áa implÂementer. Aborde notamment la syntaxe du langage XML, montre comment concevoir des documents et des grammaires XML simples, comment lier des documents XML entre eux, et comment mettre en forme des documents XML.- ­aTous niveaux- ­b ­ ­tRessources informatiques­x ­aXML (langage de balisage)-0 ­aInternet­alangage de programmation­astructure de donnÂees ­adocument multimÂedia- ­a005.3­v99- ­a004­v99a- 1­ ­aLecomte­bSÂebastien­ ­aFR­bElectre­c ­gAFNOR- ­ ­aExtendible markup language­ ­aExtensible markup language- ­aTous niveaux- ­aTechniques Informatique- ­ aLivres pratiques Autoformation- ­c27.14- Etiquette 200 |-1 ­aXML par la pratique­ebases indispensables, concepts et cas pratiques­fSÂebastien Lecomte- La zone comporte (00)93 octets Elle commence à la position (00)140

106 Le label des notices est traité comme un simple chaîne
MarcXchange : exemple <?xml version "1.0" encoding="UTF-8" ?> <collection xmlns="info:lc/xmlns/marcxchange-v-1" xmlns:xsi=" <record format="UNIMARC" type="Bibliographic"> <leader>01510nam i 450</leader> […] <datafield tag="200" ind1="1" ind2=" "> <subfield code="a">XML par la pratique</subfield> <subfield code="e">bases indispensables, concepts et cas pratiques</subfield> <subfield code="f">SÂebastien Lecomte</subfield> </datafield> </record> </collection> Le label des notices est traité comme un simple chaîne Le précédent contrôle appliqué par le répertoire ISO 2709 n’existe pas avec MarcXchange (absent du format), il faut le créer via l’applicatif, et le recalculer à chaque conversion vers ISO 2709…

107 MarcXchange : structure du schéma
attribut obligatoire Élément de plus haut niveau attribut facultatif collection id Élément racine : début de la notice record id, format, type Déclaration des zones leader controlfield datafield id id, ind1,… ind8 id tag tag subfield Label de la notice de l’ISO 2709 (24 octets) Elément de contrôle Zone de l’identifiant De l’ISO 2709 id Déclaration des Sous-zones code Structure hiérarchique

108 Cadre d’élaboration général pour des schémas « locaux »
MarcXchange Cadre d’élaboration général pour des schémas « locaux » MARC 21 et UNIMARC sont reconnus comme des schémas locaux, mais nécessitent tout de même des adaptations locales pour la mise en œuvre de MarcXchange. Assure la compatibilité de schémas locaux simples, sans perte d’informations (ou un minimum de pertes qui peuvent être répertoriées). Schéma conçu de façon à contenir des données MARC Peut servir à l’échange de notices MARC ou de « moyen de transport » pour faire migrer des notices au format natif MARC vers DublinCore.

109 Représenter une notice MARC en XML
MarcXchange Usages majeurs Représenter une notice MARC en XML Décrire une ressource en XML Échanger des notices MARC en XML Transférer des notices MARC via des services en ligne (par exemple SRU) Transmettre des données à un éditeur Utiliser un format temporaire qui permet toute forme de transformation : conversion, publication, édition, validation Par exemple, une notice peut entrer dans un « Workflow » (cycle de vie du document) au format XML, dans une application de gestion, puis être « verrouillée » et stockée à nouveau dans un format MARC.

110 OAI

111 Contexte OAI-PMH répond au besoin d’interroger plusieurs bases en exprimant la description des ressources dans un langage uniforme et commun. Les données sont reproduites et stockées dans un entrepôt qui permet de les embrasser toutes à la fois. Cette fourniture est construites en deux temps : une reproduction, puis une agrégation. Les données sont d’abord modelées sur un format commun : XML DC (mais d’autres formats sont possibles) Elles sont ensuite stockées dans une nouvelle base. Le protocole d’échange utilisé est HTTP Il faut ensuite construire un moteur de recherche pour ménager des points d’entrée, des outils de référencement, de classement, etc. (Le moteur de recherche n’est pas fourni par le modèle OAI). De nombreux produits open source sont actuellement disponibles pour mettre en œuvre un modèle OAI

112 OAI-PMH Définition : OAI PMH Open Archive Initiative Protocol for Metadata Harvesting Mvt 1 de l’interopérabiblité : aspect « normatif » : empilement structuré des données Mvt 3 de l’interopérabilité : le protocole d’échange Mvt 2 de l’interopérabiblité : XML DublinCore

113 Origine du schéma : François Nawrocki : Le protocole OAI et ses usages en bibliothèque. (

114 Un peu de vocabulaire… Ressource (‘resource’) : c’est le document qui est décrit par un appareil bibliographique (la réalité à laquelle la description renvoie, une monographie imprimée, un document électronique…) Item : c’est la notice informatique qui contient la description. Cette notice se voit attribuer un identifiant unique supplémentaire, totalement indépendant de celui du système local. Enregistrement (‘record’): ce sont une partie des métadonnées de l’item qui sont choisies et « poussées » dans un fichier XML qui deviennent un enregistrement. OAI-PMH ne travaille pas avec la totalité des données, mais un jeu allégé. Lot (‘set’) : c’est un possibilité d’OAI-PMH pour constituer des ensembles thématiques ou autres (par exemple ; les thèses d’un établissent dans un format donné et pour une période donnée).

115 Métadonnées sur la ressource : le travail du fournisseur d’entrepôt
##‎$a ‎$bBr.‎$d27,14 € 073 #1‎$a par la pratique‎$bTexte imprimé‎$ebases indispensables, concepts et cas pratiques‎$f[Sébastien Lecomte] 210 ##‎$aNantes‎$cÉd. ENI‎$dcop ##‎$a1 vol. (353 p.)‎$cill., couv. ill. en coul.‎$d22 cm 225 informatiques‎$fJoe͏̈lle Musset‎$x ##‎$aIndex 410 ##‎$aRessources informatiques (Nantes), ISSN ##‎$aXML (langage de balisage)‎$2 rameau 606 ##‎$aEchange électronique d'information‎$2rameau 676 ##‎$a006.74‎$v22‎$zeng 700 #1‎$aLecomte, Sébastien ( ; informaticien)‎$4070 item <record> <dc:title> Xml par la pratique : bases indispensables, concepts et cas pratiques</dc:title> <dc:creator>Sébastien Lecomte</dc:creator> <dc:type>Monographie imprimée</dc:type> … </record> <identifier>oai:1380</identifier> record

116 Entrepôt à sémantique commune
Principe général Base 1 (spécificités internes) Base 2 (spécificités internes) Base 3 (spécificités internes) Base 4 (spécificités internes) Création d’enregistrements en DC Création d’enregistrements en DC Création d’enregistrements en DC Création d’enregistrements en DC Spécificité commune Entrepôt à sémantique commune ?query=… Pour l’usager : : formulation d’une requête unique !

117 Mise en œuvre

118 « moissonnage » périodique et planifié
Client Institution A Institution B Système local Entrepôt A : dc Base de donnée locale SET 1 Harvester « moissonnage » périodique et planifié SET 2 Base de donnée locale SET 3 Transformation XSL Base de donnée « OAI » « Ingest » Éditeur (=fournisseur)

119 L’interrogation d’un entrepôt OAI : Méthodes et arguments
Verbe Rôle Arguments Exemples Identity Donne des informations sur l’entrepôt de données - ListSets Demande la liste des lots disponibles sur un entrepôt. resumptionToken gallica:afrique ListMetadataFormats Demande la liste des formats de métadonnées disponibles. Sans paramètre introduit, tous les formats disponibles pour au moins un item sont retournés. Avec le paramètre identifier, seul les formats disponibles pour un item donné sont retournés. identifier oai-dc lom marcXml ListRecords Retourne une liste d’enregistrements correspondant aux différents paramètres (dates, lots demandés). from until metadataPrefix set ListIdentifiers Récupère la liste des identifiants disponibles. GetRecord Permet la récupération d’un enregistrment donné, à partir d’un argument

120 Utilisation d’un handler
Exemple avec 1. Identify >> 2. ListSets >> C’est la balise <setSpec> qu’il faut rechercher pour trouver un set 3. ListMetadataFormats >> NB et 3. répondent à la méthode ‘’verb=‘’ demandent plus de précisions 4. ListRecords demande obligatoirement au moins un argument : (obligatoire) &metadataPrefix (et non pas *MetadaPrefix) : Attend un format de données, par exemple ‘oai_dc’ >> Autres arguments attendus : &set= …voir &ListSets &from : date d’enregistrement (type : AAAA-MM-JJ%) &until : date d’enregistrement (type : AAAA-MM-JJ%)

121 &metadataPrefix (et non pas *MetadaPrefix) :
>> 5. ListIdentifiers demande obligatoirement au moins un argument : (obligatoire) &metadataPrefix (et non pas *MetadaPrefix) : Attend un format de données, ici, ‘didl’ ou ‘oai_dc’ >> Autres arguments attendus : &set= …voir &ListSets &from : date d’enregistrement (type : AAAA-MM-JJ%) &until : date d’enregistrement (type : AAAA-MM-JJ%) <header>   <identifier>oai:bnf.fr:gallica/ark:/12148/bpt6k </identifier>   <datestamp> </datestamp>   <setSpec>gallica:6:61</setSpec>   <setSpec>gallica:monographies</setSpec> </header>

122 &metadataPrefix (comme précédemment)
6. GetRecords demande obligatoirement au moins un argument : &GetRecord (obligatoire) &metadataPrefix (comme précédemment) (obligatoire) &identifier NB Il s’agit de l’identifier du nœud header/identifier et non pas de celui de dc:identifier Explication : l’identifier du header est un enregistrement (une clé  ’’primaire’’ ou ‘’unique’’, tandis que le dc:identifier est une information de l’enregistrement, c’est une donnée. >> On aurait pu avoir à traduire la requête GET avec une URL encodée pour l’identifier, pour tout ce qui suit &identifier= car ce n’est pas l’identifier que l’on demande, mais sa « représentation » dans le langage http (cf tableau URL encoding), ce qui aurait donné : &identifier=oai%3abnf%2efr%3agallica%2fark%3a%2f12148%2fbpt6k852111

123 Messages d’erreur possibles
Liste : badArgument badResumptionToken badVerb cannotDisseminateFormat idDoesNotExist idDoesNotMatch noMetadataFormats noSearchHierarch   <?xml version="1.0" encoding="UTF-8" ?> - <OAI-PMH xmlns=" xmlns:xsi=" xsi:schemaLocation="   <responseDate> T15:48:40Z</responseDate>   <request>   <error code="badVerb">Value of the "verb" argument is not a legal OAI-PMH verb, the verb argument is missing, or the verb argument is repeated. Query string : verb=Record&metadataPrefix=oai_dc. Detailed description : incorrect verb = Record.</error>   </OAI-PMH>

124 et de : http://re.cs.uct.ac.za/ avec le lien ListSets
Le harvesting Etape 1 : interroger un entrepôt et cibler un SET Etape 2 : ingest initial La réponse (POST) est un ensemble de notices XML, décliné dans plusieurs formats, normalisés le plus souvent : DC, LOM, MarcXML, TEF, … Les données recueillies doivent être insérées dans une base locale On peut utiliser un programme pour le faire, mais dans la plupart des SIGB de nouvelle génération, on a besoin d’une étape intermédiaire de transformation XSL Etape 3 : planification d’un update Si l’on veut récupérer des notices de thèses du SUDOC, on peut utiliser une plateforme OAI (du site officiel) qui va nous aider à nous y retrouver : Le handler du SUDOC est Comparaison de et de : avec le lien ListSets

125 Interrogation d’une thèse qui porte l’identifiant ‘2007NAN21013’
Il va falloir utiliser une feuille de transformation TEF (exemple : ) xsl:for-each xsl:if (test=) xsl:when xsl:choose xsl:otherwise xsl value-of Xsl:template select=‘’*’’

126 Application pkpHarvester (public knowledge project) : manipulations

127 Cas particulier d’ORI-OAI

128 Conclusion

129 L’OPAC … vs IGP L’OPAC de SIGB ne remplit plus son rôle de signalement auprès des usagers On préfère parler de SID (ou d’IGP dans certains cas) pour baliser l’accès à des sources hétérogènes. De même, on parlera plutôt d’utilisateur, voire d’usager que de lecteur, et de données plutôt que de notices. L’effort de normalisation est capital pour : - l’homogénéité des données - la qualité des données Avec l’émergence de nouveaux protocoles , les données sont transportées par la couche web et s’ouvrent à d’autres niveaux d’exploitation. Avec l’interopérabilité, les professionnels de l’info-doc pensent leur repositionnement dans le monde de l’information…

130 Merci de votre attention !
ENSSIB – 21 avril 2010 Merci de votre attention ! * *