Le SUDOC en RDF : du nouveau ! 1/2

A propos du  web de données, et du Sudoc en RDF, voir notamment les billets précédents ici et .

L’été 2013 avait vu la mise en ligne d’une documentation sur l’exposition du SUDOC en RDF, et l’annonce d’un chantier visant à enrichir et affiner progressivement celle-ci. Ce chantier a produit ses premiers résultats au cours de l’année universitaire écoulée, par petites touches successives. Zoom sur les nouveautés.

Alignements

Dans un souci d’interopérabilité avec Data.bnf.fr, le FRBNF des notices BNF a été ajouté, à côté des OCN d’OCLC déjà présents : onto-bnf :FRBNF (propriété maintenue par la BnF elle-même). Les identifiants ark – présents dans une partie des notices du Sudoc, devraient suivre un peu plus tard.

Types de documents

Pour typer les documents décrits, on fait appel, de façon partiellement redondante, à trois vocabulaires :

–  Bibliographic ontology (plus familièrement « bibo »). C’est un vocabulaire simplifié d’usage assez large, au-delà de la communauté professionnelle des bibliothécaires

Dublin Core, encore plus générique

ISBD en RDF, maintenu par l’IFLA. Celui-là correspond plus strictement à nos standards de description bibliographique. Plus précis mais sans doute plus déroutant pour le profane…

Jusqu’ici, on utilisait de « bibo » que les classes « Book », « Periodical », « Series ». D’autres types de documents sont désormais identifiés: « Image », « Audio », « Audiovisual »…

– Idem pour Dublin Core : Image, Moving Image, Sound…

Côté ISBD, on utilise les deux propriétés isbd:P1001 « Content form » (type de contenu) et isbd:P1003 « Media type » (type de « médiation ») qui font appel à des listes de valeurs contrôlées.

Auparavant on ne distinguait guère que les documents imprimés et électroniques.  Désormais, le spectre des documents identifiés est plus large, même si pas encore tout à fait exhaustif : images fixes ou animées, documents musicaux ou sonores, cartographiques, microformes…

Exemple (RDF/XML):

<bibo:AudioVisualDocument rdf:about="http://www.sudoc.fr/114415641/id">
 <dc:title>Les Shadoks  [Images animées]  : l'intégrale des origines à nos jours  / René Borg, Robert Richez, Jacques Rouxel... [et al.], réal.  ; Jacques Rouxel, texte  ; Robert Cohen-Solal, comp.  ; Claude Piéplu, voix</dc:title>
 …
 <isbd:P1001>
 <skos:Concept rdf:about="http://iflastandards.info/ns/isbd/terms/contentform/T1002">
 <skos:prefLabel xml:lang="en">image</skos:prefLabel></skos:Concept>
 </isbd:P1001>
 <isbd:P1003>
 <skos:Concept rdf:about="http://iflastandards.info/ns/isbd/terms/mediatype/T1007"><skos:prefLabel xml:lang="en">video</skos:prefLabel></skos:Concept>
 </isbd:P1003>
 …
 </bibo:AudioVisualDocument>

Soit en Turtle :

<http://www.sudoc.fr/114415641/id> a bibo:AudioVisualDocument ;
 dc:title "Les Shadoks  [Images animées]  : l'intégrale des origines à nos jours  / René Borg, Robert Richez, Jacques Rouxel... [et al.], réal.  ; Jacques Rouxel, texte  ; Robert Cohen-Solal, comp.  ; Claude Piéplu, voix" ;
 isbd:P1001 <http://iflastandards.info/ns/isbd/terms/contentform/T1002> ;
 isbd:P1003 <http://iflastandards.info/ns/isbd/terms/mediatype/T1007> ;
 dc:type "Moving Image" ;
  
 <http://iflastandards.info/ns/isbd/terms/contentform/T1002> a skos:Concept ;
 skos:prefLabel "image"@en .
 <http://iflastandards.info/ns/isbd/terms/mediatype/T1007> a skos:Concept ;
 skos:prefLabel "video"@en .

