KaliDoS, un outil de vérification des règles de catalogage bibliographique – partie 1

  • Auteur/autrice de la publication :
  • Post category:Sudoc
  • Commentaires de la publication :2 commentaires
Print Friendly, PDF & Email

Ce billet est le premier d’une série de deux articles :
1. la partie 1 détaille la modélisation des règles de vérification
2. la partie 2 détaille l’architecture de l’application et ses interfaces

Chaque année, l’Université Claude Bernard Lyon 1 (UCBL) signale, en moyenne, 23 000 nouveaux titres dans le Sudoc, dont environ 5 000 qui nécessitent la création d’une notice bibliographique et sont, pour la plupart, des ‘unicas’ (documents possédés uniquement par le SCD de l’UCBL, par exemple des thèses, des mémoires, des fonds anciens numérisés).
La qualité de ces notices bibliographiques est primordiale pour garantir l’accès aux ressources. Pourtant, peu d’applications existent pour faciliter le contrôle qualité. De plus, elles sont non exhaustives voire obsolètes du fait de l’évolution des règles de catalogage.
En collaboration avec le SCD, un groupe de six étudiant.e.s du Master 2 « Technologies de l’information et du web » de l’UCBL a donc été chargé de développer une application, nommée KaliDoS (Qualité des Données du Sudoc), permettant de détecter, parmi un lot de notices, celles qui ne respectent pas un ensemble de règles.
La modélisation des règles à appliquer pour valider (ou non) les notices constituait un des enjeux majeurs de ce projet.

Modèles de règles

L’un des défis pour l’implémentation de KaliDoS réside dans la gestion des règles, que ce soit pour leur représentation ou leur utilisation. Différents types de règles ont été identifiés. Cette catégorisation permet de rendre générique la définition de ces règles, et donc d’en ajouter plus facilement.

Voici un aperçu de ces catégories :

Catégorie Définition
Comptage Vérifie que le nombre de sous-zones d’une zone soit égal au nombre de sous-zones d’une autre zone.
Exemple : plusieurs sous-zones 101$d nécessitent autant de sous-zones 330$a
Dépendance Compare la valeur de deux zones contenues dans un même PPN.
Exemple : les 4 premiers caractères de la sous-zone 029$b doivent être égaux à ceux de la sous-zone 328$d
Les opérateurs de comparaison sont l’égalité, l’inégalité et les relations inférieure et supérieure (strictes ou non).
IdRef Vérifie si une zone soumise à autorité est valide en interrogeant un référentiel externe.
Exemple : une notice contenant une sous-zone 606$2 avec la valeur « rameau » indique qu’il faut vérifier si le PPN enregistré en sous-zone 606$3 renvoie bien sur une autorité Rameau, via l’analyse de sa zone de contrôle 008
Matching Vérifie si la valeur d’une sous-zone correspond à une expression régulière.
Exemple : la sous-zone 339$d ne doit pas contenir « Année de mise en ligne »
Ordonnancement Vérifie qu’une liste de zones possédant le même tag soit triée par indicateur.
Exemple : s’il y a plusieurs zones 214, elles doivent être ordonnées selon l’indicateur « ind2 »
Précédence Vérifie, au sein d’une zone, qu’une sous-zone est bien précédée par une autre.
Exemple : une sous-zone 608$2rameau doit être précédée d’une 608$3
Structure Vérifie la présence d’une zone, d’une sous-zone ou d’indicateur.
Exemple : la zone 328 doit contenir un indicateur « ind2 » avec la valeur 0
Différents types de vérifications sont proposés, par exemple l’absence ou la présence d’une zone dans la notice, l’obligation de fournir une valeur à une zone, ou la présence d’un code pour une zone.
DépendanceConditionnelle Vérifie une règle de dépendance si la notice répond à une condition particulière.
Exemple : s’il y a une zone 455, alors la date en sous-zone 455$d doit correspondre à la date indiquée en zone 100 position 13-16
MatchingConditionnel Vérifie une règle de matching si la notice répond à une condition particulière.
Exemple : si la sous-zone 328$z ne mentionne pas « Reproduction de », alors il ne doit pas y avoir de zone 608 $3027253139Thèses et écrits académiques
StructureConditionnel Vérifie une règle de structure si la notice répond à une condition particulière.
Exemple : si la zone 008 commence par Oa, une zone 304 doit être présente

 

Jeu de règles

Chaque type de document est vérifié selon un jeu de règles qui lui est propre. Par défaut, cinq jeux de règles sont créés avec KaliDoS (« Thèses et mémoires en version de soutenance », « Thèses et mémoires reproduites », « Monographies électroniques », « Monographies imprimées et autres documents », « Jeu général ») et une interface graphique permet d’éditer les jeux de règles ainsi que le contenu de chaque règle. Si la majorité des règles sont communes à tous les établissements du réseau, il peut exister des règles locales, qui n’ont donc pas vocation à être utilisées ailleurs (par exemple, pour les thèses, le libellé normalisé de chaque université en sous-zone 328$e ou le point d’accès à l’établissement de soutenance en sous-zone 711$3).

Les règles sont stockées au format JSON (un fichier par jeu). Plusieurs exemples sont disponibles dans la documentation sur les règles.

Kalidos_partie_1_exemple_de_règles
Règle qui vérifie que la zone 230$a, stocke la taille d’une ressource électronique, ne contient pas l’unité « Mo »

 

Limitation du modèle

La gestion des règles est limitée sur trois points :

  • la distinction entre règle spécifique locale et règle collective n’est pas stricte : une application utilisée par plusieurs établissements se doit donc de marquer cette différence afin de ne partager que les règles communes à tout un réseau.
  • il n’y a pas de notion d’héritage :  un jeu de règles spécifique ne peut pas hériter des règles d’un jeu général. Ce choix se justifie par le fait que les règles évoluent peu fréquemment, mais une application nationale devrait permettre cet héritage afin de faciliter la réutilisation et le partage des règles entre établissements.
  •  il n’y a aucun opérateur pour combiner des règles : un type de règle qui doit vérifier à la fois une condition et la structure de la notice a donc été défini au lieu de combiner une règle conditionnelle et une structurelle. Il y aurait donc matière à repenser ce modèle de règles afin de permettre de combiner des règles existantes.

Conclusion

Une application dédiée au contrôle qualité des notices bibliographiques doit inclure un modèle de règles extensible.
Celui de KaliDoS répond bien aux besoins actuels, mais pourra nécessiter des adaptations s’il était utilisé par un réseau d’établissements. Dans un second billet, nous décrirons l’architecture et les interfaces de KaliDoS.

Logo Université Claude Bernard Lyon 1 Nuria Pastor Martinez, responsable du Pôle Données et Signalement (SCD de l’UCBL)

Fabien Duchateau, enseignant-chercheur (UCBL et laboratoire LIRIS)

 

Cet article a 2 commentaires

Laisser un commentaire

Tweetez
Partagez
Partagez
Aller au contenu principal