Le Guide des Bonnes Pratiques Numériques Entrepôt OAI-PMH Version 1, mars 2010 Ce guide peut être téléchargé sur : http://www.tge-adonis.fr/ressources/guides Contributeurs au guide :Laurent Capelli (CCSD), Jean-Luc Minel (TGE Adonis & MoDyCo), Gautier Poupeau (ATOS), Stéphane Pouyllau (CNRS, TGE Adonis ) Remerciements : Les auteurs du guide remercient Nadine Dardenne (TGE Adonis) pour sa relecture attentive.
Table des matières 1. Introduction...3 1.1. Le protocole OAI-PMH...3 1.1.1. Rappel sur la notion de protocole...3 1.1.2. Rappel sur le Dublin Core...4 1.1.3. Recommandations particulières pour la description : Unicode...5 1.2. Les acteurs de l'oai-pmh...6 1.3. Synchronisation entre les acteurs...7 1.4. Première synthèse...7 1.4.1. Que peut-on faire avec l'oai-pmh?...7 1.4.2. Les limites de l'oai-pmh...7 2. Structuration des données...7 2.1 Structuration d'une archive ouverte...7 2.2 Structuration OAI-PMH...8 3. Format des données renvoyées par le protocole OAI-PMH...8 3.1 Sélectionner les données selon un critère thématique...9 4. Les six verbes du protocole...11 4.1. Le rôle du jeton...12 4.2. Requêtes OAI-PMH...13 4.2.1. ListRecords...13 4.2.2. Identify...14 4.2.3. ListIdentifiers...15 4.2.4. ListMetaDatFormat...16 5. Une étude de cas : la création d'un entrepôt OAI...16 6. De l'oai-pmh à RDF...21 7. Bibliographie...23 8. Liens...23
1. Introduction Ce Guide des Bonnes Pratiques - Entrepôt OAI-PMH est une première version relative à la description d un entrepôt conforme aux directives de l «Open Archive Initiative» (OAI) et plus spécifiquement au protocole «Protocole for Metadata Harvesting» (PMH). Rédigé par le TGE Adonis sous l impulsion de l Institut des Sciences Humaines et Sociales, du Bureau des Très Grands Équipements du CNRS et du Ministère de l Enseignement supérieur et de la recherche, ce guide est toutefois amené à évoluer. Dans sa version actuelle, il présente les principes et les conditions techniques à respecter pour construire un entrepôt conforme au protocole OAI-PMH. 1.1. Le protocole OAI-PMH Le protocole OAI-PMH (Open Archives Initiative - Protocol for Metadata Harvesting) est issu de la convention de Santa Fé (21-22 octobre 1999, New Mexico, USA) au cours de laquelle deux objectifs ont été assignés à ce protocole : rendre interrogeables des bases de données hétérogènes et réparties ; définir les conditions qui permettent à des logiciels de collecter massivement les métadonnées et de les stocker dans des entrepôts centralisés ; À l origine, le protocole OAI-PMH a été ainsi mis au point par l Open Archive Initiative pour faciliter l échange et la visibilité des données stockées dans les archives ouvertes, entrepôts d articles scientifiques mis à disposition par les chercheurs eux-mêmes. Il s est peu à peu diffusé dans d autres domaines d applications de par sa simplicité et la disponibilité de nombreux outils. Ce protocole est donc né de de la volonté partagée par une communauté de faire inter-opérer des bases d'archives entre elles. Il s'appuie sur des standards que sont HyperText Transfer Protocol (HTTP, le protocole du web), XML et Dublin Core (cf ci-dessous). 1.1.1. Rappel sur la notion de protocole En toute généralité, un protocole est l ensemble des règles qui définissent le dialogue entre deux interlocuteurs. En informatique, un protocole est l ensemble des règles qui définissent le dialogue entre un client et un serveur. Est considéré comme «client», l'application de l utilisateur lui permettant d accéder à un service. Par exemple, un navigateur Web (Internet Explorer, Firefox, Chrome, ) est un client Web. Le système de réservation de la SNCF par exemple est un service situé sur un serveur Web. HTTP est le protocole du Web permettant de faire dialoguer un navigateur avec un serveur Webclient et un serveur. Par ailleurs, un protocole utilise différentes notions qui sont : les verbes : un ensemble de verbes est géré pour le dialogue les attributs : un verbe peut être complété par un ou plusieurs attributs pour formuler une demande. Par exemple, dans le protocole HTTP utilisé pour gérer le dialogue entre un client et un serveur, le verbe qu utilise le plus souvent le navigateur est «GET». Enfin, un protocole peut en encapsuler un 3
autre. Par exemple, le protocole HTTP est véhiculé dans un autre protocole : le protocole TCP/IP. De cette manière avec le protocole HTTP, il est possible de composer et d'envoyer des messages dont le contenu est constitué d autres verbes et attributs appartenant à un autre protocole. Ainsi, le protocole OAI-PMH est un protocole utilisant HTTP. On dit encore «au-dessus» de HTTP. 1.1.2. Rappel sur le Dublin Core 1 Les métadonnées sont des données qui décrivent d'autres données. On les appelle aussi des descripteurs. Dans les bibliothèques classiques, les documents sont décrits à l'aide de notices bibliographiques où l'on identifie les auteurs, les éditeurs, les titres, les dates de parution, etc. Ces notices sont utiles tant aux bibliothécaires pour la gestion de leur fonds, qu'aux usagers pour retrouver un ouvrage. Pour un document numérique, et plus particulièrement dans le cadre d'une diffusion par internet, ces notices portent le nom de «métadonnées», alors que les documents eux-mêmes sont nommés «ressources». Les documents électroniques prennent de plus en plus d'importance dans notre vie quotidienne et leur nombre ne fait qu'augmenter. Rechercher une «ressource» spécifique est devenu une tâche à la fois complexe et indispensable d'autant plus que cette recherche s'effectue maintenant dans des architectures distribuées (les «ressources» ne se trouvent pas toutes au même endroit physique, sur le même serveur). C'est dans ce contexte que les préoccupations de standardisation et de normalisation des pratiques de codage et d'échange de métadonnées trouvent leurs origines. En 1995, à Dublin (Ohio), des représentants de communautés diverses, issus du monde des bibliothèques, de l'informatique et du web, se réunissent pour définir un noyau commun de métadonnées : le Dublin Core Metadata Initiative (DCMI), abrégé souvent comme Dublin Core ou DC. Le Dublin Core est un ensemble de 15 descripteurs de portée très large et de sens très générique. Certains ont trait au contenu, d'autres à la propriété intellectuelle, d'autres enfin à l'instanciation. Cet ensemble de descripteurs a été normalisé au sein de l'iso en 2003 sous le nom d ISO Standard 15836-2003. Les 15 descripteurs sont les suivants :.1 Contributor.2 Coverage.3 Creator.4 Date.5 Description.6 Format.7 Identifier.8 Language.9 Publisher.10 Relation.11 Rights.12 Source.13 Subject.14 Title.15 Type 1 Cette section est issue du site du Centre de ressources pour la description de l'oral, centre de ressources du CNRS. 4
Des informations supplémentaires sur ces descripteurs peuvent être trouvées sur la page suivante : http://dublincore.org/documents/dces/ Ces éléments de base peuvent, dans certains cas, être jugés insuffisamment précis : il est alors possible d'utiliser un autre ensemble de «qualifiers» qui en précisent l'acception. Dublin-Core définit deux classes de «qualifiers» : Les «refinements» qui rendent plus spécifique le sens d'un élément. Par exemple, à la place de l'élément «date» il est possible d'utiliser l'un de ces «refinements» : created, valid, available, issued, modified, dateaccepted, datecopyrighted, datesubmitted. Les schémas d'encodage, et les vocabulaires contrôlés comme par exemple le schéma «Point» qui permet de définir les propriétés d'un point géographique (coordonnées : longitude, latitude, altitude, référentiel, nom). Le DC peut servir de base au Dublin Core dit qualifié dans lequel il est possible de typer les métadonnées, en utilisant les types de données proposés par le DCMI ou ses propres types de données définis dans un schéma XML. Le Dublin Core simple 2 (ou Dublin Core Element Set) est essentiel, car sans lui l'oai-pmh serait un protocole «babelien»! Le Dublin Core permet de se mettre d accord sur un minimum de terminologie pour désigner les objets. Par exemple, la balise «creator» permet de désigner un auteur ; la balise «source» permet de désigner l adresse du fichier texte, etc. Cette désignation commune va permettre l agrégation du contenu de bases de données différentes. Un schéma de données (schéma XML ou une DTD XML) spécifie un ensemble de contraintes, éléments facultatifs ou obligatoires, ou structures plus complexes. Par exemple, un auteur doit appartenir à un laboratoire qui lui, doit dépendre d une institution, etc. Dans un entrepôt OAI, chaque ressource stockée correspond à un «enregistrement» (ou «record»). Chaque enregistrement est obligatoirement décrit en Dublin Core simple. En plus de cette description en Dublin Core simple, chaque enregistrement peut être décrit suivant un ou plusieurs formats de métadonnées dont le choix est laissé à l appréciation de l administrateur de l entrepôt. Les différents formats de métadonnées utilisés par l entrepôt peuvent être connus par le moissonneur grâce à une requête spécifique. De plus en plus, le Dublin Core Metadata Terms ou DC Terms vient en complément du Dublin Core simple. Le DC Terms est un DC «complet», plus riche, permettant de raffiner les métadonnées. Un entrepôt peut être organisé en différents ensembles d enregistrements («set») qui fonctionnent comme des collections. Un enregistrement peut appartenir à plusieurs ensembles donc à plusieurs «set». Les différents ensembles peuvent être organisés «hiérarchiquement» par utilisation, dans le nom des sets, de valeurs hiérarchiques (ex. : nom de la collection: type d'objet). Par exemple, vous pouvez imaginer avoir des objets particuliers (des descriptions de photographies, par exemple), qui sont regroupés dans un ensemble/set (toutes les photographies d un photographe particulier). 1.1.3. Recommandations particulières pour la description : Unicode Les métadonnées descriptives doivent être encodées en Unicode UTF-8. Unicode est une norme développée par le Consortium Unicode, qui vise à donner à tout caractère de n importe quel système d écriture un nom et un identifiant numérique, et ce de manière unifiée, quelle que soit la plateforme informatique ou le logiciel. Le choix d UTF-8 garanti au mieux que vos données seront lisibles sur n importe quel système d exploitation ou plateforme, si on dispose d une police de caractères adéquate. 2 Voir : Dublin Core Metadata Element Set : http://dublincore.org/documents/dces/ 5
Cette norme concerne l encodage des caractères et non leur visualisation qui a besoin d une police adaptée. Le choix d UTF-8 n a ainsi pas de répercussion sur la police que vous allez utiliser pour visualiser vos données sur l écran. D autres encodages existent (ISO 8859-1 et ASCII par exemple) mais ils sont beaucoup moins complets, particulièrement pour les langues anciennes ou rares. 1.2. Les acteurs de l'oai-pmh Le protocole OAI-PMH implique deux acteurs (voir figure 1): Le fournisseur de données (data provider) qui expose, grâce à une interface Web spécifique, les métadonnées des différents enregistrements contenus dans son entrepôt. Il s agit là des données produites par les chercheurs, les laboratoires, etc. Le fournisseur de services (service provider) qui moissonne un ou plusieurs entrepôts, en utilisant les interfaces exposées par le fournisseur de données, afin d offrir aux utilisateurs des interfaces de recherche ou de navigation. Un fournisseur de service offre donc un seul point d entrée pour rechercher de l information dans un grand nombre d archives ouvertes. Le fournisseur de service peut «retravailler» l information qu il a récoltée pour : Se spécialiser dans une thématique Sélectionner des notices. Par exemple, n exposer que les notices qui ont un fichier de texte intégral Créer un index des auteurs Créer des index thématiques Par exemple, www.oaister.org, aujourd'hui inclus dans l'offre OCLC, est un fournisseur de service, hal.archives-ouvertes.fr est une archive ouverte (ou un entrepôt de données) qui expose les métadonnées via OAI-PMH. Le moteur ISIDORE initié par le TGE Adonis, comme d'autres moteurs de recherche (Crevilles.org, ScientificCommons.org, Driver-Community, etc.) pourront ainsi moissonner les données conformes au standard OAI-PMH. Figure 1 : Les acteurs et le moissonneur (extrait de Capelli 2009). 6
1.3. Synchronisation entre les acteurs Rappelons que l'oai-pmh est un protocole pour LIRE des données dans un entrepôt, par conséquent il n'existe pas d instruction (de verbe) dans le protocole pour insérer des documents ou des notices dans une archive ouverte. En conséquence, l initiative de mise à jour ne peut venir que du fournisseur de services. Le moissonneur moissonne «quand il le souhaite» pour faire la mise à jour, tous les jours ou tous les mois. L utilisateur qui interroge le fournisseur de service n a pas de garantie quant à la fraîcheur de l information collectée. 1.4. Première synthèse 1.4.1. Que peut-on faire avec l'oai-pmh? L'OAI-PMH permet de demander de l information à un serveur d archives ouvertes pour : Connaître la structure de l archive Connaître le format des métadonnées Connaître la nomenclature de classement Récupérer les notices (les métadonnées) Attention, le plus petit objet qu'il est possible de lire avec le protocole, est une notice (ou son identificateur). L accès aux notices ne se fait que de deux manières : On lit une seule notice à la fois en fournissant sa référence On demande à lire la totalité des notices 1.4.2. Les limites de l'oai-pmh L'OAI-PMH n est pas un langage d interrogation de bases de données et est extrêmement limité dans les critères de sélection. En pratique et d un point de vue documentaire, on peut sélectionner: sur un intervalle de temps sur la classification des documents L'OAI-PMH ne permet donc pas de choisir n importe quelle sélection de notices. Par exemple, on ne peut pas demander les seules fiches d un auteur. OAI-PMH n est pas orienté utilisateur. Un utilisateur n interrogera donc jamais directement une archive via OAI-PMH. Il s adressera à un service spécialisé et de fait à un dialogue entre serveurs. L'OAI-PMH est un protocole d extraction d informations : il ne peut donc pas être utilisé pour déposer de l information dans une archive ouverte. L alimentation d une archive ouverte est complètement indépendante du protocole OAI-PMH. 2. Structuration des données 2.1 Structuration d'une archive ouverte La structuration des données dans une archive est indépendante du protocole OAI-PMH. Elle résulte des choix faits par les concepteurs et elle est mise en œuvre au travers d un modèle de données pouvant être exprimé par un schéma de base de données, un schéma XML, une DTD. Les données 7
sont stockées dans une base de données, souvent relationnelle, quelquefois nativement en XML. Une structuration suffisamment élaborée peut permettre : Une représentation thématique du contenu de l archive Une représentation institutionnelle, éventuellement à plusieurs niveaux Une représentation par collection au sens large du terme : Collections institutionnelles Livres, épi-journaux, actes de congrès, etc. 2.2 Structuration OAI-PMH Avec l'utilisation des cinq ensemble, il est possible de hiérarchiser l'information. Ainsi l'oai-pmh supporte la hiérarchisation de l information, mais les moissonneurs ne l exploitent pas nécessairement. L'OAI-PMH reconnaît ainsi le concept de «collection» ( <setdescription> ). Si l'archive ouverte implémente la notion de collection, alors des sélections plus fines deviennent possibles. Au-delà de la sélection thématique, on peut sélectionner une collection. L'OAI-PMH permet au client de retrouver la structure de l archive (verbe <ListSets>). Figure 2 : Un exemple de description de collection (extrait de Capelli, ibid). Il conviendra alors d'exploiter au mieux cette «catégorisation» de l'information du coté de fournisseur de service (moteur de recherche, sites thématiques 3,etc) 3. Format des données renvoyées par le protocole OAI-PMH Les données moissonnées sont «encapsulées» en XML. Par exemple, pour une notice, ce sont au minimum les valeurs du Dublin Core non qualifié qui sont retournées. La figure 3 illustre les données retournées en réponse au verbe ListRecords (ou GetRecords). 3 Nous renvoyons le lecteur à l'exemple du projet Crevilles.org qui illustre ce cas. 8
Figure 3 : Un exemple de données moissonnées (extrait de Capelli, ibid). 3.1 Sélectionner les données selon un critère thématique Pour sélectionner de l information, il est nécessaire qu au préalable celle-ci ait été classifiée. Chaque archive choisit «sa» propre classification, et elle la fait connaître, grâce au verbe «ListSets» du protocole OAI-PMH : Conformément à un schéma XML de données ; Via un nom symbolique qui sera utilisé comme critère de recherche (par exemple <setspec>envir</setspec> ) ; Via un descriptif associé à ce nom symbolique, pour en permettre un affichage compréhensible comme par exemple <setname> Etudes de l'environnement </setname>. Attention, il n existe pas de classification thématique «universelle», ce qui ne facilite pas le travail des «moissonneurs»! Un bon fournisseur de service devrait être le fruit du moissonnage d archives dont les opérateurs se sont concertés pour choisir une thématique commune ou, au moins, un bon niveau d interopérabilité Sans cela, toute présentation thématique par un moissonneur devient périlleuse. Le verbe «ListSets» permet de connaître le modèle de classement d'une archive. La figure 4 illustre l'utilisation de ce verbe. 9
Figure 4 : Un exemple d'utilisation du verbe «Listsets» (extrait de Capelli 2009). Il est possible de traiter une structuration en thèmes et sous-thèmes. Dans l'exemple ci- dessous (figure 5) dans lequel «mathématiques combinatoires» est un sous thème de «mathématiques»: Figure 5 : Un exemple de sous thème (extrait de Capelli 2009). Ainsi le protocole OAI-PMH permet de définir une structure hiérarchique. Le caractère «:» est défini comme séparateur entre les différents niveaux. Ceci permettra ultérieurement de sélectionner toutes les notices de la rubrique «mathématiques» et, parmi celles-ci uniquement celles en «mathématiques combinatoires». Il est aussi possible d'effectuer une sélection au niveau de la fourniture de la notice : la thématique est renseignée par la balise «subject» du Dublin Core : <dc:subject>mathematics/combinatorics</dc:subject> ce qui permet d'obtenir le résultat illustré par la figure 6. Enfin, ne pas oublier qu'il est possible de répéter une balise autant de fois que nécessaire dans une notice, ce qui permet de qualifier des notices avec plusieurs thématiques. 10
Figure 6 : Un exemple de sous-thème (extrait de Capelli, 2009). 4. Les six verbes du protocole Le tableau 1 ci-dessous précise la fonction de chacun des six verbes : Identify ListMetadataFormat ListSets ListIdentifiers donne des informations générales sur le serveur donne le ou les formats dans lesquels sont fournies les notices. On trouvera ici au moins oai_dc correspondant au minimum à du Dublin Core. Le ou les formats sont définis par un schéma XML dont l adresse est donnée dans la réponse donne la structure de l'entrepôt (nomenclature de classement des notices de l'entrepôt, thématique) donne les identifiants pour un MetaDataFormat (il n y a pas de défaut comme oai_dc aurait pu l être)?? ListRecords donne toutes les notices de l'entrepôt en fonction du MetaDataFormat GetRecords donne l enregistrement défini par l «identifier» Tableau 1 : les six verbes (extrait de Capelli, ibid). 11
Le tableau 2 ci-dessous précise les attributs fonction de chacun des six verbes: o: obligatoire f: facultatif e: exclusif Tableau 2 : Les attributs des six verbes (extrait de Capelli 2009). 4.1. Le rôle du jeton Ce paramètre est surtout utile pour l implémenteur. Lors d une demande de liste (ListRecords, ListIdentifiers), l archive ne renvoie qu une fraction des éléments (contrôle de flux). Pour obtenir les éléments suivants, il faut réitérer la demande en fournissant un jeton. Évidemment, on ne peut pas changer les paramètres en cours de demande, pour cette raison, le paramètre «jeton» est exclusif. Le jeton a une durée de vie limitée. Cette durée de vie est indiquée au demandeur. Sont indiqués aussi, la taille de la liste et le nombre de notices déjà envoyées. Figure 7: Un exemple de jeton (extrait de Capelli 2009). 12
4.2. Requêtes OAI-PMH 4.2.1. ListRecords Voici un exemple de requête avec le verbe «ListRecords» : Figure 8 Un exemple de requête (extrait de Capelli, ibid) et voici un autre type de requête : Figure 9 : (extrait de Capelli 2009) qui donnerait le résultat : Figure 10 : (extrait de Capelli 2009) 13
4.2.2. Identify Figure 11 : (extrait de Capelli 2009) 14
4.2.3. ListIdentifiers Figure 12 : (extrait de Capelli, ibid) 15
4.2.4. ListMetaDatFormat Figure 13 : (extrait de Capelli 2009) 5. Une étude de cas : la création d'un entrepôt OAI 4 Le système d'entrepôt OAI-PMH que nous allons créer fonctionne à partir d'une table issue d'une base de données MySQL. Cette table contient les éléments qui seront présentés en Dublin Core et des éléments techniques utiles au pilotage de l'entrepôt OAI-PMH. Nous avons utilisé le module OAIPHP2, développé par d'heinrich Stamerjohanns 5 pour développer cet exemple. Le schéma de fonctionnement est le suivant : Table MySQL ---> PHP (application) ---> données XML. Il s'agit de présenter un exemple simple contenant toutes les étapes. Il faut noter cependant, que de plus en plus de logiciels de gestion de données numériques (Dspace, GreenStone, etc.) ou de SIGB ont des modules OAI-PMH exposant du Dublin Core simple. La présence d'un module OAI-PMH, la possibilité d'exposer les métadonnées sous plusieurs formes (DC simple, DC Terms, OLAC, METS) sont deux critères très important du cahier des charges nécessaire à l'achat d'un outil de SIGB et/ou d'une prestation de service 6. 5.1. Les étapes Les étapes qui vont suivre vont permettre l'alimentation de la table MySQL de l'entrepôt depuis un tableau de données (Excel, OpenOffice, CSV, etc.). Il s'agit de faire une entrée par document (ou une 4 Cette section est issue du Wiki du CN2SV, Centre de ressources du CNRS et écrit par Delphine Usal ( CNRS, CN2SV) et Stéphane Pouyllau (CNRS, CN2SV). 5 Module PHPOAI2 disponible sur http://physnet.uni-oldenburg.de/oai/ 6 Nous renvoyons le lecteur aux compte-rendus des journées FREDOC 2009 (Réseau des documentalistes du CNRS) disponible en ligne : http://phonotheque.hypotheses.org/2566 16
entrée par ressource), c'est donc une fiche détaillée de chaque document. Le tableau 3 explicite les différents champs de la table que nous allons utiliser. Ils correspondent aux champs du Dublin Core simple. CHAMPS COMMENTAIRES serial numéro unique pour une fiche de document entrée, en auto_incrément provider provenance du document url le référent enterdate date d'entrée dans la base du document oai_identifier numéro identifiant OAI unique oai_set type de document (manuscrit, archives documents...) datestamp date d'entrée dans la base du document deleted par défaut «false» dc_title titre du document dc_creator auteur du document dc_subject sujet du document (histoire, philosophie, etc. ) dc_description description du document dc_contributor nom de la ou des personnes ayant contribuée(s) à la mise en ligne du document (numérisation, mise en ligne...) dc_publisher nom de la personne ayant pris l'initiative de publier le document dc_date date du document dc_type type de document (manuscrit, archive, documents...) dc_format format du document pour les documents provenant d'une autre base de données dc_identifier adresse mail du document dc_source adresse mail du document dc_language langue du document dc_relation relation entre la ressource décrite et une ressource tiers (avec lien de parenté ou non) dc_coverage mots clés dc_rights droit de publication (public domain) Tableau 3 : exemple de champs (extrait de Pouyllau, 2009). La figure 17 donne un exemple de cette table administrée avec le gestionnaire phpmyadmin. Il convient ensuite de saisir les champs dans la base de données. Une solution consiste à créer un fichier avec l'outil OpenOffice. Les lignes de ce fichier doivent correspondre aux champs déclarés précédemment dans la table. Copiez dans la ligne numéro 1 le noms des champs de votre table dans l'ordre où ils sont présentés dans PhpMyAdmin. Dans le dernier enregistrement de votre base OAI, regarder quel est le dernier «serial» et le «dernier oai_identifier». Si le «dernier serial» est 3200 et son «oai_identifier» hstl- 0001245, votre premier enregistrement dans le fichier open office aura donc comme «serial» le numero 3201 et son «oai_identifier» sera hstl-0001246. Entrez les renseignements que vous connaissez dans les divers champs (voir le paragraphe précédent sur la description des champs). 17
La figure 14 donne un exemple de fichier créé. Figure 14 : (extrait de Pouyllau 2009) Enregistrez votre document en mode CSV et choisissez comme séparateur de champ le caractère «;». 18
La figure 15 illustre les différentes étapes à suivre pour réaliser cet enregistrement. Figure 15 : Les étapes d'export du fichier (extrait de Pouyllau 2009) 19
Il convient ensuite d'insérer les données contenues dans le fichier OpenOffice dans la table temporaire. Pour cela, cliquez sur la table «hstl_oai_records_w» et ensuite sur l'onglet "Importer". Recherchez votre fichier et sélectionner-le dans "Format de fichier d'importation" CSV via LOAD DATA. Cliquer ensuite sur "exécuter" : un message s'affiche vous informant que votre table a bien été copiée. Figure 16 : Les étapes d'export du fichier (extrait de Pouyllau 2009) Il ne reste alors plus qu'à placer les données en ligne : comme vous venez de passer vos données dans la table temporaire elles ne sont pas encore en ligne. Pour les mettre en ligne : hstl_oai_records devient hstl_oai_records_savjjmmaaaa hstl_oai_records_w devient hstl_oai_records Cliquer sur la table hstl_oai_records, ensuite sur l'onglet «Opérations», entrer le nom souhaité dans la fenêtre «Options pour cette table» «Changer le nom de la table pour «hstl_oai_records_sav03122007». Cliquer sur «executer» : un message s'affiche vous informant que le nom de la table a bien été modifié. Il convient maintenant de faire passer la table temporaire en page active. Pour cela répétez la même opération comme l'illustre la figure 17. 20
«record» est un calque sur le Web de la fiche physique du catalogue papier et renvoie donc à la notion de documents pour décrire un ensemble fini de données sur un autre document. Cela pose deux problèmes principaux du point de vue de la description des ressources : il est très complexe voire impossible d'exprimer des relations entre deux «records» quelle qu'en soit la nature. Le protocole OAI-PMH a ainsi tendance à aplanir la structure des ressources décrites et à les mettre toutes sur le même plan ; la description elle-même du «record», comme elle est exprimée selon le modèle d'arbre XML, limite la description à une structure hiérarchique (souvent très simple comme c'est le cas avec le Dublin Core en XML) et ne permet pas de faire référence explicitement à une autre ressource sur le Web identifiée par une URI. Les initiateurs de l'oai-pmh ont bien conscience de ces limites. C'est pourquoi ils en proposent aujourd'hui une évolution : l'oai-ore basé sur les technologies et les principes du Web sémantique. Ces derniers mois ont vu la constitution d'un Web de données (web of data ou linked data en anglais ). Il ne s'agit pas d'un nouveau Web, mais plutôt d'une nouvelle façon de mettre à disposition et de relier entre-elles des données sur le Web. Son principe est finalement assez simple : il est constitué de milliards d'assertions sur des ressources sous la forme de phrases simples (ou d'une phrase simple). Pour ce faire, le Web de données utilise les technologies du Web sémantique et l'architecture du Web : les assertions sont exprimées selon le modèle RDF : soit le triplet Sujet-Prédicat-Objet, ce qui correspond à la structure d'une phrase simple : Sujet-Verbe-Complément ; chaque composant du triplet est composé d'une URI déréférençable, c'est-à-dire un identifiant localisable au sein du Web. Chaque composant devient ainsi une ressource ; à chaque ressource sont associées une représentation en RDF (le plus souvent avec la syntaxe RDF/XML, mais parfois en N3) pour les machines et une représentation en HTML pour les humains. Ainsi se constitue un hypertexte dans lequel une ressource est reliée à une autre ressource par un lien typé, le prédicat, lui-même exprimé avec une URI. Or, tout l'intérêt de ce Web de données réside dans le fait qu'une ressource peut représenter tout et n'importe quoi : un objet du monde réel (une personne, un lieu, un livre traditionnel...), un concept ou une ressource déjà disponible sur le Web. L'URI en constitue l'identifiant indispensable dans le cadre du Web pour pouvoir exprimer des assertions. Il n'est ici plus question de document à moins d'assimiler le Web de données dans son ensemble à un document, le Web de données n'étant par définition pas fini, tout un chacun pouvant lier une ressource à une autre ressource. Quant à la structure hiérarchique, en plaçant l'assertion au niveau de description le plus fin possible (une phrase simple), elle ne constitue qu'un modèle possible de relations entre les ressources. En poussant la logique du Web à son terme, le Web de données permet de dépasser les limites inhérentes à la notion de document et à la structuration hiérarchique des données. Il ouvre ainsi la voie à une modélisation décentralisée, plus souple et plus proche de notre monde réel. Et, pour ceux que cela effraie, le W3C travaille déjà aux normes et aux techniques qui permettront de mesurer la confiance que l'on peut accorder à telle ou telle assertion. 22
7. Bibliographie Capelli Laurent(2009), «OAI-PMH, le protocole des archives ouvertes», formation CCSD. Pouyllau Stéphane (2009), «OAI-PMH pour la diffusion de corpus documentaires numérisés ou numériques : retours d'expérience», FREDOC 2009. 8. Liens Dublin Core : http://dublincore.org Open Archives Initiative : http://www.openarchives.org OAI-PMH : http://www.openarchives.org/oai/openarchivesprotocol.html Unicode : http://www.unicode.org Mise en ligne de données sous la forme d'un entrepôt OAI-PMH avec PHPOAI2, PHP et MySQL : http:// www.hstl.crhst.cnrs.fr/doc/wiki/index.php/mise_en_ligne_de_donn%c3%a9es_oai- PMH_avec_PHPOAI2_via_PhpMyAdmin 23