CERCLES OPENEDITION : UN ALGORITHME POUR AUTOMATISER LES LIENS 7XX

Le chantier CERCLES OpenEdition

CERCLES_Sarah8Klocars_Clauser_via_OpenPhoto

Sarah Klocars Clauser (via OpenPhoto)

Lancé en 2015 par le SCD de l’Université François Rabelais de Tours – l’un des établissements ayant activement milité pour la création du dispositif –   le chantier CERCLES OpenEdition consiste principalement à l’enrichissement des notices bibliographiques du corpus OpenEdition (3959 notices au 01/07/2017), un travail réalisé par une équipe de catalogueurs du SCD, sous la responsabilité de Véronique Lacan, coordinatrice Sudoc.

Étapes à la loupe

Pour le traitement des notices d’e-books, il convient de  procéder dans un premier temps à la visualisation de 2 notices : celle de l’e-book à enrichir et celle de la manifestation imprimée, quand celle-ci existe. Pour cela, l’option « multifenêtrage » de WinIBW est activée.

Image1

Menu Fenêtre > Mosaïque verticale

En plus de la relecture complète, l’attention est ensuite portée sur les zones à vérifier et/ou enrichir particulièrement :

  • 035 : vérification du code source à partir du site Open Edition Books (OEB)
  • 010 : vérification de l’ISBN à partir du site OEB
  • 1XX : vérification des données codées, dont les dates
  • 200 : vérification du titre et des mentions de responsabilité (nombreux contributeurs reportés en 314)
  • 307 : ajout de la pagination de l’édition imprimée (si elle existe)
  • 310 : vérification des modalités d’accès et mise en cohérence de cette information dans les zones 856 ou 859
  • 452 : lien vers la notice de l’édition imprimée et lien réciproque
  • 6XX : complétude de l’indexation matière
  • 70X : lien à la notice d’autorité du contributeur (le plus souvent :  zones 701)

C’est principalement  l’enrichissement de cette zone 70X qui peut s’avérer complexe : soit la notice d’autorité n’existe pas encore, soit un choix doit être effectué entre plusieurs notices d’autorité, en cas d’homonymie par exemple :

  CERCLES_doublon_autorite

De plus, ce traitement peut s’avérer long et fastidieux, les notices d’e-books proposant de nombreux contributeurs, comme par exemple  :

CERCLES_contributeurs

Une vingtaine de contributeurs pour cette notice : autant de liens à créer

L’intérêt du traitement automatique

CERCLES_hula_hoop_by_Lars_Plougmann_via_Flickr_CC_BY_SA_2_0

Un algorithme au service du CERCLE…

Menée au SCD de l’université Picardie Jules Verne dans le cadre d’un autre chantier CERCLES comportant également de nombreux accès Auteurs à créer (voir le billet à ce sujet), une première expérimentation a démontré la capacité du programme de traitement automatique mis au point par les équipes de l’Abes.  A l’aide de cet algorithme conçu pour rechercher puis lier automatiquement les points d’accès 70X aux notices d’autorité correspondantes, un lien 7XX a été ajouté automatiquement à 749 notices sur 987, soit un taux d’erreur d’à peine 0,5 %. Une expérimentation globalement positive dont l’Abes a fait la promotion, notamment lors de l’atelier  « Aligner, le signalement augmenté » présenté par Yann Nicolas lors des Journées Abes 2017.

Saisissant cette opportunité, le SCD de Tours a sollicité les équipes de l’Abes pour bénéficier d’un traitement similaire sur le corpus OpenEdition, expérimentation lancée lors de la rencontre de travail avec un membre de l’équipe OpenEdition. Ainsi, en juin dernier, l’algorithme a  tourné sur le dernier fichier d’import de notices OpenEdition chargé dans le Sudoc. Les résultats  sont tout aussi satisfaisants : le programme est parvenu à lier automatiquement 733 sur 977 points d’accès, soit 75 % de réussite. Ce sont donc des notices avec des zones 7XX liées et validées qui ont été importées dans le Sudoc, facilitant considérablement le travail du SCD de Tours et bénéficiant à tous les établissements du réseau.

L’aide à la décision

Autre avantage de ce traitement :  pour les notices n’ayant pu bénéficié du traitement automatiquement, un rapport d’aide à la décision – résultat d’une analyse et d’un décryptage – est fourni au responsable du chantier CERCLES,  coupe de pouce bien utile pour organiser le travail de correction et témoignage que l’Abes respecte son engagement dans le dispositif CERCLES : « contribuer aux enrichissements, par un travail d’expertise préalable, par la fourniture d’outils automatisés et enfin par l’analyse et le conseil pour organiser le travail d’enrichissement« .

Ainsi, la responsable du chantier OpenEdition a disposé d’une grille de corrections à effectuer sur une partie des 244 points d’accès non traités,  pour lesquels des suggestions de liens ont été exprimées :

  • sur la base de rapprochement avec des titres similaires (73 cas)
  • sur la base de rapprochement avec des éditeurs similaires (33 cas)
  • sur la base de rapprochement avec des co-contributeurs similaires (2 cas)

Dans 10 cas seulement, aucune proposition n’a pu être opérée par le programme, les notices d’autorités potentiellement liables comportant des erreurs de catalogage, à corriger au préalable.

Image2

Extrait de l’analyse du traitement et sa grille de lecture

A partir de ce traitement automatisé, les catalogueurs du chantier CERCLES OpenEdition disposent donc d’un guide de corrections, de listes de PPN toutes prêtes sur lesquels ils peuvent intervenir. Ainsi, l’essentiel de leur travail peut se concentrer sur l’analyse et le choix de liens « problématiques », plutôt que sur la tâche purement technique et répétitive, de liages « indiscutables » aux autorités.

C’est en effet dans ce travail d’analyse et de choix complexes que s’exercent véritablement les compétences des catalogueurs, et non dans l’acte technique de simple liage qui peut être, sans remords, délaissé aux machines.

 

Publicités

Visualiser les données de BACON grâce à OpenRefine

Avec près de 80 diffuseurs et plus de 400 bouquets décrits, les données BACON constituent un vivier d’informations que l’on peut exploiter de multiples manières. Non seulement elles sont utiles pour améliorer le signalement de la documentation en ligne, mais elles peuvent de plus être manipulées dans tous les sens, grâce à l’ouverture technique sur laquelle on avait misé dès le début.
L’objet de ce billet est de montrer comment BACON peut répondre à une question fréquemment posée : où se trouve cette revue, chez qui est-elle gratuite, chez qui est-elle payante, et sur quels intervalles chronologiques ? Cette question a notamment été soulevée sur le blog Biblioweb. Ici, on va s’intéresser au mode de distribution des revues qui par ailleurs sont disponibles sur CAIRN.
Les données de BACON peuvent répondre à toutes ces questions grâce aux informations structurées en KBART v2. On connaît en effet l’état de collection d’une revue (date_first_issue_online – date_last_issue_online), on sait si elle est sur abonnement ou gratuite (access_type) et on sait combien d’années peuvent s’écouler entre la mise en ligne où l’accès est payant et l’ouverture à tous (embargo_info). Il nous suffit ensuite de partir d’une liste d’ISSN, imprimés ou électroniques, qui nous intéressent, utiliser les webservices BACON adéquats et de mouliner le tout.
Les résultats peuvent prendre l’apparence d’un simple tableau, mais dans ce cas précis il est sans doute plus pertinent de voir d’un coup d’œil l’ensemble des informations qui nous intéressent afin d’obtenir quelque chose qui ressemble à ça :


La démarche que je vous propose pour aboutir à ce résultat est une démarche « bidouille » : on trouve quelque chose qui se rapproche de ce que l’on souhaite faire, on regarde comment ça marche, on l’adapte avec les outils à sa disposition et/ou que l’on maîtrise. En l’occurrence, tout ce qui sera montré ici sera fait avec OpenRefine.

Le modèle à trouver et à comprendre

C’est sans doute la partie la plus simple. En parlant autour de moi de cette idée de visualisation, un collègue m’a tout de suite orienté vers ceci https://developers.google.com/chart/interactive/docs/gallery/timeline, une bibliothèque javascript issue de Google Charts qui permet justement de créer des frises chronologiques. L’idée générale est donc de créer une page html, lisible par n’importe quel navigateur, qui contiendra les données que l’on veut afficher ainsi que le code pour les mettre en forme. On ne s’occupera que de la partie « données ». Tout le reste sera géré par le code que l’on se contentera de recopier (mais qu’il faut comprendre un tout petit peu).
L’exemple ci-dessous correspond exactement à ce que l’on veut faire : on veut pouvoir grouper par type (ici Président, Vice Président et Secrétaire d’Etat mais pour nous Gratuit et payant) des états de collection correspondant à différents fournisseurs (ici Washington, Adams, Jefferson, pour nous Persée, Open Edition, CAIRN par exemple). La structure du script n’est pas difficile à comprendre :


<script type="text/javascript" src="https://www.gstatic.com/charts/loader.js"></script>
<div id="example3.1" style="height: 200px;"></div>
<script type="text/javascript">
google.charts.load("current", {packages:["timeline"]});
google.charts.setOnLoadCallback(drawChart);
function drawChart() {

var container = document.getElementById('example3.1');
var chart = new google.visualization.Timeline(container);
var dataTable = new google.visualization.DataTable();
dataTable.addColumn({ type: 'string', id: 'Position' });
dataTable.addColumn({ type: 'string', id: 'Name' });
dataTable.addColumn({ type: 'date', id: 'Start' });
dataTable.addColumn({ type: 'date', id: 'End' });
dataTable.addRows([
[ 'President', 'George Washington', new Date(1789, 3, 30), new Date(1797, 2, 4) ],
[ 'President', 'John Adams', new Date(1797, 2, 4), new Date(1801, 2, 4) ],
[ 'President', 'Thomas Jefferson', new Date(1801, 2, 4), new Date(1809, 2, 4) ],
[ 'Vice President', 'John Adams', new Date(1789, 3, 21), new Date(1797, 2, 4)],
[ 'Vice President', 'Thomas Jefferson', new Date(1797, 2, 4), new Date(1801, 2, 4)],
[ 'Vice President', 'Aaron Burr', new Date(1801, 2, 4), new Date(1805, 2, 4)],
[ 'Vice President', 'George Clinton', new Date(1805, 2, 4), new Date(1812, 3, 20)],
[ 'Secretary of State', 'John Jay', new Date(1789, 8, 25), new Date(1790, 2, 22)],
[ 'Secretary of State', 'Thomas Jefferson', new Date(1790, 2, 22), new Date(1793, 11, 31)],
[ 'Secretary of State', 'Edmund Randolph', new Date(1794, 0, 2), new Date(1795, 7, 20)],
[ 'Secretary of State', 'Timothy Pickering', new Date(1795, 7, 20), new Date(1800, 4, 12)],
[ 'Secretary of State', 'Charles Lee', new Date(1800, 4, 13), new Date(1800, 5, 5)],
[ 'Secretary of State', 'John Marshall', new Date(1800, 5, 13), new Date(1801, 2, 4)],
[ 'Secretary of State', 'Levi Lincoln', new Date(1801, 2, 5), new Date(1801, 4, 1)],
[ 'Secretary of State', 'James Madison', new Date(1801, 4, 2), new Date(1809, 2, 3)]
]);

chart.draw(dataTable);
}
</script>