Zones de liens bibliographiques : Unimarc 4XX

Ces liens se trouvent dans les zones 4XX de l’Unimarc, une bonne partie d’entre eux concernant les périodiques dont ils permettent de reconstituer l’historique (suite de/ devient, fusions/scissions, etc.).

Jusqu’ici, seule une petite partie d’entre eux était convertie, à l’aide des propriétés relationnelles de Dublin Core, beaucoup moins précis en la matière que l’Unimarc : hasFormat, relation, hasVersion.

A présent presque tous ces liens sont publiés. Il reste encore un peu de  Dublin Core (is part of / has part), de Bibo, à la marge (notamment pour les tirés à part) ; le reste avec RDA qui a fourni l’essentiel du vocabulaire ad hoc. (Voir la suite)

Certaines relations ont été par la même occasion précisées par une nouvelle propriété : par exemple « Est une reproduction de » : traduit par dcterms:isFormat l’est désormais par rdau:P60297 (is reproduction of)

Deux zones Unimarc sont encore exprimées de façon approximative :

– 451 : Autre édition sur un même support

– 452 : Autre édition sur un support différent

Elles n’existent dans aucun vocabulaire et devront être forgées.

La suite consistera à exposer  ces mêmes champs 4XX quand ils n’ont pas de lien, c’est-à-dire lorsqu’ils sont utilisés comme points d’accès. Comme, par exemple, les nombreuses 463$t ou 464$t (Comprend) contenant des titres de volumes ou d’œuvres contenues.

Mises à jour, présentes et à venir : bonnes pratiques

L’ancienne propriété a été pour l’instant  conservée, de façon redondante.

Par ailleurs, les propriétés RDA WorkManifested, ManifestationOfWork, et la classe Work : déjà utilisées dans quelques cas précis (titres uniformes, thèses) sont désormais obsolètes et sont  remplacées par leurs homologues rdam:P30135, rdac:C10001. De même que modeOfIssuance par  rdau:30003

A noter que le vocabulaire obsolète est pour l’instant maintenu. Ceci dans un souci d’assurer une interopérabilité entre deux versions du modèle de données, et d’éviter de « casser » des applications qui exploiteraient les données impactées. Ce principe ne pourra pas toujours être appliqué, mais à l’avenir, les modifications apportées à l’existant seront annoncées à l’avance avec une échéance, comme pour les modifications habituelles de format.

A ce propos, tous les retours sont les bienvenus !

Chantier ouvert au public, casque obligatoire

D’après A. Raanes. CC by 2.0. Source :Flickr

Rappelons enfin que tout ce qui précède est détaillé dans la documentation en ligne :

http://documentation.abes.fr/sudoc/manuels/administration/sudoc_rdf

M. Jeulin

Publicités

Un serveur SPARQL pour le Sudoc

Depuis juillet 2011, l’ensemble des données Sudoc est accessible en RDF. Si on connaît son identifiant, chacune des dix millions de notices du Sudoc peut être affichée en RDF/XML. Mais encore faut-il connaître cet identifiant… Ce dispositif est utile pour permettre à un programme de naviguer de notice en notice, y compris en rebondissant sur les données RDF d’IdRef par exemple, mais cela ne permet pas d’explorer systématiquement le Sudoc ni d’effectuer une recherche.

SPARQLer le Sudoc ?

Pour ce faire, il faudrait que toutes ces pages RDF soient agrégées en une seule base qui supporte la possibilité d’interroger des données RDF en tant que RDF. Cette possibilité s’appelle SPARQL : il s’agit d’un langage de requête standardisé conçu pour interroger les données RDF. Pour l’ABES, offrir un accès au Sudoc en SPARQL reste un objectif, mais ce n’est pas une priorité de premier niveau. Par contre, faire en sorte que d’autres acteurs puissent récupérer l’ensemble du Sudoc en RDF et ce, s’ils le souhaitent, dans une base RDF compatible avec SPARQL, c’est incontournable.

