La première vérification réalisée à l’Abes consiste donc à vérifier que le fichier fourni par un éditeur remplit bien les obligations de conformité à la recommandation KBART. Voici les principaux points de vigilance :
- Nom de 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, description de la volumaison, valeurs fermées le cas échéant,…)
Les difficultés émergent lorsqu’on essaie de confronter la simplicité apparente de la recommandation avec la réalité des plates-formes de périodiques et/ou de livres en ligne. 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, 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 que cette complémentarité entre description bibliographique (MARC) et métadonnées favorisant l’accessibilité aux documents 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 en interne 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 fournitun 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 mais 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 par l’éditeur mais par l’équipe du Hub de métadonnées de l’Abes. Les découpages de revues – absents sur le site de l’éditeur- sont indiqués sur le fichier KBART.
Inconvénient de cette pratique : la matière première utilisée, les listes contractuelles et le Sudoc, ne permettent pas 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 tente de régler ce problème en agrégeant les informations trouvées dans les métadonnées d’articles.
Avec cette démarche, il s’agit donc d’inciter les éditeurs à s’interroger sur leurs pratiques afin de les faire évoluer, comme c’est le cas pour la Royal Society of Chemistry.
Dans un prochain billet, nous expliquerons en détail comment sont réalisées les différentes vérifications.