Les éléments qui se rapportent aux données sont :

  • Un « id », que l’on trouve à deux endroits
    • var container = document.getElementById('example3.1');)
    • <div id="example3.1" style="height: 200px;">
    • Le premier permet de lier un identifiant au set de données que l’on va inscrire, le deuxième permet d’afficher notre frise. Dans notre cas on a besoin d’un id par revue.
  • La description de nos colonnes, par exemple ici dataTable.addColumn({ type: ‘string’, id: ‘Position’ }); Il faut donc donner le type d’information (‘string’, simples chaînes de caractères ou ‘date’) et le nom (id) de la colonne. Nous aurons besoin d’une colonne ‘prix’ (payant/gratuit), d’une colonne ‘diffuseur’ et de deux colonnes de date (début et fin). Ces informations seront toujours les mêmes, quelle que soit la revue.
  • Nos données à proprement parler se trouvent après dataTable.addRows, par exemple [ ‘President’, ‘George Washington’, new Date(1789, 3, 30), new Date(1797, 2, 4) ]. Dans notre cas ce sera par exemple [ ‘payant’, ‘CAIRN’, new Date(2008, 0, 0), new Date(2016, 11, 30) ]. Dans les objets dates Javascript, les mois et les jours sont indexés en partant de 0. Le premier janvier est donc ‘0,0’, le 31 décembre ‘11,30’).

La bibliothèque se charge de tout mettre dans l’ordre, il n’est donc pas nécessaire de grouper les « gratuits » ensemble ni de mettre les différents éléments dans l’ordre chronologique.

