IdRef : ORI-OAI, première application externe cliente

La plate-forme ORI-OAI, conçue pour gérer la production numérique institutionnelle d’établissements de l’Enseignement supérieur et de la recherche, propose une nouvelle version du module ORI-OAI-md-editor (version 1.8.3). L’une des nouvelles fonctionnalités de l’outil permet, tout en restant connecté à ORI-OAI, de rechercher, trouver ou créer dans IdRef les autorités Personnes, Collectivités, etc. nécessaires à la description catalographique des thèses.

Pour récupérer cette nouvelle version, il suffit de faire un checkout du module ORI-OAI-md-editor depuis la version 2.0 du projet ORI-OAI.

Principes et fonctionnements

Le principe est similaire à celui utilisé dans l’interfaçage de STAR à IdRef : si un n°PPN est requis dans un champ du formulaire de thèse, l’icône « Lier à l’autorité Sudoc »  est proposée. Ce lien ouvre l’application IdRef dans une iframe (fenêtre intégrée à la page de travail). Le cartouche de recherche est préparé pour que l’opérateur lance la recherche.

Si la recherche est fructueuse, il suffira de cliquer sur le bouton « Lier la notice » en bas de la notice. Alors l’iframe se ferme. Le formulaire de thèse revient en avant-plan et les données utiles sont maintenant présentes dans les champs à remplir.

Dans le cas où l’autorité recherchée n’existe pas encore dans le référentiel, il convient de la créer. Cela se fait avec beaucoup de facilité puisque les données présentes dans la fiche de thèse et intéressant l’autorité sont pré-remplies automatiquement : PPN, date de naissance, nom, prénom, etc. A l’inverse, si les données sont saisies durant la création de l’autorité, elles seront poussées dans les champs correspondants du formulaire TEF d’ORI-OAI lors du liage.

Comprendre le workflow 

ori01

ori-02

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

ori-03

ori-04

ori-05

ori-07

Qui est concerné ?

Cette fonctionnalité est déjà en production à Valenciennes. Tous les établissements qui référencent leurs thèses depuis ORI-OAI peuvent utiliser ce service, comme par exemple, l’Université de Lorraine, l’Université Lille 1 Sciences et Technologies, l’Université de Rennes 1, l’Université Paris 2 Panthéon-Assas…

Jacques Brassart, coordinateur fonctionnel du projet ORI-OAI,

Yohan Colmant, coordinateur technique du projet ORI-OAI

Publicités

IdRef dans VIAF et après … #1 Passer d’un identifiant à l’autre (VIAF, IdRef, LC, BnF, Wikipedia, …)

Ce post de fil.abes.fr annonce l’intégration du référentiel IdRef à VIAF et en présente les enjeux stratégiques. Punktokomo prend le relais pour détailler quelques implications pratiques. En voici la première.

Tout l’intérêt de VIAF repose dans son travail d’interconnexion entre des notices d’autorité d’origines différentes. En effet, les algorithmes de VIAF cherchent à identifier toutes les notices d’autorité qui « parlent’ de la même chose, qu’il s’agisse d’une personne, d’une collectivité ou d’une oeuvre. Ils génèrent alors des grappes (clusters) d’autorités. Ces grappes VIAF possèdent elles-même un identifiant unique, en bijection avec chacun des identifiants des autorités membres de la grappe.

Par exemple, l’historien Alain Boureau correspond à la grappe 52358786, qui regroupe l’identifiant IdRef, l’identifiant BnF, l’identifiant de la BN allemande, l’identifiant de la Bibliothèque du Congrès ou encore celui de la Bibliothèque Vaticane. VIAF publie les informations de cette grappe pour qu’elles puissent être lues par un humain (HTML) ou exploitées par un programme (RDF, JSON, MARCXML). Chacune de ces pages  intègre les liens vers les notices d’autorité d’origine, ce qui permet de facilement naviguer de VIAF vers IdRef et les autres bases : connaissant l’identifiant VIAF, un humain ou un programme pourra découvrir l’identifiant IdRef et, en déroulant la bobine de notre web service Biblio, la liste des documents Sudoc liés à cette autorité.

