Transcript support 1 - Groupe technique sur l`adoption de RDA en France

Evolution des catalogues :
Métadonnées, Interopérabilité, web
sémantique, FRBR et RDA
ENS Lyon
17 au 19 juin 2013
Thierry Clavel et Philippe Bourdenet
Programme
Introduction : le contexte
1. Problématique de l’interopérabilité des données en
bibliothèque
 Paysage applicatif
 Exemple d’interopérabilité : le SCD du Maine
 Pourquoi changer ? : Enjeux du Web de données pour les
bibliothèques
2. Métadonnées : jeux et formats
 Expression des données en XML
 Dublin Core, MODS, ONIX, TEI, EAD METS, LOMFR
3. Interopérabilité des systèmes
 Notion de modèle conceptuel
4. Web sémantique et Web de données
5. FRBR et FRAD
6. RDA et le catalogage FRBerisé
Introduction : Le contexte
Bibliothèque scientifique numérique (BSN)
 Une « très grande infrastructure de recherche » créée en
2009
 Un projet qui fédère l’action des acteurs de
l’enseignement supérieur et de la recherche basé sur la
coopération
 9 segments (axes) BSN 1 à BSN9
Projet d’établissement de L’ABES 2012-2015
 Le projet compte 8 axes dont :
 Missions de l’ABES : mutualisation « acquérir, signaler,
diffuser »
 Signalement des ressources électroniques
 « priorité absolue »
 Projet SGBM
 Hub de métadonnées de la recherche
 Faire évoluer les catalogues
2012 : Lancement de 2 études en parallèle
 Etude du cabinet pléiade sur les outils découverte
 Conclusions :
 La mutualisation devrait porter sur les données : base
de connaissances nationale intégrée à GOKB
 Se doter d’un localisateur national
 Etude du groupe de travail SGBM
 3 scénarios
Choix du CA de l’ABES du 31/5/2013
 SGBM : Choix du scénario 2
 Migration des établissements volontaires vers le
SGBM
 Maintien de CBS pour le catalogage (transferts
réguliers vers le SGBM)
 Étude complémentaire de 6 mois pour le
remplacement de CBS
 Etude Pléiade
 Développement d’un localisateur national
Hub de métadonnées de la recherche
•Partenariat ABES-CNRS
•Récupération des métadonnées commerciales ou
institutionnelles sous n’importe quel format
•Dédoublonnage, Conversion et Redistribution des
métadonnées « enrichies » vers les bibliothèques du
réseau
que dit le projet sur FRBR et RDA et les
données ?
 « L’ABES poursuivra dans la voie de l’ouverture et de
l’interopérabilité de ses données sur le web. Elle
expérimentera la mise en oeuvre du modèle FRBR en
concertation avec la BnF dans la perspective de
l’implémentation du code de catalogage RDA »
Ouverture des données (open data) vers une
interopérabilité technique et juridique
 Mouvement international
 Plateforme française d'ouverture des données publiques
 data.gouv.fr
 Exposition des données en RDF
 ABES : licence ouverte (LO) recommandée par la
mission ETALAB pour les données produites par le
réseau
 BnF : idem pour :
 Catalogues
 Gallica
 Data.BnF.fr
Le comité stratégique bibliographique (CSB)
 Composition : ABES, BnF et leurs tutelles
 Nouvelles orientations du paysage bibliographique
français :
 Exposer les métadonnées des catalogues nationaux
sur le Web de données
 FRBRiser les catalogues (BnF et SUDOC)
 Permettre un catalogage FRBRisé en révisant les
normes AFNOR (2015)
 Préparer l’adoption de RDA pour ne pas s’isoler du
contexte international et européen
 rapport d'orientation du 13 novembre 2012
FIN de l’introduction
Open URL et les résolveurs de liens
 OPEN URL : protocole de métadonnées permettant de
faitre des liens contextuels
 Résolveur de liens : outil informatique implémentant la
norme OpenURL et faisant le lien entre une citation
bibliographique et le texte intégral, en fonction des
abonnements de l'établissement.
Discovery tools (outil découverte)
 Logiciel avec fonctions de recherche et facettes
 Réservoir unique
 Rapidité des résultats
 Indexe texte intégral et métadonnées de différentes
bases
 Base de connaissance
 Autres fonctions : fourniture de documents, résolveur de
liens
 Problème récurrent : bruit et pertinence des résultats
Pourquoi changer
nos catalogues ?
ou
Les enjeux du Web de données pour
les bibliothèques
Les catalogues de bibliothèques, monde
merveilleux ?
 On a déjà des normes de catalogage (ISBD, AFNOR…)
 des formats MARC pour saisir et récupérer des
notices…
 Des SIGB qui fonctionnent…
 Des OPAC et des catalogues
collectifs accessibles sur le Web…
Alors, pourquoi vouloir changer ?
1 – changer pour l’usager
Mais d’abord, est ce que nos
catalogues conviennent aux
usagers?
Source : Sylvain Machefert
Source : Sylvain Machefert
1 - changer pour L’usager
 L’usager est avant tout un internaute :
 Il veut tout et tout de suite
 Il veut des contenus précis (un article, une chanson, etc.)
 Il recherche en priorité sur le Web (et pas spécialement dans des
catalogues)
 Il consulte les catalogues en recherche simple à la « google »
Il faut donc :
 Faire évoluer nos catalogues pour les adapter à l’usager
 Ils ramènent trop de réponses (bruit) sans les classer
 Il faut structurer les résultats de recherche pour afficher des
réponses pertinentes
 Aller vers l’usager
 Pousser les contenus et les données des bibliothèques vers les
usagers/internautes donc sur le Web
Data.bnf.fr
Autre exemple
catalogue collectif ciné-ressources
 http://www.cineressources.net/recherche_t.php
« Super » Notice
d'autorité
« nom de personne »
C'est pas merveilleux,
Cette page de résultats ?!
Expérimentation OPENCAT
OPENCAT
2 – changer pour être sur le
Web
Pourquoi Les catalogues de bibliothèques ne sont
ils pas visibles sur le Web ?
 Le Web ne parle pas MARC
 Le Web a ses propres normes
Et surtout …
Les catalogues sont dans
le Web profond
http://www.flickr.com/photos/markhillary/377
4707075/
http://www.flickr.com/photos/7590540
4@N00/5088208539/
Les catalogues de bibliothèques sont
dans des bases de données (silos) qui ne
sont pas indexées par les moteurs de
recherche
2 - Changer pour être sur le Web
Pourquoi adopter les standards du Web sémantique ?
 pour sortir du Web profond et de notre « niche » technologique
des formats MARC
 pour évoluer avec le Web
 pour que la maintenance
de nos catalogues coûte moins cher
3 - Changer pour rationaliser et enrichir le travail
de catalogage
 Récupérer des données produites ailleurs
 Par exemple les biographies de Wikipedia
pour les auteurs
 Ne pas avoir à répéter les mêmes informations
 Réutiliser les données du catalogue
 Par exemple : l’indexation matière
Une indexation-matière
recréée pour chaque notice
Indexation matière
dans le SUDOC :
4- Changer pour que nos données soient
réutilisées
créer des « Données liées ouvertes »
Eclater nos notices en données réutilisables
 pour que n’importe qui puisse réutiliser
 n’importe lesquelles de nos données
 de n’importe quelle manière
Quels outils pour le changement ?
Des modèles conceptuels pour
Structurer l’information
bibliographique
Un code de catalogage
Des Technologies et
normes garantissant
l’Interopérabilité du Web
de données
Web de données
Un espace global d’information, ouvert, qui
permet de lier, exploiter, mettre à disposition,
réutiliser les données sur le Web
Métadonnées : Tentative de définition
- données sur (à propos) d’autres données
- Information structurée qui sert à décrire, trouver, localiser,
gérer, ,,, des ressources
Types de Métadonnées
 Métadonnées descriptives
 Titre, auteur, résumé, mots clés, etc,
 Métadonnées de structure
 Chapitres d’un livre, organisation d’un texte
 Métadonnées de gestion (administratives)
 gestion des droits (propriété intellectuelle)
 Archivage et conservation
 Techniques : format, type, accès aux ressources, etc,
Métadonnées ou notice ?
Métadonnées internes ou externes à une ressource
37
Formats de Métadonnées
- Métadonnées existent dans tous les secteurs
d’activité
- Nombreux formats
- Problème d’interopérabilité
Dublin core : un exemple de métadonnées
Dublin Core
Jeu de métadonnées descriptives normalisées : devenu
une norme ISO (15836) en 2003, maintenu par le DCMI
(Dublin Core Metadata Initiative).
Objectif d’origine:
décrire les ressources électroniques sur Internet dans un
contexte HTML pour faciliter la recherche , avoir des
métadonnées communes à plusieurs communautés
Caractéristiques du Dublin Core :
Simplicité : 15 éléments seulement
Souplesse d’utilisation : tous les éléments sont
facultatifs et répétables
Utilisable dans différents formats : HTML, XML, etc.
Les 15 éléments de base du Dublin Core
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
Title : titre de la ressource
Subject : mots-clés ou language documentaire
Description : présentation du contenu (résumé, table des matières, etc;)
Source : référence à une ressource dont la ressource décrite est dérivée
Language : langue utilisée dans la ressource
Relation : référence à une ressource apparentée
Coverage : couverture spatio-temporelle (périmètre ou domaine
d’application de la ressource)
Creator : auteur principal
Contributor : responsabilité secondaire
Publisher : éditeur (mise à disposition de la ressource)
Rights : gestion des droits
Date : date d’un événement dans le cycle de vie de la ressource
Type : catégorie, fonction ou genre de la ressource (contenu
sémantique)
Format : format, taille de la ressource
Identifier : identifiant (URL, ISSN etc.)
Dublin Core qualifié et non qualifié
Dublin Core non qualifié : utilisation des 15 éléments
seulement
Dublin Core qualifié : Utilisation d’un Référentiel plus
complet : Dubin Core metadata terms
Possibilité de choisir d’autres éléments et des schémas
d’encodage.
•
http://dublincore.org/documents/dcmi-terms/
Exemples de DC qualifié:
1. qualificatifs de raffinement (création de nouveaux éléments)
<meta name="dc.identifier.URI" content=« http://www.enssib.fr">
2.
schéma d’encodage (association d’un élément à un référentiel)
<meta name="dc.subject" scheme = « DDC » content= « 025.314 »>
Exemple pour un site Web
Exemple de notice OAI (métadonnées Dublin
Core)
<record>
<identifier>oai: 2450</identifier>
<dc:title> Accueillir, orienter informer </dc:title>
<dc:creator> Bertrand Calenge</dc:creator>
<dc:type>Monographie imprimée</dc:type>
…
</record>
DC Profil bibliothèques
 http://dublincore.org/documents/library-applicationprofile/
Avantages du Dublin core
 Simplicité
 Reconnaissance internationale : norme ISO
 Utilisation grandissante grâce au protocole OAI
PMH
Limites du Dublin Core
 Globalement encore peu utilisé à l’échelle du Web
 simplicité à double tranchant
 15 éléments de base : insuffisant pour décrire des
ressources complexes
Exercice Dublin Core
 Transposer en DC simple la notice MARC suivante
MODS Metadata Object Description Schema
MODS
 Schéma XML développé par la Bibliothèque du Congrès
pour décrire tout type de ressource
 Métadonnées descriptives
 Adaptation simplifiée du MARC 21
 Indépendant d’un code de catalogage
 Plus riche que le Dublin Core
 Mappings facilités vers différents jeux de
métadonnées : MARC, DC, RDA, ONIX
MODS
 Exemples :
 http://www.loc.gov/standards/mods/userguide/examples.
html
 Vocabulaire MODS en RDF
 http://www.loc.gov/standards/mods/modsrdf/
MODS
 A quoi sert MODS ?
 Décrire des ressources
 Échanger des métadonnées MARC avec d’autres
jeux de métadonnées
 Compatibilité OAI PMH et SRU
 Qui utilise MODS en France ?
 DAPHNE (Données en Archéologie, Préhistoire et
Histoire sur le NEt)
 Portail Musique contemporaine
ONIX Online Information eXchange
 Format de métadonnées en XML de la chaîne éditoriale
commerciale
 éditeurs, diffuseurs libraires
 2 schémas
 ONIX for books
 ONIX for serials
 Fait pour l’échange
ONIX for books
 Guide ONIX avec aperçu et éléments (version en
français 2009)
 200 éléments :
 En tête : expéditeur et destinataire
 6 blocs :
 description du produit
 Enrichissement marketing
 Détail du contenu
 Conditions de publication
 Matériels liés (dont autres œuvres)
 Conditions d’approvisionnement
ONIX
 Utilisation d’ONIX en France :
 Electre / cercle de la librairie
 Produit ses données en ONIX
 ONIX, FRBR RDA et le Web sémantique
 Mapping RDA/ONIX framework
 Production de données FRBrisées en ONIX possible
 ONIX n’est pas disponible sur le Web de données (en
juin 2013)