Si l’on reprend notre structure, on cherche donc à  avoir pour chaque revue  (les variables sont entre ##):


#titre_revue# – #editeur_scientifique#<script type="text/javascript" src="https://www.gstatic.com/charts/loader.js"></script>
<div id="#ISSN_revue1#'" style="height: 200px;"></div>
<script type="text/javascript">
google.charts.load("current", {packages:["timeline"]});
google.charts.setOnLoadCallback(drawChart);
function drawChart() {

var container = document.getElementById('#ISSN_revue1#');
var chart = new google.visualization.Timeline(container);
var dataTable = new google.visualization.DataTable();
dataTable.addColumn({ type: 'string', id: 'prix' });
dataTable.addColumn({ type: 'string', id: 'diffuseur' });
dataTable.addColumn({ type: 'date', id: 'debut' });
dataTable.addColumn({ type: 'date', id: 'fin' });
dataTable.addRows([
[ '#prix#', '#diffuseur#', new Date(#debut#, 0, 0), new Date(#fin#, 11, 30) ],
[ '#prix2#', '#diffuseur2#', new Date(#debut2#, 0, 0), new Date(#fin2#, 11, 30) ]
]);

chart.draw(dataTable);
}
</script>

La page finale que l’on cherche à générer sera un tableau html où chaque ligne comportera le code correspondant à une revue.

Préparer la requête BACON

On veut maintenant trouver une liste de toutes les revues distribuées par CAIRN. BACON est bien entendu le bon endroit où chercher. Un rapide tour sur l’interface https://bacon.abes.fr permet de récupérer ce qui nous intéresse. En allant sur « Exporter », en faisant une recherche par fournisseur puis en décochant « Bouquet courant », on obtient la liste complète des titres de revues disponibles sur CAIRN. Un clic sur la flèche rose permet de télécharger le fichier.
Dans le cas des revues à barrière mobile (les dernières années sont payantes, les années antérieures deviennent progressivement gratuites au bout de 2, 4, 5 ans voire plus) les master lists BACON proposent deux lignes par revue : une ligne décrivant la partie gratuite, une autre la partie sur abonnement. Le champ « embargo_info » permet de décrire la durée au bout de laquelle la revue devient gratuite.
Après avoir ouvert le fichier (en vérifiant bien que le séparateur compris est la tabulation et que l’encodage est l’UTF8) nous allons donc supprimer les doublons. Nous allons utiliser OpenRefine pour lancer cette opération. Le chargement du fichier s’effectue en cliquant sur « parcourir » et en sélectionnant le fichier CAIRN qui nous intéresse.  Après un clic sur « next », OpenRefine propose quelques options d’import. Il faut bien vérifier que l’encodage est UTF8, puis on peut cliquer sur « create project ». On arrive alors sur l’interface de travail d’OpenRefine, nous présentant une vue de nos données de manière tabulaire.
Nous allons utiliser la fonction « Blank down », qui permet de supprimer la valeur d’une cellule si la valeur de la cellule précédente est identique. Les fichiers KBART étant classés dans l’ordre alphabétique du titre, on sait que ce cas de figure se présentera pour le fichier CAIRN.
En cliquant sur la flèche à gauche de l’en-tête de colonne « publication_title », le menu déroulant propose de sélectionner « Edit cells » puis « Blank down ». Un clic et toutes les cellules en doublons disparaissent.
Pour supprimer les lignes correspondantes, il faut faire une facette permettant de faire remonter les cellules vides. Pour ce faire, il faut cliquer sur la même flèche à gauche de « publication_title », puis cliquer sur « Facet », puis sur « Customized facets » et enfin sur « Facet by blank ».

Dans le panneau de gauche apparaît alors les facets. « False » signifie que la cellule n’est pas vide, « True » qu’elle l’est bien. On va donc cliquer sur « True », ce qui a pour conséquence de n’afficher que les lignes qui ont un « publication_title » vide. Il faut enfin cliquer sur la flèche à gauche de « All », aller sur « Edit rows » et enfin sur « Remove all matching rows ».
Tout disparaît alors de votre vue tabulaire, mais pas de panique : en supprimant la facette (petite croix à gauche du titre de la facette) apparaissent toutes les lignes, sans aucun doublon.
On a besoin ensuite d’être sûr d’avoir une colonne avec un identifiant à chaque ligne. Ce n’est pas le cas ici puisque certaines revues n’ont pas d’ISSN papier, uniquement un ISSN électronique. On va donc créer une colonne qui donnera tout le temps l’ISSN papier et qui mettra un eISSN s’il n’y a pas d’autre identifiant.
La procédure est la suivante :

  • Cliquez sur la flèche à gauche de l’étiquette de colonne « print_identifier »
  • Sélectionnez « Edit Column »> « Add column based on this column… »
  • Attribuez un nom à la nouvelle colonne (par exemple « ISSN ») dans le champ « New column name »
  • Entrez dans le champ « Expression » le code suivant :
    • if(isBlank(value),cells['online_identifier'].value,value)
    • Ce code regarde si le champ « print_identifier » est vide ; si c’est le cas, il ajoute la valeur du champ « online_identifier » ; si ce n’est pas le cas, il conserve la valeur d’origine

Lancer et traiter la requête BACON

Nous disposons d’une liste d’ISSN sur laquelle nous allons pouvoir utiliser le webservice id2kbart. Ce webservice permet de connaître l’ensemble des packages où figure un périodique donné en fonction de son ISSN (version « papier » ou version électronique) et remonte l’ensemble des informations KBART correspondantes. Le webservice n’interroge que la version la plus à jour de chaque package.
L’étape suivante va consister à lancer le webservice sur toutes les lignes. Rien de plus simple :

  • Cliquez sur la flèche à gauche de l’étiquette de colonne « issn ».
  • Sélectionnez « Edit Column »> « Add column by fetching URL… »
  • Attribuez un nom à la nouvelle colonne (“BACONjson” par exemple) ») dans le champ « New column name »
  • Mettez le « Throttle delay » à 5 millisecondes
  • Entrez dans le champ « Expression » le code suivant :
    • "https://bacon.abes.fr/id2kbart/"+value+".json"
    • Ce code va prendre la valeur de la cellule id et va lui concaténer par un + les informations permettant de construire l’URL d’interrogation du webservice
  • Allez prendre un café. Ça va être LONG.

Le json récupéré ressemble à ceci : https://bacon.abes.fr/id2kbart/1293-6146.json
Tout cela est très verbeux car toutes les informations contenues dans la ligne KBART sont remontées, et cela autant de fois qu’il y a de bouquets dans lesquels se trouve le titre. La prochaine opération consiste donc à parcourir le json pour ne sélectionner que les informations qui nous intéressent.
La réponse est typiquement un objet JSON « bacon » dont le contenu est compris entre accolades et à l’intérieur duquel se trouve un tableau « query » qui contient lui-même, entre crochets carrés, un objet « id » (ISSN) et autant d’objet « provider » qu’il y a de bouquets où se trouve la revue dont l’ISSN est interrogé.
Le problème est que le code json est structuré de manière différente en fonction du nombre d’éléments correspondant à la requête.
Par exemple, s’il y a une seule ligne KBART correspondant à un identifiant dans un paquet donné, « kbart » est un objet json contenant un objet « element » décrit par des paires clés-valeurs (par exemple « publication_title »: « Mille huit cent quatre-vingt-quinze ») séparées entre elles par des virgules et encadrées par des accolades, comme le montre l’exemple ci-dessous :


"provider": {
"name": "CAIRN",
"package": "CAIRN_COUPERIN_REVUES-HUMANITES_2016-09-15",
"kbart": {
"element": {
"publication_title": "Mille huit cent quatre-vingt-quinze",
"print_identifier": "0769-0959",
"online_identifier": "1960-6176",
[…]
"access_type": "P"
}

En revanche, s’il y a deux lignes correspondant au même identifiant, comme c’est le cas dans les master lists, « kbart » devient un tableau contenant deux objets « elements », comme ci-dessous :

"provider": {
"name": "CAIRN",
"package": "CAIRN_GLOBAL_ALLJOURNALS_2016-11-15",
"kbart": [{
"element": {
"publication_title": "Mille huit cent quatre-vingt-quinze",
"print_identifier": "0769-0959",
"online_identifier": "1960-6176",
[…]
"access_type": "F"
}
}, {
"element": {
"publication_title": "Mille huit cent quatre-vingt-quinze",
"print_identifier": "0769-0959",
"online_identifier": "1960-6176",
[…]
"access_type": "P"
}
}]
}
}

On pourrait faire un seul script parcourant le json qui prendrait en compte tous les cas de figure (si « kbart » est un tableau tu fais ça, si « kbart » est un objet tu fais autre chose) mais on peut également faire les choses en plusieurs fois et combiner les résultats, comme le permet Openrefine.
On souhaite avoir par bouquet une réponse sous cette forme, et séparer chaque bloc par un point-virgule :
« Name » : « date_first_issue_online »-« date_last_issue_online »:« embargo_info»-« access_type»
Soit par exemple « OPENEDITION:2000-2012:P36M-P ; »
On va donc d’abord créer une colonne à partir de la colonne BACONjson (flèche descendante à gauche du nom puis « Edit column » et « Add column based on this column »), appeler cette colonne « parse1 » et appliquer le script suivant :

join(forEach(value.parseJson().bacon.query,v,v.provider.name+':'+v.provider.kbart.element.date_first_issue_online+ '-'+v.provider.kbart.element.date_last_issue_online+':'+v.provider.kbart.element.embargo_info+'-'+v.provider.kbart.element.access_type),";")

Décortiquons un peu :
« Value » est la variable comprenant l’ensemble de la cellule qui nous intéresse. On dit donc au script de parser cette variable écrite en json (value.parseJson()) en remontant le contenu de l’objet query inclus dans l’objet bacon. Comme query est un tableau contenant plusieurs objets on doit faire un « forEach » permettant de le parcourir. On crée ensuite une variable (ici appellée « v », mais on peut l’appeler comme on veut) qui prendra la valeur attachée à la clef « name » contenue dans l’objet « provider », concatène avec « : », ajoute la valeur attachée à la clef « date_first_issue_online » contenue dans l’objet « element » lui-même contenu dans l’objet « kbart » à son tour contenu dans l’objet provider. Le reste du code est à l’avenant. On obtient donc lors du premier passage de l’itération une réponse sous forme de tableau ressemblant à ça :

[OPENEDITION:2000-2012:P36M-P]

Un « forEach » renverra autant de tableaux que de réponses potentielles. Pour les manipuler, la forme tableau n’est pas adaptée. Il faut donc les transformer en chaîne de caractères. C’est là qu’intervient la première instruction « join », qui va concaténer les différents éléments du tableau au moyen d’un point-virgule, comme on le lui indique par le dernier argument du script.
La réponse visible dans Refine ressembera donc à ça :

Object does not have any field, including provider;CAIRN:2003-null:null-P;Object does not have any field, including element;CAIRN:2003-null:null-P;CAIRN:2003-null:null-P;CAIRN:2003-null:null-P;EBSCO:2007-2015:null-P

A chaque fois que le script tombe sur une expression qu’il ne peut parser il l’indique. La réponse commencera systématiquement par « Object does not have any field, including provider » dans la mesure où le script tombe d’abord sur un objet contenant la paire clef/valeur « id » avant de tomber sur l’objet valeur qui nous intéresse. On s’occupera plus tard de supprimer toutes les mentions inutiles.
On peut ensuite toujours s’appuyer sur la colonne « BACON_json » pour créer les colonnes « parse2 » et « parse3 » afin de pouvoir traiter les cas décrits ci-dessus où le json n’a pas exactement la même tête. On aura donc les scripts suivants :

join(forEach(value.parseJson().bacon.query,v,v.provider.name+':'+v.provider.kbart[0].element.date_first_issue_online+'-'+v.provider.kbart[0].element.date_last_issue_online+':'+v.provider.kbart[0].element.embargo_info+'-'+v.provider.kbart[0].element.access_type),";")

Ici « kbart » est un tableau dont on ne récupère que les valeurs contenues dans la première série d’objet (d’où le [0] puisqu’en json on commence à compter à partir de 0). On sait en effet que c’est dans cette première série que l’on aura les informations concernant l’accès gratuit à la revue, et c’est ça qui nous intéresse.

value.parseJson().bacon.query.provider.name+':'+value.parseJson().bacon.query.provider.kbart.element.date_first_issue_online+'-'+value.parseJson().bacon.query.provider.kbart.element.date_last_issue_online+':'+value.parseJson().bacon.query.provider.kbart.element.embargo_info+'-'+value.parseJson().bacon.query.provider.kbart.element.access_type

Ici il n’y a qu’une valeur possible (il s’agit de revue en OA qui ne sont présentes dans aucun bouquet), donc pas de tableau à parcourir.
L’étape suivante consiste à concaténer ligne à ligne l’ensemble des valeurs parse1, parse2 et parse3 afin d’opérer ensuite toute une série de traitement.
On va donc créer une colonne à partir de parse3, l’appeler parsefinal et appliquer le script suivant :

forNonBlank(value,v,v,cells['parse1'].value+','+cells['parse2'].value)

Le script regarde si la valeur de « parse3 » existe. Si c’est le cas, il l’associe à la variable v (le premier « v » de l’expression), puis l’affiche (le deuxième « v » de l’expression). Sinon, il affiche le quatrième argument, soit les valeurs concaténées par une virgule de « parse1 » et « parse2 ».
On a donc quelque chose comme ça :

Object does not have any field, including element;CAIRN:2008-null:P5Y-F,Object does not have any field, including provider;CAIRN:2008-null:null-P;CAIRN:2008-null:null-P

Avant de passer aux choses sérieuses, on va enfin nettoyer un petit peu les résultats afin notamment de pouvoir faciliter les calculs que nous allons faire sur les couvertures chronologiques.
Je passe rapidement sur la suppression des embargos relatifs aux revues OpenEdition. Ces embargos sont faux et n’ont pas encore été corrigés par l’éditeur à l’heure où j’écris ce texte. Il faut donc les supprimer pour éviter toute incohérence.
Nous allons tout d’abord remplacer les mentions « F » et « P » par « gratuit » et « payant ». Un simple script comme ci-dessous fait l’affaire. Pour l’appliquer, il faut aller sur la colonne « parsefinal » puis « Edit cells » et « transform » :

value.replace('-F','-gratuit')

Dans un fichier KBART, une revue dont le dernier fascicule est accessible n’a pas de date de fin explicitement indiqué. Nous allons remédier à cela grâce à l’expression suivante :

value.replace('-null','-2017')

Nous allons enfin transformer la mention d’embargo en un simple chiffre. En effet, les revues gratuites avec barrière mobile n’ont normalement pas de date de fin dans les fichiers KBART. Pour connaître la date effective du dernier fascicule librement accessible, il faut soustraire le nombre d’années d’embargo à la date de l’année en cours. Pour transformer une expression du type P2Y, P4Y ou P10Y nous allons utiliser des expressions régulières au sein du script ci-dessous :

value.replace(/(P)(\d+)(Y)/,'$2')

Les expressions régulières permettent de repérer un motif et d’opérer des traitements sur celui-ci. Dans openrefine, les expressions régulières sont encadrées de //. Ici l’expression est assez facile à comprendre : on recherche une chaîne qui contient d’abord un P, puis un ou plusieurs chiffres (\d est un raccourci qui désigne n’importe quel chiffre, + indique qu’il y en a au moins un), puis un Y. Le script remplace ensuite toute l’expression par le 2e élément (eh oui, en expressions régulières on compte à partir de 1…), à savoir le chiffre.
Toujours dans cette idée,  nous allons convertir les embargos exprimés en mois en embargos exprimés en années. Bien évidemment, on perd en précision ce que l’on gagne en facilité de manipulation. On utilise alors une expression du type :

value.replace('P24M', 'P2Y')

Normalement, dans notre expression, ‘null’ ne désigne maintenant que des titres qui n’ont pas d’embargo. Nous allons donc transformer cette chaîne en chiffre :

value.replace('null', '0')

Maintenant, notre expression ressemble à ça :

Object does not have any field, including element;CAIRN:2008-2017:5-gratuit,Object does not have any field, including provider;CAIRN:2008-2017:0-payant;CAIRN:2008-2017:0-payant

Préparer la visualisation

Nous avons tous les éléments pour la transformer assez facilement en :

[ 'payant', 'CAIRN', new Date(2008, 0, 0), new Date(2017, 11, 30) ], [ gratuit, 'CAIRN', new Date(2008, 0, 0), new Date(2012, 11, 30) ]

Jusqu’à présent, nous avons utilisé un langage de script propre à Openrefine qui s’appelle GREL. Ce langage est très facile d’usage et efficace pour les manipulations simples. Dans notre cas, nous avons besoin de quelque chose d’un peu plus poussé, notamment pour la manipulation des expressions régulières. Nous allons donc utiliser le langage jython, proche du python, qui est l’un des langages nativement intégré à Openrefine. Le script en question étant assez long, les commentaires se font au fur et à mesure. Ces commentaires sont intégrés au code et se manifestent par un # en tête de chaque ligne de commentaire.


import re
#on importe la bibliothèque re, qui comporte les fonctions dont on a besoin
p = re.compile(ur'([A-Z]+:[0-9]{4}-[0-9]{4}:[0-9]{1,2}-[a-z]{6,7})')
#ici, on crée une variable avec le motif de ce que l'on cherche codé comme une "expression régulière"
#[A-Z]+: signifie "trouve moi toutes les chaînes qui ont une ou plusieurs (+) lettres en majuscules([A-Z]) puis deux points (:) par exemple "CAIRN:"
# [0-9]{4}-[0-9]{4}: signifie "trouve moi toutes les chaînes ayant 4({4}) chiffres([0-9]), un tiret(-), et 4 chiffres puis deux points (:) par exemple "2008-2017:"
#[0-9]{1,2}- signifie "trouve moi toutes les chaînes sur 1 à 2 ({1,2}) chiffres ([0-9]) puis un tiret (-) par exemple 5-
#[a-z]{6,7} signifie "trouve moi une chaîne de 6 à 7 ({6,7}) lettres en minuscule [a-z] par exemple "payant" (l'autre valeur étant "gratuit").
#L'expression régulière permet donc de ne prendre en considération que les chaînes qui ressemblent à CAIRN:2008-2017:0-payant ou CAIRN:2008-2017:5-gratuit
reg=re.findall(p, value)
#Recherche toutes les chaînes qui correspondent à l'expression régulière dans "value" qui correspond à tout ce que contient la cellule traitée. Le résultat est une liste. Dans notre exemple ['CAIRN:2008-2017:5-gratuit','CAIRN:2008-2017:0-payant','CAIRN:2008-2017:0-payant']
liste_ec=sorted(list(set(reg)))
#On transforme une première fois la liste en set afin de supprimer les doublons (set(reg)), puis on en refait une liste (list(set(reg)) que l'on trie (sorted) et on attribue le tout à la variable liste_ec. Il est indispensable de disposer d'une liste afin de pouvoir isoler et traiter individuellement chaque élément de la liste, ce qui ne serait pas possible avec une chaîne de caractères simple. Le résultat est donc ['CAIRN:2008-2017:5-gratuit','CAIRN:2008-2017:0-payant']
for i in range(0, len(liste_ec)):
#on parcourt ensuite tous les éléments de la liste en partant du premier élément de la liste (0), jusqu'à son dernier qui a un numéro d'ordre qui correspond à la longueur de la liste (len(liste_ec)). On va récupérer un par un chaque élément qui nous intéresse (éditeur, état de collection, nombre d'années d'embargo, mode d'accès).
    regxnom = re.compile(ur'([A-Z]+):[0-9]{4}-[0-9]{4}:[0-9]{1,2}-[a-z]{6,7}')
#on reprend la même expression régulière que ci-dessus, mais avec une grosse différence : on entoure de parenthèses l'expression que l'on veut faire remonter, ici le nom de l'éditeur.
    nom=re.findall(regxnom,liste_ec[i])
#Recherche tous les résultats correspondant à l'expression régulière à l'endroit de la liste où l'on se trouve (liste_ec[i])
    stringnom=":".join(nom)
#Il ne peut y avoir qu'un seul éditeur par expression, on n'a donc normalement pas besoin de concaténer plusieurs valeurs (ce que fait le ":".join qui concatène en séparant par deux points). Mais le résultat d'un re.findall est une liste, et j'ai besoin d'une simple chaîne de caractère (string). C'est une manière d'y arriver. Il y a sans doute des manières plus élégantes.
    regxdatedeb = re.compile(ur'[A-Z]+:([0-9]{4})-[0-9]{4}:[0-9]{1,2}-[a-z]{6,7}')
#mêmes opérations pour la date de début
    datedeb=re.findall(regxdatedeb,liste_ec[i])
    stringdatedeb=":".join(datedeb)
    regxdatefin = re.compile(ur'[A-Z]+:[0-9]{4}-([0-9]{4}):[0-9]{1,2}-[a-z]{6,7}')
#mêmes opérations pour la date de fin
    datefin=re.findall(regxdatefin,liste_ec[i])
    stringdatefin=":".join(datefin)
    regxprix = re.compile(ur'[A-Z]+:[0-9]{4}-.{4}:[0-9]{1,2}-([a-z]{6,7})')
#mêmes opérations pour gratuit/payant
    prix=re.findall(regxprix,liste_ec[i])
    stringprix=":".join(prix)

    regxemb = re.compile(ur'[A-Z]+:[0-9]{4}-.{4}:([0-9]{1,2})-[a-z]{6,7}')
#mêmes opérations pour le nombre d'années d'embargo
    emb=re.findall(regxemb,liste_ec[i])
    stringemb=":".join(emb)
    liste_ec[i]='[\''+stringprix+'\',\''+stringnom+'\', new Date ('+stringdatedeb+',0,0), new Date ('+str(int(stringdatefin)-int(stringemb))+',11,30)]'
#on concatène tous les éléments afin que cela ressemble à l'expression que l'on veut écrire. On raffine en calculant la date de fin en fonction de l'embargo (qui est à 0 pour les titres payants) en transformant en nombre entier la date de fin ((int(stringdatedefin)) et le nombre d'années d'embargo, en soustrayant le deuxième au premier et en reconvertissant le tout en chaîne de caractère (str).
# On arrive à ça, sous la forme d'une liste : ['['payant','CAIRN', new Date (2008,0,0), new Date (2017,11,30)]','['gratuit','CAIRN', new Date (2008,0,0), new Date #(2012,11,30)]']
liste_script=','.join(liste_ec)
#Afin de pouvoir utiliser ces informations, on a besoin de les retransformer en chaîne de caractères. Dans le modèle de script pour obtenir une frise chronologique, on voit que chaque élément doit être séparé par une virgule, d'où le ','.join.
return liste_script
#La fonction return permet l'affichage, on obtient donc la chaîne ['payant','CAIRN', new Date (2008,0,0), new Date #(2016,11,30)],['gratuit','CAIRN', new Date (2008,0,0), new Date (2011,11,30)]

L’avant dernière étape consiste à habiller les expressions que l’on a générées avec le reste du script présenté en début de billet qui s’occupe de l’affichage de la frise chronologique en tant que tel. On va donc transformer notre cellule avec l’expression suivante (à nouveau en GREL) :

cells['publication_title'].value+' - '+cells['publisher_name'].value+ '<script type="text/javascript" src="https://www.gstatic.com/charts/loader.js"></script> <div id="' +cells['issn'].value+ '" style="height: 280px ; width:100%"></div> <script type="text/javascript"> google.charts.load("current", { "packages": ["timeline"] }); google.charts.setOnLoadCallback(drawChart); function drawChart() { var container = document.getElementById("' +cells['issn'].value+ '"); var chart = new google.visualization.Timeline(container); var dataTable = new google.visualization.DataTable(); dataTable.addColumn({ type: "string", id: "prix" }); dataTable.addColumn({ type: "string", id: "titre" }); dataTable.addColumn({ type: "date", id: "Start" }); dataTable.addColumn({ type: "date", id: "End" }); dataTable.addRows([' +value+ ']); chart.draw(dataTable); } </script>'

Il ne nous reste plus qu’à exporter le résultat. On peut au préalable faire un tri par exemple sur la colonne publisher_name afin de regrouper par éditeur (flèche à gauche de publisher_name puis clic sur Sort, puis encore clic sur Sort qui apparaît juste au-dessus des en-têtes de colonnes et clic sur « Reorder rows permanently).
Pour exporter le résultat en une page html, il convient de cliquer sur Export puis « Custom tabular exporter ». Nous n’allons sélectionner que la colonne qui nous intéresse (de-select all puis clic sur la colonne qui a la version finale du script), décocher la case « output colum headers », puis dans l’onglet « Download » sélectionner « html table » dans « other formats », et enfin cliquer sur « Download ».
Le résultat est visible dans n’importe quel navigateur. Le fichier html de résultats peut être téléchargé ici . Il faut l’enregistrer sur son poste avant de l’ouvrir avec un navigateur.

Quelques remarques conclusives

  • Ce code est générique, il peut être utilisé avec n’importe quelle liste d’ISSN en entrée (si on ne dispose pas des noms des éditeurs il suffit d’adapter la dernière étape du code)
  • Il n’est pas du tout optimisé : il faut 1-2 minutes pour que tout s’affiche, dans le cas de notre exemple. N’hésitez pas à apporter des améliorations !
  • La visualisation permet rapidement de se rendre compte de certaines incohérences dans les données : il y en a, elles sont corrigées au fur et à mesure.

B.Bober

Autorités vs référentiels : 3 questions aux experts de l’Abes

arabesques85Autorités, identifiants, entités : L’expansion des référentiels. Tel est le titre du dossier de la revue Arabesques n°85 consacré aux référentiels d’autorités.

Le volume et la diversité des métadonnées en circulation dans les systèmes d’information – de l’enseignement supérieur, de la recherche, de la culture-  exigent de repenser le rôle des référentiels d’autorité. Considérés comme données de confiance au service du développement de l’open data et du web sémantique, ils constituent un capital précieux, une garantie d’indépendance, tout en interrogeant en profondeur les pratiques catalographiques classiques.

Le comité de rédaction  a souhaité apporter un éclairage terminologique en posant 3 questions aux experts de l’Abes en ce domaine : François Mistral, responsable IdRef, Yann Nicolas, expert Métadonnées, Philippe Le Pape, mission Normalisation, Olivier Rousseaux, chef du service Métadonnées. Voici  leurs réponses in extenso.

1 – En tant que professionnel de la documentation, quelles distinctions faites-vous entre « référentiel » et « base d’autorités » ?

François Mistral : Afin d’éviter toute confusion par omission, ajoutons un troisième terme dans ce jeu des distinctions : celui de « nomenclature ». En catalogage, ce seront les données codées – comme par exemple les codes de pays, nomenclature internationale maintenue officiellement par l’ISO 3166 Maintenance Agency (ISO 3166/MA).

Par « référentiel », je retiens surtout l’idée de données de référence et de repère. Cela signifie qu’un référentiel est un jeu de données,  suffisamment vraies, justes, certaines pour être utilisées en confiance afin d’en produire ou d’en agréger d’autres. De fait, ces données de référence sont des points de repère à partir desquelles en situer d’autres avec économie.

Par  « données d’autorité », je retiens la double dimension de contrôle et de légitimité à assurer ce contrôle : ces données font autorité en ce qu’elles contrôlent des données bibliographiques, ce qui met en évidence la nécessaire qualité des données d’autorité, la pratique des sources constituant une de leur plus-value essentielle.

Cependant, outre les différences entre ces termes, je voudrais mettre en évidence l’horizon de leur convergence.  Que les bibliothécaires se persuadent qu’eux-mêmes et les données qu’ils produisent ont la légitimité de coloniser de nouveaux espaces de l’information au profit d’un intérêt tant professionnel que général.

Yann Nicolas :  Selon moi, quand on parle référentiel à l’Abes, on entend « des données qui permettent de décrire nos documents en minimisant le recours à du texte libre », de type listes fermées de « termes » (ex : code pays…) ou listes d’entités (ex :  entité de type Pays)

Décrire les entités de type « Document » étant notre cœur de métier, les entités qui gravitent autour sont considérées comme des entités secondaires « pour nous », comme des moyens et non des fins. Ce qui est tout relatif : un système de gestion des chercheurs français prendra nos documents pour entités secondaires, le Sudoc ou theses.fr devenant un référentiel « pour eux ». Bref, les référentiels des uns peuvent être les données centrales des autres. Ce qui ne veut pas dire que tout peut devenir référentiel.

La tendance actuelle est de transformer les référentiels « liste de termes ou de codes » en référentiels d’entités clairement identifiées : autrement dit, en langage Web sémantique, on passe de « littéraux » (chaînes de caractères simples, ou bien typées) à des « ressources », possédant une URI pour identifiant,  ces ressources pouvant elles-mêmes avoir des attributs, être décrites, succinctement ou longuement, ici ou ailleurs. Connecter nos données à ces référentiels, c’est indirectement enrichir nos données des attributs de ces entités secondaires, et, par transitivité, de proche en proche, à beaucoup d’autres informations.

Traditionnellement, une notice d’autorité remplit ces deux fonctions : identifier clairement une entité grâce à un identifiant précis ; mais également associer à cette entité un nom, un libellé, une étiquette linguistique, un « littéral », un nom propre à retenir comme son nom de référence. En effet, les autorités, de plus en plus ouvertes, vivent dans différents contextes (langues, cultures, types d’application, etc.) et le « bon » terme à afficher peut ne pas être toujours le même. De ce fait, la fonction « terme retenu » est de moins en moins centrale … même s’il faut bien de la chair attachée au squelette de l’entité : des attributs, et parmi eux, des libellés, multiples, qualifiés.

Bref, nos autorités traditionnelles se normalisent : rejoignent d’autres référentiels en tant que liste d’entités clairement identifiées, possédant des attributs et des relations (qualifiées) avec d’autres d’entités (de même type ou non, de même référentiel ou non). Cette normalisation est à la fois intellectuelle et technique. Le paradigme « web sémantique » constitue le vecteur principal de cette normalisation : tout devient Ressource, identifiée de manière univoque à l’échelle universelle grâce à sa (ou ses !) URIs, et ce sont les triplets RDF qui en parlent le mieux…

Philippe Le Pape : Les deux termes s’appliquent à des jeux de données « de référence », statut consacré soit par une labellisation (ex : norme ISO 3166 Codes des noms de pays ; norme ISO 80000-3 Système international de grandeurs, espace et temps ; standard RDA ; standard Unimarc) soit par l’usage (ex : données de theses.fr, de la Bibliographie nationale française). Il s’agit selon moi avant tout d’une distinction d’ordre technique, opérante dans le cadre d’un système de production et d’administration d’un ensemble de métadonnées complexes et organisées.

On nommera « référentiel », l’ensemble de données « outils » auquel on recourt pour garantir la qualité des métadonnées administrées, leur interopérabilité et leur conformité à un standard partagé. Dans cette catégorie entrent les modèles de données, les règles de catalogage, les formats, les nomenclatures (noms et codes de pays, de langue, unités de mesure, coordonnées géographiques..).

Dans un système bibliographique classique, fondé sur le modèle du fichier de notices descriptives dont certains  points d’accès sont contrôlés, les données d’autorité servent à normaliser, unifier et documenter certains de ces points d’accès.  Les données d’autorité ont donc vocation à faire référence pour des tiers, ce qui revient à dire que, dans le cadre d’un système de production de métadonnées, on utilise des référentiels pour produire des données d’autorité.

On remarque que les modèles conceptuels FRBR, FRAD et FRSAD – qui ont ouvert la voie à une conception nouvelle des systèmes bibliographiques, utilisent encore cette terminologie. En revanche, pour le modèle LRM, l’ancienne distinction entre données bibliographiques et  données d’autorité n’existe plus : le modèle ne reconnaît que des entités fonctionnelles en relation les unes avec les autres.

Olivier Rousseaux : « Référentiel : Ensemble auquel doivent appartenir les éléments, les solutions d’un problème posé » (dictionnaire Larousse).

Dans le contexte de l’Abes, les fichiers d’autorités, de même que les listes de données codées, servent à contrôler la cohérence des métadonnées bibliographiques. Ils participent à un ensemble plus vaste qui organise et contraint les métadonnées produites et qui comprend les modèles de données, les formats de saisie, les règles normatives de description, le tout s’inscrivant dans un cadre international – Principes internationaux de catalogage, modèle IFLA LRM (successeur des modèles conceptuels FRBR, FRAD et FRSAD) ou code de catalogage RDA. Des éléments de référence qui s’ajoutent comme autant de « briques », indispensables pour rendre des services tels que le partage de données entre applications, la fourniture à des tiers ou l’exposition.

J’appliquerais donc plutôt le terme de référentiel à cet ensemble qui fonctionne comme un tout avec des règles d’interdépendance et d’interopérabilité de ses constituants. Il permet tout à la fois la cohérence des métadonnées produites, la communication entres les applications documentaires de l’Abes mais également les services de fourniture et d’exposition associés à ces métadonnées.

2 – Ces dernières années, on assiste à la montée en puissance du rôle des référentiels. Comment cela impacte-t-il concrètement votre travail auprès des réseaux de l’Abes / les pratiques de catalogage des professionnels des réseaux ?

François Mistral : En tant que responsable IdRef depuis mon arrivée à l’Abes en 2014, mon activité consiste à encourager cette montée en puissance et à accompagner les professionnels des réseaux en ayant une démarche systémique reposant sur 3 piliers :

  • l’animation du réseau des catalogueurs et notamment des Correspondants autorité, interlocuteurs experts ;
  • l’amélioration de l’outillage professionnel visant à accroître la maîtrise de la production par les producteurs ;
  •  la dissémination multi-canaux et multi-formats des données d’autorité dans et « hors les murs ».

Il reste  encore beaucoup à faire pour informer sur le rôle des référentiels et convaincre des considérables bénéfices attendus et plus encore constatés de leur utilisation dans les Systèmes d’Information, documentaires, de recherche ou autres. Valoriser les données produites par nos réseaux depuis plus de vingt ans et de convaincre de leur capacité à rendre service, sont une source de motivation quotidienne. Nous avons pu étoffer l’offre de service d’IdRef – notamment en matière d’alignements –  afin de la rendre plus attractive. Cette offre est un levier pour démarcher des nouveaux partenaires et intégrer des nouveaux projets, dans lesquels l’un de nos apports spécifiquement «ABES» consiste à promouvoir l’idée centrale et précieuse de « mutualisation ».

Yann Nicolas : Je ne pense qu’à ça !  Ces dernières années, certains collègues et moi avons travaillé sur deux projets : Qualinca et le Hub de métadonnées.
Qualinca est un projet de recherche ANR qui vient de se terminer. L’idée était de produire des algorithmes qui auscultent et améliorent la qualité des liens entre notices bibliographiques et notices d’autorité. Entre Sudoc et IdRef, par exemple. Mais il faut penser plus générique, moins nombriliste : au-delà des données bibliographiques Sudoc et au-delà des autorités IdRef.

Côté hub de métadonnées, on récupère des données hétérogènes en provenance des éditeurs. Notre boulot est d’homogénéiser tout ça, mais aussi de l’enrichir, notamment grâce aux référentiels de toutes sortes : langues, auteurs, sujets, types de document… Il s’agit bien de remplacer (ou compléter) des mots par des identifiants : remplacer un nom d’auteur par un lien vers une URI (IdRef, ISNI, ORCID…) ou remplacer le code « J63 », non pas par le terme « Turnover » du thésaurus JEL (Journal of Economic Literature), mais par un lien vers l’URI de ce concept dans la version Web sémantique de ce thésaurus multilingue – voir : https://punktokomo.abes.fr/2016/05/16/mettre-nos-donnees-en-reseau-un-demonstrateur-4b-les-revues-doxford-up-et-la-classification-jel-economie/
Dans les deux cas, il s’agit de connecter l’information bibliographique à des référentiels, pour mieux la structurer et mieux la connecter, non seulement à l’échelle d’un catalogue, -même collectif ou national, mais à l’échelle du Web !

Philippe Le Pape : On assiste plutôt à une prise de conscience du rôle des référentiels. Dans des systèmes de production partagée de métadonnées tels que le Sudoc, le rôle de la normalisation – qui intègre l’emploi de référentiels – a toujours été crucial. Mais avec la mise en application de RDA, le recours à des vocabulaires contrôlés s’accroît encore – « type de contenu », « type de médiation », « type de support » en sont des exemples.

Olivier Rousseaux : L’Abes est confrontée à ces questions pour avoir posé comme principe, lors de la mise en place même du Sudoc, la réutilisation de référentiels existants : RAMEAU ou FMeSH pour les accès matière, fichiers d’autorités « personnes, collectivités, titres » de la BnF pour les accès auteur ou titre uniforme ; listes de codes ISO (langues, pays) ou Unimarc (codes fonctions pour les auteurs).

Les évolutions les plus importantes : l’accès – foisonnant dans le contexte du web de données – aux métadonnées d’autres référentiels bibliographiques, administratifs ou autres de type  VIAF , base SIRENE de l’INSEE ou Répertoire des structures de recherche au niveau national  (RNSR)  ainsi que les évolutions techniques qui permettent de se projeter dans leur exploitation (solutions d’alignement et/ou d’enrichissement des métadonnées).

A l’Abes, la réflexion porte donc sur les manières d’appréhender les métadonnées de référentiels tiers pour bénéficier de leurs apports potentiels. A minima, il s’agit d’une opportunité d’améliorer, dans nos bases de production, les méthodes de liage automatique  entre notices bibliographiques et autorités de manière à diminuer cette activité pour les catalogueurs. En ce qui concerne le travail de catalogage au quotidien, les perspectives sont également d’exploiter les référentiels afin de développer des outils d’aide à la décision (ex : projet de recherche Qualinca)

3 – Comment envisagez-vous/imaginez-vous le rôle des référentiels dans le paysage de l’IST / au-delà ?

François Mistral : Selon moi, les référentiels actuels laissent entrevoir certaines des évolutions à venir du métier de catalogueur. Les données produites par les bibliothécaires sont promises à un grand avenir, tout l’enjeu étant dans leur structuration. A ce titre, les référentiels vont continuer de croître en importance. En conséquence, le rôle et l’expertise des producteurs de données structurées et structurantes doivent être au centre de nos préoccupations prospectives.

Un point délicat réside dans le fait que « nous autres catalogueurs » devons prendre conscience que nous sommes, aux premières loges, à la fois spectateurs et acteurs de ce phénomène qui dépasse largement notre secteur professionnel. Avec ou malgré nous, les choses se jouent dans notre communauté.

A ce titre, on pourrait imaginer que les référentiels jouent, comme pour les données, un rôle structurant pour l’IST. Ils pourraient amener une reconfiguration plus rationnelle des missions de ses opérateurs, reconfiguration façonnée à leur image : toute entière de spécialisation et de coopération pour un service rendu de haut niveau.

Yann Nicolas  : Vu de l’Abes, en caressant du regard le paysage un peu cacophonique de l’IST en France, j’espère encore une politique publique des référentiels claire. Que chacun joue sa partition, c’est-à dire maintienne et mette à disposition les référentiels qui sont de son ressort. Qu’on évite les doublons où plusieurs font plus ou moins correctement la même chose. Mieux vaudrait qu’un seul le fasse, et de manière excellente ! Par exemple, que le Référentiel national des structures de recherche (RNSR) administré par le MENESR soit, de droit et de fait, reconnu comme LE service public national qui fournit identifiants et attributs de référence pour les laboratoires français. Ce qui n’empêche en rien des clients – comme STAR ou theses.fr – de gérer leurs propres attributs complémentaires, en sus des attributs RNSR, à des fins propres, bibliographiques ou pas. Si possible, gérons nos propres attributs de laboratoires, mais pas nos propres identifiants : accrochons nos attributs aux identifiants RNSR. Même chose pour les autorités de type Entreprise : le référentiel SIRENE de l’INSEE est désormais ouvert !
L’Abes doit être un bon client des référentiels des autres, en même temps qu’un bon fournisseur de référentiels pour les autres, dès lors que son positionnement, son organisation et son capital de données la rendent légitime. C’est le cas, sans conteste, du référentiel des thèses françaises ou celui des chercheurs français.

Philippe Le Pape : On va vers une importance grandissante des identifiants de confiance dans lesquels le « nom », la « forme d’autorité », les données elles-mêmes se trouvent de plus en plus ramassés : le passage des métadonnées bibliographiques de systèmes fermés au Web renforce la nécessité de les normaliser et de les étiqueter en fonction des standards du Web, selon des systèmes d’identification qui pour être efficaces doivent jouir d’une large reconnaissance.

Olivier Rousseaux : Je ne vois pas leur rôle évoluer radicalement dans l’immédiat car leur nature et leurs fonctions perdurent sans être remises en question. J’envisage plutôt une tendance à des rapprochements – entre alignements et fusion- de référentiels existants.
Cependant, pour chaque rapprochement envisagé, les mêmes questions devront être examinées, tout référentiel tiers visé fonctionnant dans un contexte défini et circonscrit qui lui est propre : à quels objectifs répond-il ? à quelles contraintes ? sur quel modèle de données est-il fondé ? quelles en sont les règles d’alimentation ? nos besoins sont-ils couverts par ce référentiel en termes de granularité des données, d’évolutivité et de traçabilité des évolutions apportées ? quels risques et quels avantages y aurait-il à fusionner avec ce référentiel tiers? quelle gouvernance en résultera (technique comme scientifique) et sera-t-elle adaptée à notre contexte ?

Un référentiel tiers est donc à aborder avec prudence afin de mesurer le degré de rapprochement optimal qu’on peut en espérer. De ce point de vue, le projet de « Fichier national des entités » amorcé en mars 2017 entre la BnF et l’Abes répond à ces questions en se positionnant résolument dans la recherche d’une solution de fusion des « traditionnels » fichiers d’autorités existants de part et d’autre au profit d’un fichier national unique géré en co-production.

 

 

CERCLES Bibliothèque Numérique Dalloz : retour d’expérience du SCD de l’université de Strasbourg

logo-unistra

« Genèse » du Chantier CERCLES de la Bibliothèque Numérique Dalloz

Le chantier “CERCLES BNDalloz” a été initié par le SCD de l’Université de Strasbourg en avril 2016 (sa fin est prévue pour le printemps 2017).

Il fait suite à l’immersion de Catherine Storne à l’Abes en janvier/février 2016.
Les objectifs de cette immersion étaient à la fois de rapprocher les équipes “docelec” et “catalogage” pour mieux signaler les ressources électroniques et de circonscrire la relation éditeurs et bibliothèque dans le traitement des métadonnées.

La documentation électronique seconde, voire prend le pas –pour certaines disciplines- sur la documentation papier. Il est dès lors nécessaire aux bibliothèques de s’inscrire comme acteur de leur signalement. Le SCD de l’université de Strasbourg a voulu participer, au travers de ce projet, à cette transition.

Organisation du Chantier CERCLES

L’équipe

L’équipe en charge de ce projet se compose de deux personnes :

  • Stéphanie Himber, responsable du chantier CERCLES BNDalloz.
  • Stéphane Rehlinger

Ne bénéficiant pas de temps dégagé pour se consacrer prioritairement à ce projet, nous y avons travaillé aussi régulièrement que possible lorsque nos activités propres à notre structure nous le permettaient.
Le départ de l’initiatrice du chantier, en septembre 2016, aurait pu nous fragiliser car nous ne disposions alors que des extractions initiales. L’appui des services Interfaces & Traitements et Métadonnées de l’Abes a donc été d’une grande aide : au niveau des outils, nous avons disposé d’extractions ad hoc et bénéficié de modifications en lot ; au niveau de l’accompagnement, nous avons pu nous appuyer sur des conseils et orientations de travail.
Nous avons également pu nous appuyer sur notre collègue Catherine Banos, correspondante “publications en série périodiques et collections” au sein du SCD de l’université de Strasbourg, et sur l’équipe du CR Alsace du Sudoc-PS de la BNUS – Christine Hecht et Estelle Cade – pour les demandes de numérotation ISSN des collections électroniques.

Périmètre du chantier

Le corpus initial – circonscrit en février 2016 – compte environ 1950 notices bibliographiques auxquelles s’ajoutent les versements réguliers de nouveaux titres, soit actuellement près de 2150 notices.
Il convient d’y ajouter les 40 notices de collection dont seulement 6 étaient présentes dans le Sudoc avant le début du chantier.

Lors du travail préparatoire sur ce corpus, les notices Oa ont été créées par copie des notices Aa existantes puis enrichies et corrigées par l’Abes.

Ci-dessous le tableau des modifications apportées par script vbs lors de la création par copie

Notice papier Notice d’e-book correspondante
001 Non repris
002 Non repris
003 Non repris
008 Par défaut : $aOax3
010 Non repris
020 Non repris
021 Non repris
033 Non repris
034 Non repris
035 Remplacé par défaut par : ##$aBNDalloz
073 Non repris
106 Non repris
135 Ajout par défaut : ##$av$br$cm$e#$gm$ia$ja
181 Ajout par défaut : ##$P01$ctxt
182 Ajout par défaut : ##$P01$cc
215 Non repris
225 Non repris
230 Ajout par défaut : ##$aDonnées textuelles
337 Ajout par défaut : ##$aNécessite un logiciel capable de lire un fichier au(x) format(s)Widelook ou Widelook Flash
410 Non repris
452 Ajout par défaut : ##$0″ + ancienPpn
801 Non repris
802 Non repris
830 Non repris

Ci-dessous les enrichissements

zone
010 ISBN électronique
100$a / 210$s dates du tableau-Dalloz ajoutées en 100$a et 210$d (par écrasement de celles éventuellement présentes)
205 Numéro d’édition tiré de la BNDalloz
676 $a340
859 URL fourni par l’OAI-Dalloz

Une fois ces deux opérations terminées, il restait environ 570 notices ou titres à traiter :
Cataloguer les documents électroniques pour lesquels la notice papier n’existe pas ;
Vérifier / corriger les notices Oa déjà présentes dans le Sudoc ;
Vérifier les notices susceptibles d’être des doublons. Dédoublonner quand nécessaire ;
Enrichissement des notices absentes de l’entrepôt OAI-Dalloz.

… et quelques 1830 notices Oa créées par l’Abes à enrichir ou à corriger.

Si la taille de ce corpus est relativement modeste, son signalement dans les catalogues est fortement attendu par les collègues. Aussi, plus que la complexité du traitement catalographique, c’est l’impératif de la réalisation du chantier pour fin 2016/janvier 2017 (comme nous nous l’étions fixé) qui nous a préoccupé.

Organisation du travail

  • Nous avons élaboré des outils de travail que nous avons partagés sur un dossier commun et nous disposions d’un espace collaboratif de travail proposé par l’Abes.

Outils de suivi
▹Tableau de suivi étape par étape ;
▹Tableau de suivi des demandes ISSN ;
▹Tableau des erreurs à corriger : notices doublons, 859 doublons, pb. d’eISBN, erreur de référencement Dalloz, … ;
▹Sauvegarde de plusieurs extractions servant de base de travail ;
▹Tableau détaillé des zones retenues pour le catalogage des documents électroniques.
▹Liste des nouveaux titres versés sur la base depuis mars 2016 : pISBN-eISBN-titre-édition-collection-date de mise en ligne-eppn-URL ;
▹Suivi pour info. au réseau / tableau de bord ;
▹Extractions réalisées par l’Abes.

Le manuel CERCLES de suivi du chantier est disponible ICI

  • Nous avons construit nos scripts vbs :
    Avec Nicole Krieger, correspondante SUDOC pour notre structure, nous avons déterminé les zones Unimarc que nous utiliserons pour créer et enrichir les notices Oa. Dans un document interne, nous avons commenté chaque zone et détaillé la forme du contenu de celle-ci.
    Nous avons formalisé le tout au travers d’un script que nous avons enrichi au fur et à mesure des consignes communiquées par l’Abes (ex. zones 339, 035).

Script vbs des notices bibliographiques :

"010 ##$AISBN$bebook"&vblf&_
"035 ##$aBNDalloz_"&vblf&_
"135 ##$av$br$cm$e#$in"&vblf&_
"181 ##$P01$ctxt"&vblf&_
"182 ##$P01$cc"&vblf&_
"230 ##$aDonnées textuelles"&vblf&_
"303 ##$aDescription d'après la consultation du 2017-MM-JJ"&vblf&_
"304 ##$aTitre provenant de la page de titre de la version électronique"&vblf&_
"305 ##$aVersion électronique de la XXe édition, Paris : Dalloz, 20"&vblf&_
"307 ##$aPagination de l'édition imprimée : XXX p."&vblf&_
"310 ##$aAccès réservé aux usagers des établissements qui en ont fait l'acquisition"&vblf&_
"320 ##$aBibliogr. p. XXX de l'édition imprimée"&vblf&_
"339 ##$aHTML$d20"&vblf&_
"339 ##$aSWF$d20"&vblf&_
"337 ##$aNécessite un logiciel capable de lire un fichier au(x) format(s) Widelook ou Widelook Flash"&vblf&_
"452 ##$0PPN imprimé"&vblf&_
"676 ##$a340$v22"&vblf&_
"830 ##$aChantier CERCLES 2016 ! Ne pas modifier cette notice sans avoir vérifié le périmètre d'intervention sous la responsabilité de : SCD de l'université de Strasbourg. Pour plus d'information, consultez le manuel CERCLES du GM."&vblf

  • Nous avons procédé de la même façon pour les notices Od
    Script vbs des notices de collection :
008 ‎$aOdx3
100 0#‎$a200X‎$d200X-
101 0#‎$afre
102 ##‎$aFR
104 ##‎$ak‎$by‎$cy‎$dba‎$e0‎$ffre
106 ##‎$ar
110 ##‎$ab‎$by‎$cb‎$em‎$f0‎$gy‎$hy‎$i0
135 ##‎$av‎$br‎$cm‎$dn‎$e#‎$gm‎$hn‎$in‎$ja‎$kn
181 ##‎$P01‎$ctxt
182 ##‎$P01‎$cc
200 1#‎$a@Codes Dalloz universitaires et professionnels
210 ##‎$aParis‎$cÉditions Dalloz‎$d[200?]-
230 ##‎$aDonnées textuelles
301 ##‎$aDemande de numérotation ISSN en cours
303 ##‎$aNotice réd. d'après la consultation du 2016-07-06
304 ##‎$aTitre provenant de l'écran-titre
310 ##‎$aL'accès à cette ressource est réservé aux usagers des établissements qui en ont fait l'acquisition.
326 ##‎$aCollection
337 ##‎$aNécessite un logiciel capable de lire un fichier au(x) format(s) Widelook ou Widelook Flash
452 ##$0LIEN VERS Ad
517 ##‎$a@Codes Dalloz

Travaillant à deux personnes sur ce corpus et étant dans des établissements distants, il était capital d’assurer un traitement uniforme des notices au risque de devoir s’entre-corriger.

Le traitement

Suite à l’étude des extractions initiales et à l’étude de la qualité des métadonnées, il a été décidé de créer les notices Oa par duplication des notices Aa pré-existantes et de les corriger / compléter le cas échéant à l’aide des données venues du site  Dalloz.
Aussi, contrairement à d’autres chantiers CERCLES, nous n’avons pas été concernés par la création d’autorités.

Plusieurs opérations ont fait l’objet de modifications en lot par l’Abes à partir d’extractions de sous-ensembles. C’est le cas de l’insertion des zones 035, 225/410, 304, 310, 339, 830, 859.
Le reste des vérifications et traitement des « cas spéciaux » s’est fait manuellement.

Concrètement, les opérations que nous avons eues à mener étaient :

  • des enrichissements ou corrections de notices bibliographiques et de collection : pour cela, nous avons travaillé à partir des extractions initiales et à partir des extractions de sous-ensembles, résultats de modifications en lot, faites tout au long du chantier.
  • des créations de notices bibliographiques et de collection : nous nous sommes appuyés – quand cela a été possible – sur la notice Aa existante que nous avons dupliquée et modifiée à l’aide de notre script.

Chaque création / vérification de notice s’est faite à partir de la « fiche de l’ouvrage » Dalloz + affichage / consultation du document électronique.

Quelques chiffres

Notices de collection Traitement en lot Traitement manuel
Création de notices de collection + demande de numérotation ISSN 39 notices
Doublons
notices dédoublonnées env. 50 notices
URL
Vérification de notices sans URL 34 ppn
Modifications
Insertion zone 010 $a 120 notices
Insertion zone “035BNDalloz” 2081 notices 13 notices
Insertion zones 181/182 5 notices
Insertion zones 225/410 1434 notices 716 notices
Insertion zone 230 1901 notices
Insertion zone 830 1901 notices
Insertion zone 859 “URL” 1726 notices
Zone 859 : substitution de l’URL pointant vers la notice de présentation par l’URL pointant vers le document 380 notices
suppression zone 073 273 notices
Suppression zone 839 30 notices
Créations
création manuelle de notices Oa env. 240 notices

Problèmes rencontrés

  • Numérotation ISSN des collections électroniques :
    L’intitulé de la collection électronique mentionné sur la fiche de présentation de la base Dalloz diffère de la mention de collection signalée sur la page de titre de la version électronique du document (nouvelle collection ou absence de série). Du coup, certaines demandes de numérotation ISSN ont été rejetées par le Centre ISSN France. Ces dernières ont été relancées en mars 2017 avec un dossier étoffé. Sont concernées les collections suivantes :
    ▹Cours
    ▹Dictionnaires Dalloz
    ▹Etudes, mélanges, travaux
    ▹Hors collection
    ▹Hors collection Dalloz / Hors collection Delmas / Hors collection Sirey
  • Communication de l’URL d’accès :
    Nous avons communiqué  les URL au fur et à mesure à l’Abes en complétant un fichier partagé (contenant déjà les PPN des notices créées).  l’Abes ne peut les récupérer directement et facilement via le service dédié Dalloz, un long nettoyage préalable des données récupérées est nécessaire via Open Refine avant de pouvoir les insérer en lot dans les notices.
    Nous avons utilisé le service mis à disposition par Dalloz :
    Test de service BND ☞ http://www.dalloz-bibliotheque.fr/services/bndtest.php?isbn
  • Accès aux anciennes éditions déjà retirées de la base Dalloz. Grâce au même service Dalloz, via l’ISBN (consigné dans les premières extractions) nous avons pu trouver les informations éditeur du document électronique.

dalws

  • Fiche de présentation BNDalloz incomplète ou erronée : absence de l’édition, ISBN doublon, … ;
  • Nombre réduit de connexions simultanées (5) nous obligeant à différer la consultation / le traitement des documents.

Questions soulevées

  • Lors du traitement catalographique :
    • Quel sort réserver à la zone 205 ?
      Pour la BNDalloz, la version électronique est la reproduction de la version imprimée ; c’est donc tout naturellement que Dalloz signale dans la « fiche de présentation » de l’ouvrage électronique, le numéro de l’édition imprimée. La BNDalloz donnant accès à plusieurs éditions du même titre, nous avons choisi de mentionner le numéro d’édition de la version imprimée conformément à ce que Dalloz fait dans sa base.
      Nous avons ajouté également la zone 305 :
      Ex. 305 ##‎$aVersion électronique de la 2e édition, Paris : Dalloz, 2016
    •  Que faire de la mention « matériel d’accompagnement » ?
      Il a été décidé de garder cette information en zone 327.Ex. 327 2#‎$aLa ressource ne donne pas accès aux données contenues sur le CD-ROM accompagnant l’édition imprimée
    • Notices de collection : comment dater le début d’une collection électronique, sachant que la BNDalloz est une base dont la mise à jour est régulière ?
      Il a été convenu que c’est l’année de mise en ligne du premier titre dans la collection qui compte. A défaut de la connaître, nous avons considéré la date comme incertaine :
      100 $a 20XX, 100 $d20XX-… et en 210 $d [20??]-
  • Cas de l’exemplarisation :

La question s’est posée de s’exemplariser de suite sous les notices créées par duplication en février/mars 2016 ou d’attendre la fin du chantier CERCLES.
Certaines bibliothèques, en option « Mises à jour propres » pour leur transferts réguliers, ont décidé de se localiser sous les notices fraîchement créées par copie, au risque de récupérer en local des notices incomplètes et perfectibles. D’autres, en option « toutes mises à jour » ont pu bénéficier de la mise à disposition rapide de nos créations, en ayant la garantie de recevoir au fil de l’eau nos enrichissements.
Ici, le SCD de l’université de Strasbourg a opté pour l’exemplarisation en fin de chantier. Les modalités n’ont pas encore été définies ; il a toutefois été décidé de créer une double localisation si la ressource électronique est présente sur deux bases (le plus souvent ScholarVox) car la BNDalloz est pressentie comme une base relativement stable.

  • La pertinence du corpus :
    Les sciences juridiques étant une discipline pour laquelle l’information est vite obsolète, nous nous sommes demandé s’il était utile et pertinent de signaler des éditions anciennes.
    La réponse n’étant pas clairement tranchée, nous avons traité tous les titres dont nous avions connaissance.
    A voir par la suite si nous procéderons à une sorte de « désherbage » du catalogue.A titre d’exemple, le titre suivant (ppn 191184985) : Comptabilité et gestion des associations : système comptable, gestion financière, analyse et contrôle de gestion / Francis Jaouen. – 11e éd. [à jour au 22 décembre 2008]. – Paris : Dalloz : Delmas, 2009. – (Encyclopédie Delmas).
    La notice ne comporte pas le champ 859 car le titre n’est plus accessible via la base et l’URL n’est pas connu.

Nos impressions sur cette expérience

Ce type de chantier nécessite un investissement important :

  • du temps pour organiser le travail, pour assurer un suivi régulier et être réactif aux diverses sollicitations ;
  • de la concentration pour jongler, au sein de la même journée, entre nos activités initiales et l’étude d’extractions / traitement de notices.

Nous n’avons été que deux personnes à nous lancer dans ce chantier. Après réflexion, cela n’a sans doute pas été un mal car le travail de coordination n’aurait été que plus important si nous avions été plus nombreux.

La création des notices Oa par copie des notices Aa nous a grandement soulagé. Du coup, nous avons eu relativement peu de notices à créer eu égard à la taille du corpus initial.
En outre, il me semble que pour mener à bien ce type de chantier, il est nécessaire de trouver l’appui d’une équipe capable de manipuler les métadonnées dans tous les sens, de faire des extractions du corpus et des modifications d’ensemble. Grâce aux équipes de l’Abes, nous avons pu avancer à pas de géant dans le traitement des notices.

Et la suite ?

Conformément au principe du dispositif CERCLES, où l’établissement reste le référent sur le corpus pour le réseau Sudoc, le SCD de l’université de Strasbourg maintiendra l’effort de mise à jour. En effet, Dalloz fait partie des éditeurs qui ne fournissent pas (encore ?) de métadonnées exploitables qu’il serait possible de traiter de façon automatique ou presque pour alimenter le SUDOC et d’autres outils.
En s’appuyant sur le nombre de titres versés sur la base en 2016, nous pouvons estimer le nombre de nouveaux titres annuels à environ 200.
Se pose en sus la gestion des titres quittant la base : introuvables via la BNDalloz mais consultables si l’URL est connue (… pour le moment).

La page dédiée au corpus Dalloz bibliothèque numérique est désormais disponible dans le manuel import ICI

28684221452_443261be71_n

« Kandinsky circles int’l july » (CC BY-NC-ND 2.0) by CaZaTo Ma

Stéphanie Himber
Responsable du chantier CERCLES BNDalloz

logo-unistra

Identifier les auteurs de HAL avec IdRef

logo-idref   C’est une histoire déjà ancienne à l’Abes que celle de l’identification automatique des Personnes impliquées dans des ressources documentaires. Du moins, est-ce un sujet qui, depuis plusieurs années, aiguillonne des études et aboutit progressivement à des réalisations intéressantes. En voici une illustration avec des corpus extraits de HAL.

Corpus SHS – 2011

Entre octobre 2010 et novembre 2011, dans le cadre du projet SudocAd, un premier prototype a été développé avec pour objectif l’enrichissement des métadonnées du moteur de recherche ISIDORE par l’ajout de lien aux autorités Sudoc (IdRef). Le prototype exploita un échantillon de 13 444 notices d’articles issues du portail Persée – domaine «Économie » – en identifiant, quand elle existait, l’autorité IdRef correspondant à chacun des auteurs. Une fois traitées, les notices furent livrées à ADONIS et à l’équipe Persée. Côté performance, le prototype SudocAD atteignait un très bon niveau : sur un échantillon vérifié de 150 notices Persée, 80% étaient estimées comme de « bonnes décisions » (liage ou non liage), et surtout, le taux d’erreur (création de liens erronés) était inférieur à 2%.

Corpus SHS – septembre 2015

Depuis, le projet Qualinca a repris le flambeau, avec une approche plus globale. En septembre 2015, une nouvelle expérimentation d’identification automatique est menée sur un corpus de HAL : 1 900 documents du domaine SHS sont puisés dans l’entrepôt OAI-PMH. Après traitement, 3 200 formes-auteurs sont extraites et passées à la moulinette du prototype. Lors du développement de l’outil, seuls 2 critères de matching -appelés également dans ce cadre « heuristiques »- sont utilisés (« co-auteur » et « unica »). Sur la base de ces critères,  1 100 entités – soit 34% des formes-auteurs – seront matchées, puis rattachées à une notice d’autorité dûment identifiée.

Corpus Astrophysique – avril 2016

Les disciplines ayant des pratiques de publication fort diverses, le choix s’est porté sur le traitement de 300 articles issus du domaine « Astrophysique » et leurs 1 242 formes-auteurs.  L’astrophysique étant un domaine dans lequel les publications sont hautement internationalisées, la proportion d’auteurs étrangers y est importante. De plus, l’interdisciplinarité y étant élevée, on trouvera parmi les auteurs des chercheurs physiciens, biologistes, ingénieurs, océanographes, chimistes, mathématiciens…

La qualité de l’identification finale dépendant largement de la qualité des données de départ, on notera que les données en entrée sont majoritairement de qualité basse, un aspect amplifié par l’absence de normalisation dans l’écriture des appellations. Quelle sera l’incidence de ces variantes orthographiques sur la couverture du corpus par IdRef ?

Le corpus comportait : 406 appellations d’auteur avec nom + prénom (soit 33%) et 836 appellations d’auteur avec nom + initiale du prénom (soit 66%). Les 1 242 formes-auteurs ont d’abord été ramenées à 1 156, suite à la suppression de 43 doublons évidents (avec accent vs. sans accent ; initiale du Prénom vs. Prénom développé).

Premier  constat : le prototype a appris à gérer de façon très satisfaisante ce paramètre de variabilité des graphies. Ainsi, 467 appellations (soit 37,6%) ont été identifiées avec les heuristiques «co-auteur», «titre» et «unica» – pour ce dernier critère, les appellations « Nom, P. » furent mises de côté. Second constat : sur les 775 appellations restantes, 57 -soit 4,6%- correspondaient à des auteurs dont des homonymes ont été correctement écartés par la machine. Afin de tester la couverture d’IdRef, une deuxième passe a ensuite été effectuée, sous forme d’une recherche manuelle rapide, qui a permis d’identifier 95 auteurs supplémentaires.
En valeur absolue,  autant d’auteurs avec « Nom, Prénom » qu’avec « Nom, P. » ont été identifiés. En valeur relative, le résultat est évidemment en faveur des auteurs avec « Nom, Prénom » – 66 % – contre 33% pour les auteurs avec « Nom, P. »  Dans ce cas également, le fait de disposer de notices d’autorité est très intéressant puisque dans la majorité des cas d’appellations avec « Nom, P. »,  le prénom développé a été retrouvé. Ces éléments permettent d’estimer le potentiel de clusterisation apportée par une notice d’autorité grâce aux variantes de formes.

Au final, ce sont 561 auteurs qui ont été identifiés, soit 45% d’identification des auteurs du corpus Astrophysique de HAL. A titre de comparaison, on remarquera que les requêtes lancées sur AuréHAL  sur les formes-auteurs présentes, en demandant pour chacune si elle correspondait à une forme présente dans un idHal, a donné un résultat de seulement 3,5 % des appellations du corpus « Astrophysique ».

Corpus idHal – janvier 2017

Le corpus idHal – identifiants uniques gérés dans HAL- en progression continue, constitue un nouvel enjeu majeur en termes d’alignement d’identifiants – notamment sur fond de projet Conditor. L’exploitation de ce service de HAL est importante à plusieurs égards : outre la sensibilisation auprès des chercheurs quant à la question de l’identification pérenne et unique, idHal permet de tirer parti du travail de validation d’attribution de publication réalisés par les chercheurs eux-mêmes.
Récemment,  un alignement vers IdRef des auteurs – publiant dans HAL et disposant d’un idHAL- a été tenté. En 5 étapes, cela a donné :
1)    identifier tous les auteurs HAL ayant un idHal
2)    récupérer les documents liés à ces idHal
3)    les convertir et les charger dans la base RDF de l’Abes
4)    lancer les heuristiques d’alignements
5)    extraire les premiers résultats : 11 000 auteurs à lier pour 6 400 alignés ( soit 58,2 %)