Mais le chemin inverse est tout aussi utile à parcourir : connaissant l’identifiant IdRef, découvrir la grappe VIAF. A terme, cette opération sera possible grâce à l’injection de l’identifiant VIAF à l’intérieur même de chaque autorité IdRef (chantier en cours). En attendant, ce parcours est possible au moyen de l’astuce suivante : connaissant l’identifiant IdRef (ex : PPN = 028270282), on peut accéder à cette page de VIAF http://viaf.org/viaf/sourceID/SUDOC|028270282 qui redirige automatiquement vers l’URL de la grappe : http://viaf.org/viaf/52358786/. Cette redirection peut être exploitée à la fois par un humain et par un programme.

Il est donc possible de faire le chemin aller et le le chemin retour entre VIAF et n’importe quelle autorité d’origine, telle celle d’IdRef. Mais, par transitivité, VIAF peut aussi servir à passer d’une autorité d’origine à une autre, d’une notice de la BN allemande à une notice de la BN espagnole ou d’IdRef à la BnF (et vice versa). Certes, les liens entre les autorités IdRef et les autorités BnF existent déjà, puisque beaucoup de notices IdRef sont créées à partir des notices BnF et en conservent le numéro source. Mais chacun de ces fichiers d’autorité ayant sa propre autonomie, il est probable que VIAF permette de découvrir de nouveaux liens IdRef/BnF, ce qui est une excellente chose pour tout le monde.

Enfin, VIAF contient parfois un lien vers DBpedia, version RDF de Wikipedia versée sur le web de données. Par exemple, en RDF, la grappe Paul Veyne pointe vers cette entrée de DBpedia, et donc de Wikipedia. Là, encore, par transivité, on peut aller de l’autorité IdRef à la page de Wikipedia.

Toutes ces interconnexions contribuent à densifier le maillage de l’information au sein du web de données, et donc à en multiplier les possibilités d’exploitation. Mais en-deçà de cet enjeu global et de long terme, VIAF peut ici et maintenant aider le catalogueur au quotidien.

Y. Nicolas

Sudoc, IdRef : de nouveaux Micro Web Services

De nouveaux Micro Web Services Sudoc et IdRef ont été développés :

  • merged : à partir d’un PPN de notice Sudoc ou IdRef fusionnée, trouver le PPN actif (notice valide)
  • multiwhere : localiser (RCR de localisation) un ou plusieurs document(s) à partir de leur identifiant Sudoc (PPN)

A noter : un service where a été précédemment développé pour permettre la localisation d’un seul document à partir de son identifiant (PPN). Il est dorénavant conseillé d’utiliser le multiwhere qui est plus riche que le where : non seulement il permet de traiter plusieurs notices à la fois, mais il contient également les coordonnées géographiques de chaque bibliothèque.

  • frbn2ppn, ocn2ppn, etc. : connaitre l’identifiant Sudoc à partir d’un identifiant externe (BnF, WorldCat, etc.)
  • iln2rcr : connaître la liste des RCR rattachés à un ILN

Pour  retrouver l’ensemble de la documentation technique :

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.

L’actu du web de données en patates

Depuis 2007, le Linking Open Data cloud diagram aide à visualiser les différents corpus de métadonnées en RDF qui constituent le web de données liées (linked data). Ce nuage  a commencé modestement :

Linking Open Data cloud diagram, by Richard Cyganiak and Anja Jentzsch. http://lod-cloud.net/ - mai 2007

Le nuage du LOD (linked open data) en 2007

De mises à jour en mises à jour, sous l’avalanche des nouveaux corpus publiés en RDF et la multiplication des liens entre eux, ce nuage est devenu illisible. Et c’est un bon signe.

