BACON et la labellisation des données : à quelle aune mesure-t-on la qualité d’un fichier KBART ?

rvb-sloganLa recommandation KBART  , portée par la NISO, a une immense qualité : elle est relativement simple à comprendre et à implémenter. Un fichier KBART doit répondre à des exigences très peu contraignantes de prime abord : des intitulés de colonnes normalisés et parlants (‘publication_title’, ‘first_author’, …), une sortie sous la forme d’un fichier .txt, format universel s’il en est, encodage en UTF-8,… Faire un fichier KBART à la main  n’est donc pas compliqué en soi. La première vérification faite  à l’ABES consiste donc à vérifier que le fichier fourni par un éditeur remplit bien toutes les obligations pour qu’il soit conforme à la recommandation KBART. Sans entrer dans les détails de la recommandation, soulignons ici que nous sommes particulièrement vigilants sur les points suivants :

•    Nom du fichier normalisé (Editeur_consortium/région_package_date.txt)
•    Encodage UTF-8
•    Fichier tabulé (.tsv, .csv, .ssv)
•    Présence des 25 colonnes obligatoires
•    Colonnes correctement nommées
•    Colonnes correctement remplies (respect de la norme ISO 8601 pour les dates, de la description de la volumaison, des valeurs fermées le cas échéant,…)

Les difficultés émergent lorsque l’on essaye de confronter la simplicité apparente de la recommandation avec la réalité, parfois tordue il est vrai, des plates-formes   de périodiques et ou de livres en ligne. KBART est simple, simpliste si on le compare au MARC. La version 2 de la recommandation améliore sa précision (prise en compte des livres électroniques, de l’open access, de l’histoire d’un périodique), sans doute au détriment de sa facilité d’implémentation qui heureusement reste élevée, mais elle n’est toujours pas en mesure de décrire les cas complexes  .
Ce n’est pas un problème en soi : KBART se focalise sur l’accès à des ressources qui peuvent – et doivent – être décrites dans des formats adaptés si on veut en présenter toute la richesse et la complexité. Pour autant, pour que cette complémentarité     entre description bibliographique (MARC) et métadonnées permettant l’accessibilité aux documents (KBART) puisse se faire, deux éléments sont impératifs au niveau du fichier KBART:

•    La description de l’accès à la ressource doit être pertinente : le champ title_url doit effectivement pointer vers la ressource, le champ title_id doit permettre de comprendre comment se structurent les liens d’accès aux volumes, fascicules, articles ou chapitres de la ressource.
•    Les identifiants utilisés (ISSN et ISBN) doivent être corrects et le découpage de l’histoire d’une revue en ses différents avatars doit se retrouver en ligne, comme d’ailleurs le stipule une autre recommandation, PIE-J.

L’analyse effectuée par l’ABES pour vérifier la qualité de ces données débouche sur un diagnostic transmis à l’éditeur qui sait alors précisément par où ses métadonnées pèchent. S’ensuit un dialogue avec ce dernier, voire un accompagnement de ses équipes techniques qui doit aboutir à une mise à jour de la plate-forme, processus qui peut être long et difficile (sous-traitance, restructuration de certains contenus,…). A l’issue de ce dialogue et au vu des améliorations apportées par l’éditeur, l’ABES peut alors attribuer le label de qualité de données, preuve de l’engagement de l’éditeur dans sa démarche globale d’amélioration de description et de signalement de son contenu. Si un éditeur ne peut que fournir un fichier KBART syntaxiquement correct mais ne respectant pas les recommandations plus fines de description, il verra ses fichiers intégrés dans BACON  tels quels et sans label, puisqu’il n’est pas question de modifier les fichiers se rapportant à des produits en abonnement courant.
La démarche est un peu différente pour les bouquets ISTEX. Dans ce cas, les fichiers KBART sont générés non pas par l’éditeur mais par l’équipe du Hub de métadonnées de l’ABES. Les découpages de revues qui ne sont pas présents sur le site de l’éditeur sont quand même indiqués sur le fichier KBART  . L’inconvénient de cette pratique est que la matière première utilisée, les listes contractuelles et le SUDOC, ne permettent pas par exemple de retrouver systématiquement toutes les informations de volumaison , notamment le numéro du premier volume/fascicule appartenant à une revue que l’éditeur n’a pas identifié comme telle (l’équipe du HUB est cependant en train de tenter de régler ce problème en agrégeant les informations trouvées dans les métadonnées d’articles). Son avantage en revanche est de pousser les éditeurs à s’interroger sur leurs pratiques  et à les faire éventuellement évoluer, comme est en train de le faire la Royal Society of Chemistry. En ce sens la démarche adoptée par le HUB rejoint celle de BACON.

Dans un prochain billet, nous expliquerons en détail comment nous réalisons les différentes vérifications.

Advertisements

Les personnes disposent d’un droit d’accès aux informations contenues dans cette zone de texte. Les informations que vous y inscrivez doivent être pertinentes au regard du contexte. Elles ne doivent pas comporter d’appréciation subjective, ni faire apparaître, directement ou indirectement les origines raciales, les opinions politiques, philosophiques ou religieuses, les appartenances syndicales ou les mœurs de la personne concernée.

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s