Moissonner le Sudoc

C’est pourquoi, dès juillet 2011, nous avons indiqué à des agrégateurs potentiels comment moissonner le Sudoc en RDF. De la même manière que les robots des moteurs de recherche peuvent crawler un site web dynamique à partir d’un fichier XML qui liste toutes les URLs du site, les robots des agrégateurs de données RDF ont été invités à crawler le Sudoc de la même manière, mais en demandant explicitement le format RDF/XML. Au passage, ce fichier XML qui liste les URLs est un fichier sitemap et le fait de pouvoir servir une page en HTML ou en RDF (ou autre chose encore) en fonction de la demande du client s’appelle la négociation de contenu.

S’il est en théorie séduisant et rassurant d’imaginer qu’on puisse crawler la version RDF d’une base de données selon la méthode de crawl standard qui fait le web d’aujourd’hui, en pratique, aujourd’hui, ce n’est pas la solution la plus efficace. En un an, Sindice, un des principaux agrégateurs de contenu RDF, n’a moissonné que 10% de la base.

Vous avez prévu quoi pour juillet … 2021 ?

Dumper le Sudoc

Il nous faut donc recourir aux bonnes vieilles méthodes. Nous allons donc générer des exports réguliers du Sudoc en RDF et nous les publierons, en libre accès. Contrairement à la solution du crawl, cette solution du dump implique nécessairement un décalage temporel entre les données du Sudoc et celles de son dump. Nous espérons limiter à un mois ce décalage inévitable.

Afin de roder ce nouveau dispositif, nous avons mis le dump à la disposition de Sindice. Dès que le conseil d’administration aura décidé de la licence juridique associée aux données des réseaux ABES, donc du Sudoc, ce dump sera ouvert à tous.

SPARQLer le Sudoc  avec Sindice !

En attendant, c’est avec enthousiasme que nous avons constaté l’intégration réussie des 300 000 000 de triplets RDF du Sudoc dans le moteur de recherche Sindice et dans son serveur SPARQL. Certes, Sindice est une initiative universitaire, qui ne peut prétendre garantir la continuité de service d’un serveur commercial (ceci dit, Sindice a désormais sa structure commerciale). Certes, les bases de données RDF de cette taille n’ont pas les performances des bases de données relationnelles et encore moins des moteurs de recherche comme Solr. Mais la souplesse et la puissance de SPARQL sont addictifs.

Disposer d’un accès au Sudoc en SPARQL, c’est très précieux pour développer des prototypes, se former au web sémantique sur des données familières, faire des requêtes impossibles avec les interfaces actuelles du Sudoc (Web, Z39.50), identifier avec précision les aspects sur lesquels la conversion actuelle  du MARC en RDF peut être améliorée…. Mais nous ne conseillons pas de faire dépendre un service en production du serveur SPARQL de Sindice. Ce n’est pas le but.

Afin de vous encourager à confesser votre propre addiction dans les commentaires, voici une première requête, très simple, qui liste tous les auteurs que Jacques Roubaud a pu traduire :

SELECT distinct  ?auteur ?auteurnom

FROM <http://www.sudoc.fr/>

WHERE {
  ?doc <http://www.loc.gov/loc.terms/relators/trl> <http://www.idref.fr/027110583/id>.
  ?doc dc:title ?titre.
  ?doc >http://www.loc.gov/loc.terms/relators/aut> ?auteur.
  ?auteur foaf:name ?auteurnom.
      }

Y. Nicolas

SudocAD : résumé du projet

Voici le résumé du rapport final (+ annexes) du projet SudocAD, mené par l’ABES et le LIRMM en 2010-2011 et co-financé par le TGE ADONIS :