Ainsi, grâce aux puissants algorithmes d’alignement élaborés en interne, une bonne partie du chemin semble parcourue. Mais aller plus loin – beaucoup plus loin !-  est envisageable. En effet, il est désormais tout à fait possible de lancer les heuristiques sur l’intégralité de HAL.

De belles perspectives

Depuis 2010 à l’Abes, les avancées de la réflexion et des outils en matière de données d’autorité ont construit une approche intellectuellement et technologiquement performante, ce qui permet  de promouvoir, désormais preuves à l’appui, l’offre de service d’IdRef auprès des opérateurs de l’IST en France.
En effet, si le taux de couverture des auteurs de publications de recherche est proche de 50%, il est de l’ordre de 90% pour les auteurs français – ce qui confirme la portée réelle d’IdRef en termes de référentiel des auteurs de l’Enseignement Supérieur et de la Recherche.
Dans les mois à venir, le programme de travail ira en ce sens. La consolidation des process constitue l’axe prioritaire : il s’agira tout d’abord de les automatiser intégralement afin de moissonner de très gros volumes de données. La redistribution de ces alignements constitue le second axe.

Sur le même concept que le web service de récupération des alignements – idref2id,  le stock d’alignements disponibles va s’accroitre  pour mettre en vitrine tout ce que nous avons déjà en « arrière-boutique ». De belles perspectives donc.