Linking Open Data cloud diagram, by Richard Cyganiak and Anja Jentzsch. http://lod-cloud.net/ - septembre 2011

Le nuage du LOD en 2011

Quand on zoome sur cette dernière version du nuage, on reconnaît un visage familier (et ce n’est pas une illusion) :

Sudoc, IdRef, theses.fr et Calames dans le nuage du LOD

Sudoc, IdRef, theses.fr et Calames dans le nuage du LOD

Grâce à la publication en RDF des données produites par les réseaux ABES et à leur interconnexion interne (autour des autorités Sudoc d’IdRef) ou externe (vers Rameau, Dewey, et bientôt d’autres cibles comme VIAF), le Sudoc, IdRef, theses.fr et Calames sont désormais des citoyens de cette luxuriante communauté de données ouvertes. Ce n’est pas une fin en soi, mais c’était une exigence.

Désormais, plus besoin de dessiner des patates dans un diaporama prospectif, il suffira de faire une copie d’écran du nuage officiel :

Le nuage ABES comme rêverie en 2008

Le nuage ABES comme rêverie en 2008

 

Y. Nicolas

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

Micro Web Service Biblio : quels sont les documents rattachés à cette personne ?

Biblio est le premier micro Web Service IdRef proposé par l’ABES : il permet de lister les documents signalés dans le Sudoc et rattachés à la notice d’autorité d’une personne.

A partir de l’identifiant d’une notice d’autorité de personne physique du Sudoc (« PPN » pour les intimes), Biblio fournit la liste des documents liés, en précisant pour chacun d’entre eux son titre et son identifiant Sudoc (PPN).

Par exemple, l’URL suivante :

http://www.idref.fr/services/biblio/027182800

est une requête Biblio qui demande la liste des documents rattachés à Paul Veyne, identifié par 027182800.

La réponse, en XML par défaut, est la suivante :

<?xml version="1.0" encoding="UTF-8"?>
<sudoc>
  <query>
    <ppn>027182800</ppn>
  </query>
  <result>
    <name>Veyne, Paul (1930-....)</name>
    <countRoles>10</countRoles>
    <role>
      <unimarcCode>070</unimarcCode>
      <marc21Code>aut</marc21Code>
      <roleName>Auteur</roleName>
      <count>89</count>
      <doc>
        <ppn>138028052</ppn>
        <citation>[Recueil factice: Portraits antiques]  [vol.1] ,   [Texte imprimé] / [s.l.] : [s.n.] , 1904-1969</citation>
      </doc>
      <doc>
        <ppn>138507023</ppn>
        <citation>[Recueil factice : Paul Veyne : Varia]   [Texte imprimé] / [s.l.] : [s.n.] , 1957-1967</citation>
      </doc>
      (... autres docs ...)
    </role>
    <... autres rôles ...)
  </result>
</sudoc>

Cette liste de documents est une liste raisonnée, organisée par rôles. Dans l’exemple ci-dessus, on voit que Paul Veyne remplit une dizaine de fonctions : Auteur, Préfacier, Collaborateur, Éditeur scientifique, Sujet, etc. Les rôles sont mentionnés par leur libellé en français (Auteur), leur code de fonction UNIMARC (070) et leur code de fonction MARC21 (aut). Ils sont triés par code de fonction UNIMARC.

Côte technique, si vous préférez exploiter ces informations dans le contexte d’un script JavaScript, il est possible de demander une réponse dans le format JSON

  • soit en ajoutant l’URL de requête le suffixe .json
  • soit en appelant l’URL de base en précisant dans la requête HTTP préférer du JSON (Accept: text/json). Vous utiliserez alors le mécanisme de la négociation de contenu, que vous pouvez tester avec le plugin Firefox Modify Headers par exemple.

N’hésitez, pas en commentaires, à demander des explications complémentaires, proposer des enrichissements à ce service et nous informer de l’usage que vous envisagez d’en faire.

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

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