Un nouveau framework détecte les types de colonnes à partir des en-têtes : 39 types et 120 000 colonnes

Un groupe de chercheurs a publié sur arXiv un article sur un framework qui détermine le type sémantique d'une colonne de table à partir de son seul en-tête, et évalue au passage la qualité de la source de données. Le système associe les en-têtes à 39 types interprétables FinalFormat. Il a été testé sur environ 120 000 colonnes issues de sept jeux de données : UCI, Prague, Kaggle, VizNet/Sato, SOTAB, T2Dv2 et le volet Metadata-to-KG du concours SemTab 2024. Le résultat principal est ambivalent. Sur l'évaluation stricte officielle de SemTab, les chiffres sont modestes, mais les auteurs soutiennent que le modèle n'est pas seul en cause.

Le problème : comprendre une table sans regarder les cellules

Avant d'être chargées dans un graphe de connaissances, les données tabulaires doivent être annotées : quelle colonne contient des dates, laquelle des noms d'organisations, laquelle des identifiants. Cette tâche s'appelle Column Type Annotation (CTA) et relève du domaine plus large de la Semantic Table Interpretation. L'annotation s'appuie généralement sur le contenu des cellules. Mais les valeurs peuvent être fermées pour des raisons juridiques, bruitées, ou tout simplement inexploitables. L'en-tête reste alors presque la seule source de sens.

Les auteurs partent du principe que la qualité d'un graphe de connaissances ne dépend pas seulement de la vérification du graphe déjà construit. Elle dépend aussi des métadonnées qui entrent dans le processus d'intégration. Leur framework traite donc deux tâches à la fois : il annote les types et détecte les problèmes de qualité.

Comment fonctionne le framework

Les en-têtes sont associés aux 39 types FinalFormat grâce à des ressources lexicales sélectionnées à la main, c'est-à-dire des règles et des dictionnaires, et non un modèle opaque. Chaque décision est traçable : le champ SourceKeywords enregistre les tokens de l'en-tête qui ont conduit au choix du type. Pour les besoins d'audit et les secteurs réglementés, cette transparence compte autant que la précision.

Un deuxième niveau intervient ensuite. Chaque type attribué active un ensemble de contrôles issus de la taxonomie Data Quality Issues (DQI). Le système recherche :

• les valeurs manquantes ;
• les doublons ;
• les violations de domaine (domain violations) ;
• les types de données erronés ;
• les incohérences temporelles.

Les résultats sont agrégés dans la métrique HeadersIQ. Il s'agit d'un indicateur léger et non pondéré de la qualité, calculé à l'échelle de la source de données entière, et non d'une colonne isolée. En parallèle, une voie d'alignement avec les graphes de connaissances met le résultat en correspondance avec DBpedia et Schema.org.

Les chiffres et un benchmark discutable

Les auteurs revendiquent une large couverture pratique sur des métadonnées réelles et bruitées. Sur le volet Metadata-to-KG de SemTab 2024, l'évaluation officielle selon le principe GT-strict, c'est-à-dire une correspondance stricte avec la référence, s'est révélée modeste. Les auteurs ne le cachent pas.

Pour en comprendre les causes, ils ont mené un audit diagnostique en aveugle des divergences. D'après ses conclusions, de nombreux écarts s'expliquent par la granularité des annotations du benchmark, les alias et le choix de l'ontologie. Les prédictions n'apparaissent pas pour autant totalement invraisemblables pour une approche qui ne s'appuie que sur les en-têtes. Par exemple, « ville » face à « localité » compte formellement comme une erreur, alors que la différence de sens est minime.

Une réserve importante s'impose ici. Les auteurs écrivent explicitement que l'audit constitue un élément de diagnostic sur les schémas de divergence, et non un résultat révisé du benchmark. Ils ne cherchent pas à recalculer le score en leur faveur. Il reste que l'audit a été réalisé par les auteurs du système eux-mêmes et qu'il ne fait l'objet d'aucune confirmation indépendante.

Où cette approche peut s'appliquer

L'approche semble utile dans les scénarios où les valeurs des cellules sont indisponibles : catalogues de données ouvertes, registres d'entreprise, contrôle préalable des livraisons de données de partenaires. Un filtrage peu coûteux et explicable à partir des en-têtes permet d'écarter rapidement les sources qui présentent des problèmes évidents, avant de mobiliser des ressources pour un lourd pipeline d'intégration.

Une équipe qui construit un graphe de connaissances ou une vitrine de données devrait retenir deux points. Premièrement, la traçabilité via SourceKeywords facilite la vérification manuelle et le débogage des règles. Deuxièmement, les observations sur les erreurs de granularité et de choix d'ontologie sont utiles pour lire n'importe quel résultat SemTab : un faible score strict ne signifie pas toujours que les prédictions sont inutiles. Il vaut tout de même évaluer le système sur ses propres données, car les en-têtes des tables réelles sont souvent peu informatifs, et la méthode atteindra alors, par construction, un plafond.