François Mistral, responsable IdRef

STAR : les statistiques 2016

starDepuis l’ouverture en 2006 de l’application nationale STAR, développée suite à l’arrêté du 7 août 2006  relatif aux modalités de dépôt, de signalement, de reproduction, de diffusion et de conservation des thèses électroniques, outre la garantie d’un signalement et d’un archivage numérique fiable,  c’est bien également in fine la valorisation et la diffusion des thèses françaises que le dispositif mis en œuvre par l’Abes soutient. Un dispositif qui devrait se renforcer suite à la parution de l’arrêté du 25 mai 2016  rendant obligatoire le dépôt de la thèse dans sa version électronique  pour tous les établissements à partir du 1er septembre 2016. 

Outre un éclairage original sur la richesse de la production et sur la dynamique de diffusion des « documents Thèses », la publication des statistiques 2016 se veut un indicateur d’activité au service des établissements membres du réseau Star.

Volumétrie de la base de données STAR

Au 1er janvier 2017,  56 287 thèses déposées et archivées  sont recensées dans la base de données STAR/CINES. On constate que, depuis 3 ans, le volume de thèses traitées annuellement tend à se stabiliser autour de 10 000 thèses par an – 11 258 en 2016 pour être précis. Il est prévisible que cette moyenne augmente sensiblement en fonction du nouvel arrêté rendant le dépôt électronique des thèses obligatoire.

