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.

theses.fr : comment fonctionne l’onglet « personnes » ?

(If libraries were like relational databases. Par Bpanulla. CC BY-NC-SA 2.0 . Source : Flickr)

Depuis le 17 janvier, www.theses.fr propose un nouveau périmètre de recherche : les personnes impliquées dans la recherche doctorale française (directeurs de thèse, auteurs de thèse et rapporteurs).

Pour mettre en place cette nouvelle fonctionnalité, l’ABES a dû résoudre plusieurs difficultés techniques.

En effet, theses.fr s’appuie sur SolR, un moteur de recherche proposant une API XML et JSON par HTTP. Les données exposées étant décrites par document (TEF), nous les avons naturellement indexées de cette manière. C’est-à-dire qu’une thèse (soutenue ou en préparation) correspond à un TEF et est indexée sous la forme d’un document SolR.
La description d’une thèse contient, entre autre, son auteur, son directeur de thèse, ses rapporteurs.

Comment arriver à rechercher sur ces personnes, alors que l’index est fait par document ?

Avec une base de données relationnelle, il aurait suffi de faire une jointure entre la table du « document » et la table des « personnes ».
Dans notre cas, il a fallu fabriquer une indexation dédiée à ce type de recherche.
Nous avons utilisé un SolR « personnes », destiné à indexer des personnes.
A chaque indexation d’un document thèse :
– un programme récupère les personnes liées (par leur numéro d’identifiant, le PPN de la notice d’autorité IdRef-Sudoc),
– les supprime éventuellement du SolR « personnes » (pour ne pas avoir de personnes sans thèse liée, dans le cas d’une mise à jour d’une thèse),
– puis pour chaque PPN trouvé, et pour chaque rôle possible, effectue une recherche dans le SolR « thèses » afin de trouver les thèses liées à ce PPN. Et ce sert de ces informations pour ajouter une fiche ainsi constituée au SolR « personnes ».
La recherche dans l’onglet « personnes » utilise le SolR « personnes » afin de trouver les fiches correspondant à tous les critères de recherche.
Pour chaque fiche de personne trouvée, le programme effectue une sous requête par rôle sur le SolR « thèses » afin de n’afficher que les thèses correspondant à au moins un des critères de recherche.

Exemple

La thèse http://www.theses.fr/2011TOU20094 a pour auteur  Mehdi Ghouirgate, pour directeur Philippe Sénac, pour rapporteurs Pascal Buresi et Jean-Pierre Van Staëvel, et comme mot-clé al-andalus. Cette thèse correspond au document 2011TOU20094 dans le SolR « thèses »
Au moment de son insertion dans theses.fr, un document est créé dans le SolR « thèses » et quatre documents sont créés dans le SolR  « personnes ».
Jean-Pierre Van Staëvel a été rapporteur d’une thèse,  a été directeur de quelques thèses soutenues, et est actuellement directeur d’une dizaine de thèses en préparation.
Dans le SolR « personnes », le document  SolR qui décrit Jean-Pierre Van Staëvel contient le fait qu’il est rapporteur de la thèse http://www.theses.fr/2011TOU20094 et qu’il est directeur notamment des thèses en préparation http://www.theses.fr/s33517 et http://www.theses.fr/s37444
Dans le SolR « thèses », le document 2011TOU20094 indique que cette thèse a pour mot clé al-andalus et  les documents s33517 et s37444 ont le mot maroc dans les mots du titre des thèses en préparation.
Ainsi si vous faites une recherche sur maroc al-andalus dans l’onglet « personnes » vous avez notamment comme résultat Jean-Pierre Van Staëvel qualifié par une thèse soutenue dont il est rapporteur (2011TOU20094) et deux thèses en préparation dont il est directeur (s33517 et s37444).
L’onglet « personnes » de theses.fr consolide donc l’information présente dans les deux SolR.

A. Charot

PCP : gérer vos états de collection

Au premier semestre 2012, une interface de visualisation des plans de conservation partagée (PCP) sera ouverte. En exploitant les états de collection des périodiques, elle donnera à voir dans un premier temps les lacunes et les redondances existant dans un périmètre modulable de bibliothèques (PCP, département, région, toute la France, etc.).
Cette interface s’adresse principalement aux gestionnaires de PCP existants mais doit permettre aussi le développement  de nouveaux PCP.
L’application permet la consultation et l’affichage de toutes les notices de périodiques du Sudoc.

  • Ergonomie :

L’accent doit être porté sur l’affichage des données pour permettre efficacement leur analyse et comparaison.

L’interface devrait s’articuler sur 3 écrans :
1-Onglet Recherche
2-Onglet Résultat (liste de notices bibliographiques)
3-Onglet Titre

Ce dernier onglet proposera une visualisation des états de collections disponibles et proposera une information sur les lacunes identifiées.

Connexion :
L’interface ne propose qu’un affichage des informations disponibles et ne permet aucune  possibilité d’intervention sur les données :
L’accès est libre sans condition d’authentification ou d’habilitation particulière.

  • Technique :

Coté serveur :