Mené par l’ABES et l’équipe de recherche GraphIK du LIRMM, co-financé par le TGE ADONIS dans le cadre de son appel à projets 2009-2010, le projet SudocAD vise à interconnecter entre eux différents corpus de métadonnées agrégés par la plateforme de recherche ISIDORE, en les reliant au référentiel IdRef. Ce qui est en jeu, ce n’est pas seulement l’efficacité de la recherche dans Isidore, mais l’intégration des données SHS françaises au web de données, auquel IdRef est déjà connecté.

L’objectif opérationnel du projet était d’enrichir automatiquement des notices d’articles du portail Persée, en identifiant (quand elle existe) l’autorité IdRef correspondant à chacun des auteurs de l’article. 13 444 notices ont ainsi été traitées et livrées à ADONIS et à l’équipe Persée.

Pour identifier la notice d’autorité IdRef qui correspond à l’auteur Persée, SudocAD ne se contente pas d’utiliser les informations contenues dans la notice d’autorité mais exploite les connaissances enfouies dans les notices bibliographiques Sudoc liées. Toutes ces connaissances sont exprimées en RDF, selon le vocabulaire FRBROO. Il devient possible alors de raisonner à propos de ces connaissances, grâce aux outils sémantiques conçus et développés par GraphIk.

Les principales étapes du traitement opéré par SudocAD sont les suivantes : le nom et le prénom de l’auteur Persée sont utilisés pour sélectionner une liste parfois longue d’autorités IdRef candidates ; le raisonneur du LIRMM charge un ensemble de données RDF composées de la notice Persée, des autorités candidates et des notices bibliographiques Sudoc liées à ces autorités ; enfin, après avoir analysé ces données au moyen de règles logiques, le raisonneur répartit les autorités candidates en sept catégories de liage, de Strong à Impossible.

SudocAD ne donne donc pas directement un verdict sur la bonne autorité à lier. Mais, à partir du rapport d’analyse en XML et des sept catégories, il est facile de définir un algorithme qui détermine automatiquement l’autorité à lier. Mais il existe plusieurs manières de construire un tel algorithme. Ce rapport distingue les algorithmes de liage automatique qui paraissent les plus pertinents.

A côté du liage automatique, le rapport d’analyse généré par SudocAD peut également être utilisé dans une perspective d’aide à la décision. Il s’agirait d’utiliser ce rapport pour présenter les autorités candidates d’une manière qui facilite et fiabilise le travail manuel du catalogueur qui cherche à lier une notice bibliographique à une autorité.

Afin d’évaluer l’approche de SudocAD, un protocole a été établi pour comparer les résultats d’un traitement automatique aux décisions de liage prises par un catalogueur. Sur un échantillon de 150 notices Persée, elle montre que SudocAD atteint un très bon taux de bonnes décisions (liage ou non liage), autour de 80%, et surtout un taux d’erreur (création de liens erronés) inférieur à  2%.

Au-delà du projet SudocAD, l’ABES et l’équipe GraphIK ont la volonté d’éprouver la validité de cette approche sur d’autres corpus de métadonnées et d’améliorer encore son efficacité en corrigeant les défauts actuels et surtout en élargissant le spectre des informations prises en compte, notamment en exploitant de manière sémantique les co-auteurs et le vocabulaire Rameau.

theses.fr : l’API XML des personnes

logoThesesFrtheses.fr dispose d’une API dédiée aux personnes. Elle permet de récupérer les informations de la personne et la liste des thèses liées.

Repérez la page de la personne qui vous intéresse, et ajoutez le paramètre .rdf à l’URL de la page.

Exemples : http://www.theses.fr/034282297

et http://www.theses.fr/034282297.rdf

Vous obtenez un fichier RDF/XML.

Les données décrivant la personne utilisent le vocabulaire FOAF, les données décrivant les thèses utilisent BIBO et DC, les relations sont exprimées grâce aux MARC RELATORS PROPERTIES