depot-annuel

Indicateurs d’activité dans STAR

Calculée en fonction du nombre de thèses traitées, l’activité dans l’application STAR se caractérise par un relatif lissage tout au long de l’année. Cependant, tout comme en 2015, on constate un léger pic d’activité lors du premier trimestre de l’année civile.

Le délai de traitement moyen d’une thèse dans STAR, donnée statistique présente dans l’application de pilotage Webstats, est calculé en fonction de l’écart entre  la date de soutenance et la date de validation finale.  Alors qu’en 2015 ce délai de traitement était en moyenne de 293 jours,  il est de 317  jours en 2016.

ration-mensuel

delai-traitement

Diffusion des thèses : l’accès libre largement privilégié

Illustration d’une belle dynamique d’ouverture et de libre accès,  le pourcentage de thèses déposées dans STAR diffusées sur Internet, stable depuis 2013, est évalué à 75%. On note qu’est privilégiée la diffusion des thèses sur plusieurs plateformes en simultané, cette diffusion s’appuyant sur la plateforme Thèses-en-Ligne (TEL) du CCSD, la plateforme des établissements de soutenance et la plateforme ABES.

Signe que les automatisations introduites entre les différents systèmes -et notamment entre STAR et TEL –  favorisent la politique de dépôt en open access ?  Quoiqu’il en soit, comme l’indiquent les statistiques publiées récemment par le CCSD, en 2016, on peut se réjouir que 72% des thèses déposées dans TEL – soit 5 731 thèses – l’aient été à partir de l’application STAR.  En 2014,  cela ne représentait que 39% des cas…