– Stockage : l’ensemble des notices du Sudoc et leur données d’exemplaires sont stockées dans une base de données Oracle dans un format d’export XML
– Recherche : un moteur de recherche Solr (http://lucene.apache.org/solr/) permet d’identifier des notices selon des critères définis

Coté « client » :

– votre navigateur (Firefox, Internet Explorer…) est capable d’interroger par des requêtes HTTP asynchrones (http://fr.wikipedia.org/wiki/Ajax_%28informatique%29 ) les deux sources de données citées ci-dessus :
* les réponses sont fournies au format JSON (http://www.json.org/) lors de l’interrogation de Solr
* du XML est renvoyé par un serveur Tomcat intermédiaire pour les données d’exemplaire des notices
– des librairies javascript sont ensuite exécutées dans le navigateur (jQuery http://jquery.com/ et ses éléments d’interface principalement) pour manipuler, calculer et présenter les résultats.

Le prototype devrait être présenté une nouvelle fois au groupe de discussion.

Exemplariser sans WinIBW

Au second semestre 2012, l’ABES proposera une interface Web dédiée à l’exemplarisation. Cette nouvelle application s’adressera aux professionnels des réseaux Sudoc et Sudoc-PS pour exemplariser un document, sans modifier le niveau bibliographique des notices.

  • Ergonomie :

La connaissance du format MARC ne sera pas un pré-requis nécessaire à la saisie des données.
L’interface devrait s’articuler sur 4 écrans :
1-Onglet Recherche
2-Onglet Résultat (liste de notices bibliographiques)
3-Onglet Titre
4-Onglet Edition (modification, création)

Toutes les fonctionnalités proposées dans l’outil professionnel actuel WinIBW et permettant la gestion ou l’intervention sur les données d’exemplaires seront préservées.
L’utilisateur sera guidé dans son travail par une aide et des contrôles intégrés aux formulaires de saisie.
Les données seront soumises aux mêmes tables de validation que dans WinIBW.
L’utilisateur pourra créer des modèles de notices d’exemplaires adaptés à ses besoins.
Une exemplarisation par douchette sera aussi proposée.

  • Connexion :

L’interface est à destination des professionnels.
L’accès sera donc réservé aux catalogueurs des réseaux Sudoc et Sudoc-PS, avec authentification (login WinIBW).

  • Technique :

Cette application Web dialogue directement avec le CBS, comme le fait WinIBW en utilisant les technologies XML, JavaScript, java.
L’interface repose donc sur CBS, le système central du Sudoc : les index de recherche, les tables de catalogage, de validation sont ceux définis dans le CBS.

Un prototype est en cours de réalisation. Il servira de base de discussion au sein d’un groupe de travail qui sera bientôt constitué.

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

theses.fr : les technologies utilisées

logoThesesFrtheses.fr a été développée en interne par l’ABES.

Il s’agit d’une application web Java, tournant sur le conteneur de servlet Tomcat, et dont les urls sont réécrites via Apache.
Nous avons choisi d’utiliser uniquement des JSP et Servlet, sans framework particulier ; voici les quelques librairies utilisées :  Saxon / JDOM / SolRJ / JSON …
La partie « visible » est constituée d’HTML (bien sûr!) et d’une feuille de style (créée par Oxynel), ainsi que de javascript (JQuery) pour les widgets présents : autocompleter, slider, checkers…
Mais theses.fr sait délivrer autre chose que de l’HTML, via ses Servlets. Les API XML de theses.fr vous permettent d’obtenir le contenu sous différents formats, tels que (pour l’instant !) :
– Flux Atom
– RDF
– XML

Les données sont stockées dans une base Oracle : les métadonnées des thèses ainsi que le plein texte sont stockées dans une table (une colonne contenant les métadonnées sous forme TEF étendu, une colonne contenant le plein texte extrait du fichier PDF), la clé de la table est soit le numéro national de thèse, soit le numéro de la thèse en préparation (qui sera fourni par la future application STEP). Ainsi, via l’url http://www.theses.fr/n° on accède aux métadonnées de cette table.
D’autres tables seront par la suite utilisées pour gérer l’authentification qui permettra par exemple de sauvegarder les recherches.

Le principal challenge a été de fournir un moteur de recherche rapide pour ces données. Challenge d’autant plus crucial que le volume de données à l’ouverture n’a rien à voir avec celui que theses.fr devra supporter dans quelques mois, une fois  chargées les métadonnées des thèses décrites dans le Sudoc et le texte intégral des thèses déposées dans TEL.
Nous avons choisi la plateforme de recherche opensource Apache SolR, basée sur Apache Lucene, qui fournit par défaut de nombreuses fonctionnalités :
– recherche plein texte
– highlighting (surlignage)
– facettes
– support de différent type de document (word, pdf…)
– recherche distribuée
– réplication d’index automatique

La plateforme de production qui permet d’avoir un service 24h/24 avec tolérance de pannes est composée de serveurs Red Hat Enterprise (linux) :
– deux boîtiers de répartition de charge
– deux serveurs frontaux (Apache + Tomcat)
– un serveur de fichiers (NAS)
– deux serveurs de recherche (Tomcat + Solr)
– deux serveurs de base de données (Oracle en SAN)

Cette plateforme sert pour toutes les nouvelles applications développées par l’ABES : IdRef, STAR, STEP, theses.fr, les API Sudoc…

Pour de plus amples renseignements, n’hésitez par à contacter l’équipe technique via ABESstp

A. Charot