theses.fr utilise les autorités du Sudoc : chaque personne possède un identifiant propre à theses.fr mais aussi son  identifiant pérenne issu du référentiel IdRef.

Attention : cet API ne permet pas de récupérer le nuage de mots de la personne disponible dans l’interface de theses.fr

Le dernier chapitre de la documentation de theses.fr est consacré aux API.

N’hésitez pas à utiliser le guichet d’assistance ABESstp pour nous faire part de vos remarques.

IMR

theses.fr : l’API XML des thèses

logoThesesFrMoteur de recherche des thèses de doctorat françaises, theses.fr propose des API XML d’accès aux données.

Le principe est d’utiliser l’interface puis d’ajouter un paramètre à l’URL pour obtenir les données brutes.

Pour récupérer les données d’une thèse de theses.fr en RDF, repérez la thèse convoitée, récupérez son URL, ajoutez .rdf

Exemples :

http://www.theses.fr/2009PA040090

et

http://www.theses.fr/2009PA040090.rdf

Dans le fichier RDF/XML, les vocabulaires suivants sont utilisés

  • pour qualifier les éléments de la thèse : Dublin Core, BIBO, ISBD (vocabulaire en cours de normalisation par l’IFLA)
  • pour décrire les personnes et les organismes : FOAF
  • pour décrire les relations : MARC RELATORS PROPERTIES

Le dernier chapitre de la documentation de theses.fr est consacré aux API.

Les API de theses.fr démarrent modestement ;  n’hésitez à nous faire part de vos besoins via le guichet d’assistance ABESstp

IMR

IdRef : des pages HTML et RDF plus riches

En Octobre 2010, l’ABES a inauguré IdRef, avec l’ambition de promouvoir l’utilisation des autorités Sudoc au-delà du Sudoc, et même au-delà des seules applications ABES comme Calames ou STAR.

Parmi les moyens techniques mis au service de cette stratégie, figurait l’exposition sur le Web des données d’autorité au moyen de pages HTML et RDF dédiées et d’une batterie d’URL pérennes associées. Depuis ce matin, ces pages sont considérablement enrichies.

IdRef, lié à Sudoc. Et inversement.

Jusqu’à maintenant, ces pages HTML et RDF reflétaient seulement le contenu des notices d’autorité UNIMARC. Désormais, elles contiennent les références bibliographiques de tous les documents signalés dans le Sudoc qui possèdent un lien vers ces notices d’autorité.

Ainsi, à la page suivante :

http://www.idref.fr/027182800

vous trouverez quelques informations sur Paul Veyne, tirées de sa notice d’autorité (version UNIMARC en XML), mais aussi la liste raisonnée de tous les documents qui lui sont liés. Cette liste est raisonnée au sens où ces documents sont regroupés en fonction du rôle qu’y joue Paul Veyne (auteur, directeur de thèse, préfacier, etc.)

Pour obtenir la version RDF/XML de ces données, il suffit d’ajouter  l’extension .rdf à l’URL précédente :

http://www.idref.fr/027182800.rdf

On voit à cette adresse que les données RDF d’IdRef pointent désormais vers les données RDF du Sudoc, publiées aujourd’hui. Et l’inverse est également vrai, comme le montre cet exemple :

http://www.sudoc.fr/001028235.rdf

Les données RDF d’IdRef pointent également vers le référentiel géographique Geonames ou le référentiel de langues Lexvo. Par la suite, nous avons bon espoir de pouvoir établir des liens vers d’autres référentiels, comme VIAF pour les personnes ou Rameau pour les concepts.

Merci

Merci aux quelques milliers de catalogueurs qui, depuis des années, ont établi ces millions de liens ! Et merci aussi à eux pour leur vigilance dans la saisie des données codées !

Le Web de données, reconnaissant.

Documentation technique : http://documentation.abes.fr/aideidref/developpeur/ch03.html

Contact : passez par l’interface d’assistance d’IdRef > Domaine Web Services