Type de diffusion

diffusion

plate-forme

Olivier CIAN, responsable fonctionnel de l’application STAR

 

Calames : les statistiques 2016

calamesTout en inaugurant la prise de relais entre le blog Calames, qui cesse ses publications en ce début d’année, et  Punktokomo, blog technique de l’ABES, ce billet vise prioritairement à fournir aux établissements membres du réseau Calames des éléments complémentaires aux statistiques générales accessibles via l’application Webstats.

Les statistiques présentées ici  fournissent des tendances et des indicateurs, mais ne prétendent pas donner d’information sur la qualité, la précision, la pertinence des encodages adoptés, ni sur la part de travail récurrent ou rétrospectif touchant des niveaux descriptifs pré-existants. En effet, le caractère hybride de l’instrument de recherche EAD – partagé entre la volonté de mettre en forme des documents et la tendance à l’usage de référentiels et autres données destinés aux traitements informatiques –  explique en partie cette difficulté à prendre tout le recul souhaitable sur ces ensembles de fichiers : bien souvent, seul un regard humain est à même de juger complètement de la qualité des encodages. Ces diagrammes sectoriels sont néanmoins des témoins sûrs de l’implication des établissements dans le signalement de leurs archives et manuscrits, de leur importance dans le paysage patrimonial de l’ESR en général et dans la vie du réseau Calames en particulier.

État de la base publique Calames au 31 décembre 2016

Répartition du 3/4 de million de composants publiés dans Calames par établissements

repartition-c-publies-fin-2016-par-rcr

Répartition des composants publiés dans Calames par origine (rétroconversions nationales originelles ou production/ attribution d’ID par l’outil)

originedonneescalames2016

Répartition  des composants publiés dans Calames par cercles de déploiement (1er cercle déployé en 2008, 7e et 8e cercles en 2014)

repartition-c-publies-fin-2016-par-cercles

Nouvelles données publiées dans Calames en 2016

La quantité de données nouvellement publiées est restée notablement élevée en 2016, bien que le surcroît soit moins spectaculaire qu’en 2015 et qu’il soit beaucoup plus également réparti entre une bonne dizaine de sources de signalement. origine-surcroit-c-publies-courant-2016

Neuf ans après son lancement, Calames dépasse ainsi les trois quarts de million de niveaux descriptifs publiés :

evolution-c-publies-2007-2016

Travaux de catalogage dans l’outil Calames Prod en 2016

La quantité de <c> nouvellement identifiés par l’outil Calames est très proche du niveau de l’année précédente : environ 126.000 composants ont été créés courant 2016 par le réseau Calames.

On constate que très peu d’établissements dérogent à la recommandation de cataloguer en-dehors de la base de production (env. 4000 <c> répondent à ce cas de figure après analyse), et le cas n’échoit que pour de bonnes raisons (emplois d’exports spécifiques ou volonté de faire des publications tests notamment).
Les 5 établissements ayant créé la plus grande quantité de niveaux descriptifs dans Calames depuis son origine sont ceux-là mêmes qui représentent à eux seuls plus de 60% des données actuellement publiées : Muséum National d’Histoire Naturelle (158067 <c> créés dans l’outil depuis 2008), BDIC (110203), Institut de France (86941), Bibliothèque Littéraire Jacques Doucet (65668) et Académie de Médecine (60648).

catalogage-dans-calames-2016

Depuis l’an dernier, nous disposons d’une statistique certes un peu complexe, mais complémentaire à la précédente, qui nous renseigne sur la fréquence du recours à l’outil de catalogage Calames Prod (au-delà du seul nombre de nouveaux <c> créés). Le graphique ci-dessous doit être ainsi lu : en 2016, la BLJD a effectué 839 interventions quotidiennes sur fichiers EAD unitaires (ou 839 « jours-fichiers »).

L’existence pour un même établissement d’un grand nombre de fichiers EAD favorise certes l’élévation des chiffres, quelques établissements ayant à gérer des dizaines d’instances distinctes. Le graphique témoigne aussi, en comparaison de 2015, d’un recours à la fois plus intense et fréquent à l’outil Calames Prod (plus de 1100 jours-fichiers supplémentaires pour une quantité de composants créés équivalente) ainsi que d’une part non négligeable de travaux rétrospectifs (retours sur des instances dont l’architecture au moins avait été créée les années précédentes).

temps-frequence-catalogage-calames-2016

Ventilation de 9  années de catalogage -aussi bien en production qu’en publication/indexation- dans Calames

production-c-2008-2016

Le décalage entre ces deux représentations des composants créés via l’outil Calames (<c> publiés / <c> créés) est une donnée structurelle depuis plusieurs années : de l’ordre de 100.000 composants présents mais n’ayant jamais connu de première publication. Les <c> créés en base de formation ont été « purgés » au maximum des rebuts, données de tests, et doublons de fait (ID différents mais données identiques à des niveaux descriptifs publiés en base de production). A noter aussi, une forte tendance à l’accélération des publications d’inventaires, puisque seuls 1/4 des <c> créés en 2016 n’ont pas connu de première indexation à la fin de leur année de naissance.

Statistiques de consultation 

Comme en 2015, la hausse continue de la quantité de données exposées, ainsi que plusieurs épisodes de popularité liés aux recherches ponctuelles de certains mots-clés sur les moteurs de recherche généralistes, se sont soldés par un nombre de visites sur le catalogue public en sensible accroissement.

Ainsi, la moyenne annuelle est de l’ordre de 16 000 visites/mois (soit 5.000 de plus qu’en 2013-2014) ; un phénomène corollaire est la recrudescence du « zapping » des internautes (durées moyennes de visites raccourcies), mais en restant bien loin des niveaux liés au sur-référencement que la nouvelle interface Calames avait connu dans ses premiers mois d’existence.

Jean-Marie Feurtet, responsable Calames