Résumé

  • Le Dataset Exchange Working Group du W3C a publié The Profiles Vocabulary comme First Public Working Draft le 20 août 2026. Le texte suit la Recommendation track, mais n’est ni une Recommendation ni une norme approuvée par le W3C.
  • La version HTML décrit une chaîne de propriétés : si une ressource est conforme à un profil et que ce profil en profile une spécification, un raisonneur peut déduire la conformité à cette spécification. Les communautés restent libres de définir le sens et le test de cette conformité.
  • Une correction de juin a remis les deux propriétés dans le bon ordre. Une autre issue demeure ouverte et qualifie toujours l’axiome d’at risk ; son texte intégré à la Working Draft reproduit encore l’ancien ordre.
  • Le fichier RDF Turtle daté du 20 août ne contenait aucune déclaration owl:propertyChainAxiom lors de la vérification. Le rapport d’implémentation cite des cas d’usage, mais son tableau élément par élément conserve des valeurs xx.
  • Une issue ouverte du groupe Data Shapes présente un contre-exemple de validation incomplète. Toute conformité héritée utilisée pour acheter, certifier ou automatiser une règle devrait porter un reçu indiquant les versions, l’autorité, les tests, le moteur et la nature exacte du résultat.

Décrire un profil, puis lui prêter une conséquence

Une spécification générale laisse souvent des choix. Une administration, un secteur ou une communauté scientifique les réduit, ajoute des contraintes, combine plusieurs modèles ou explique une manière commune de les appliquer. Le résultat est un profil. Il n’est pas seulement un document secondaire : il organise ce qu’une communauté attend de données, de logiciels et de leurs producteurs.

PROF propose un vocabulaire RDF pour rendre cet agencement lisible par les machines. prof:isProfileOf relie un profil à une spécification ou à un autre profil. Des Resource Descriptors peuvent ensuite pointer vers des contraintes, des validateurs, des schémas, des guides, des vocabulaires, des exemples ou des correspondances. Le rôle de chaque ressource est explicite et la liste peut être étendue par les communautés.

Cette architecture répond à un problème concret de découverte. Un client peut identifier un profil et les artefacts nécessaires à son emploi, au lieu de supposer qu’un PDF ou une page de présentation suffit. Elle devient toutefois plus ambitieuse lorsque le projet définit l’héritage de conformité.

La Working Draft HTML indique la chaîne suivante :

dct:conformsTo owl:propertyChainAxiom ( dct:conformsTo prof:isProfileOf )

Le chemin part de la ressource, rejoint le profil auquel elle se déclare conforme, puis atteint la spécification profilée. Le raisonneur peut créer une nouvelle relation dct:conformsTo vers cette spécification. Dans un catalogue ou un graphe de connaissances, la conclusion devient aussi facile à interroger qu’une relation directement déclarée.

La maturité institutionnelle ne doit pourtant pas disparaître. Le texte est la première Working Draft publique d’une trajectoire vers une éventuelle Recommendation. Le W3C décrit ce stade comme un travail en cours, publié pour examen et mémoire. Le groupe a consenti à la publication ; le W3C et ses membres n’ont pas endossé le contenu comme norme.

La logique calcule une relation, pas sa légitimité

Le projet place une phrase décisive près de l’axiome : chaque communauté peut déterminer ce que signifie la conformité à ses profils et aux objets qu’ils profilent, ainsi que la manière de la tester. La syntaxe commune n’uniformise donc pas le niveau de preuve.

Une inférence peut être déterministe alors que ses prémisses sont discutables. Avec deux arêtes et un axiome précis, un moteur produit ou non un triplet. Mais la première arête peut provenir d’un test exhaustif, d’un jeu partiel de contraintes, d’une auto-déclaration de l’éditeur ou d’une simple métadonnée. La certitude du calcul ne transforme pas la qualité de ce point de départ.

Le cas du null profile rend cette difficulté particulièrement nette. Ce type de profil vise à fournir une validation à une spécification qui n’en possède pas. La Working Draft reconnaît cependant qu’aucune méthode universelle et précise ne peut être donnée : les règles de la spécification source peuvent elles-mêmes manquer de précision. Convertir des règles en formes SHACL suppose alors de décider ce qui est couvert, omis ou interprété.

Le vocabulaire distingue aussi la relation directe prof:isProfileOf de prof:isTransitiveProfileOf, destinée à exposer les ancêtres éloignés et à éviter à chaque client de parcourir tout l’arbre. Si cette facilité est utilisée, les relations pertinentes devraient être complètes. Le projet ne prescrit néanmoins pas la manière dont chaque implémentation réalise les inférences correspondantes.

Au point de décision, cinq objets ne devraient jamais être confondus : un lien publié par l’auteur du profil, un triplet inféré, un test de validateur réussi, une certification et une détermination juridique. Le même mot « conformité » peut les accompagner, mais ils ne disposent ni de la même preuve ni de la même autorité.

Deux issues, deux questions différentes

L’Issue 58 portait sur le mécanisme. Ouverte en mars 2026, elle montrait que les deux propriétés étaient auparavant placées dans le mauvais ordre. Un commit a corrigé l’introduction, l’exemple, le tableau de définition et l’annexe : il faut suivre dct:conformsTo, puis prof:isProfileOf. L’issue a été close le 26 juin.

L’Issue 29 porte sur l’opportunité de conserver le mécanisme. Elle reste ouverte, avec le label at-risk, et indique que l’inclusion de l’axiome n’est pas tranchée. Des commentaires de mai la relient à la complétude des null profiles et à un contre-exemple publié dans le dépôt Data Shapes.

La page du 20 août montre ainsi deux états. Le corps du projet, l’exemple d’inférence, le tableau de la propriété et l’annexe utilisent la formule corrigée. L’encadré automatiquement repris de l’Issue 29 contient toujours la formule inversée. Un lecteur qui connaît l’historique peut choisir la bonne version ; une extraction partielle ou un agent qui ne voit que l’encadré peut conserver la mauvaise.

L’annexe « Features at risk » va plus loin : classes, propriétés, rôles et axiome figurent sur une liste en attente de preuves d’implémentation. Le statut n’annonce pas une suppression certaine. Il signifie qu’une proposition doit encore gagner sa place par des résultats publics et reproductibles.

La publication pour les humains et celle pour les machines divergent

L’annonce du W3C fournit un fichier prof.ttl daté et le présente comme l’encodage RDF Turtle du vocabulaire OWL. C’est l’objet qu’un logiciel peut télécharger, hacher et charger sans interpréter une prose HTML.

Dans le fichier du 20 août examiné, prof:isProfileOf est bien une propriété objet et une sous-propriété de prof:isTransitiveProfileOf. Les notes d’usage parlent d’héritage des contraintes et la propriété transitive décrit la fermeture de la hiérarchie. En revanche, aucune déclaration owl:propertyChainAxiom n’y apparaissait, alors que la page HTML en donne une dans l’introduction, l’exemple et le tableau de dct:conformsTo.

Cette absence n’autorise pas à deviner l’intention. L’axiome étant at risk, son retrait du cœur RDF peut être volontaire. La section sur la représentation RDF prévoit aussi des artefacts d’axiomes supplémentaires. Mais les surfaces publiques contrôlées ne disent pas clairement si la règle HTML est normative, optionnelle, expérimentale ou simplement non synchronisée.

La différence produit des comportements. Une équipe ajoute l’axiome à partir du HTML. Une autre considère le Turtle daté comme l’autorité exécutable et ne déduit rien. Une troisième charge la version vivante de l’espace de noms. Toutes parlent de PROF, mais leurs graphes ne répondent pas de la même façon.

La bonne gouvernance ne commande pas d’avance d’insérer ou de retirer l’axiome. Elle exige que la spécification humaine, l’ontologie distribuée, les issues et les tests expriment la même décision — ou qu’une divergence temporaire soit nommée comme telle.

Des implémentations nommées, une matrice de preuve encore vide

Le projet rend normatifs le modèle conceptuel, la spécification du vocabulaire et l’annexe Test Suite. Cette dernière décrit des modèles de validation SHACL et des instructions d’application. Le rapport d’implémentation distinct identifie cinq exemples, regroupés en trois ensembles présentés comme indépendants.

Cheka est décrit comme un outil Python qui remonte une hiérarchie de profils pour trouver les validateurs du profil et de ses ancêtres. Le rapport mentionne également l’ontologie LOCI, les bonnes pratiques de profilage ODRL, une hiérarchie OGC et un catalogue de profils à URI persistants. Il existe donc des usages pertinents.

Mais le tableau qui doit relier chaque élément du vocabulaire à ses implémentations contient encore xx dans les colonnes élément, libellé, implémenteur et emplacement. Le lien affiché vers le dépôt du test suite renvoyait 404 au moment du contrôle, bien qu’un répertoire testsuite existe sur la branche gh-pages. Cela ne prouve ni l’absence de code ni l’absence de tests. Cela montre que la page publique ne relie pas encore chaque fonction at risk à deux implémentations et à un résultat reproductible.

La charte active fixe l’objectif. La republication de PROF sur la Recommendation track est un livrable tentative. Pour dépasser Candidate Recommendation, une spécification normative devrait démontrer au moins deux implémentations indépendantes et interopérables de chaque fonction au moyen de tests ouverts. Des plans de test sont attendus dès les premiers projets, avec une coordination explicite avec le Data Shapes Working Group. Le mandat court jusqu’en avril 2028 : le dossier incomplet est une invitation au travail, pas un constat d’échec final.

Le contre-exemple de la complétude

L’Issue 882 du dépôt Data Shapes construit une situation où un graphe de formes vérifie correctement une partie des règles d’une ontologie OWL. Les données passent les formes présentes. Une autre contrainte de l’ontologie, absente du validateur, révèle toutefois après inférence qu’un même individu appartient à deux classes disjointes.

Le validateur est correct sur ce qu’il teste, mais incomplet au regard du parent. Si « conforme au profil » devient automatiquement « conforme à la spécification », le triplet final dépasse la portée des contrôles exécutés.

Cette issue est une contribution ouverte, pas une résolution du W3C. Elle ne condamne pas tout héritage de profils. Elle pose la question que la norme devra rendre vérifiable : quel seuil de complétude autorise le passage d’un résultat local à une conformité parentale ?

Le groupe pourrait exiger des validateurs complets, séparer profilage descriptif et conformité testée, restreindre l’axiome, rendre obligatoires régime d’inférence et couverture, ou publier l’héritage comme module choisi par la communauté. Le consommateur ne doit pas avoir à deviner laquelle de ces politiques s’applique.

Un reçu de conformité héritée

Avant d’utiliser un triplet hérité dans un achat, un audit, une certification ou une politique automatique, il faut préserver sa dérivation. Le reçu doit indiquer les versions et hachages exacts du profil et de la spécification parente, les liens directs prof:isProfileOf, l’artefact machine chargé et les axiomes effectivement actifs.

Il doit nommer l’autorité qui définit la conformité et son objectif, puis versionner les contraintes, validateurs, schémas, guides et correspondances. Moteur de raisonnement, validateur, régime d’inférence, configuration, suite de tests, couverture par fonction, contre-exemples, limites connues, implémentations indépendantes et issues at risk appartiennent au même dossier.

Enfin, le résultat doit être qualifié : relation déclarée, triplet inféré, validation réussie, certification ou décision juridique. Un catalogue exploratoire peut accepter une inférence. Une garantie contractuelle peut demander une autre autorité. Ce choix revient au responsable de la décision, non à un champ dont la provenance a disparu.

Dans le cadre de l’analyse de Heng Lu sur la relation principal-agent, le groupe de normalisation n’est qu’un agent parmi d’autres. La communauté du profil, le développeur de l’outil et le raisonneur automatisé exercent eux aussi une délégation technique. Le principal ne peut la contrôler s’il ignore qui a défini la règle, quel fichier a été exécuté et qui a promu le résultat au rang de preuve.

Ce que les éléments ne démontrent pas

La FPWD n’est pas une Recommendation et rien ne permet de prédire le sort final de l’axiome. Son absence du Turtle ne prouve ni erreur ni intention ; elle établit seulement une différence observable entre les surfaces HTML et RDF au moment du contrôle.

Le rapport cite de vraies implémentations. Son tableau provisoire n’autorise pas à dire qu’il n’existe aucune implémentation, pas plus qu’un lien 404 ne prouve l’absence de tests. Le contre-exemple est un argument public, non un consensus. Aucun acteur nommé n’est accusé d’avoir produit une fausse déclaration.

Le reçu proposé est une recommandation de gouvernance de Daniel Kade, pas une exigence, une certification ou une solution technique annoncée par le W3C.

Sources

  1. Actualité W3C — Première Working Draft publique de The Profiles Vocabulary
  2. W3C — The Profiles Vocabulary, FPWD du 20 août 2026
  3. W3C — Artefact RDF Turtle daté de PROF
  4. W3C — Historique de publication de The Profiles Vocabulary
  5. Dépôt W3C DXWG — Issue 29 : axiome conformsTo at risk
  6. Dépôt W3C DXWG — Issue 58 : correction de la chaîne de propriétés
  7. Dépôt W3C Data Shapes — contre-exemple de l’Issue 882
  8. W3C DXWG — Rapport d’implémentation de The Profiles Vocabulary
  9. W3C — Charte du Dataset Exchange Working Group
  10. W3C — Types de normes et de documents
  11. W3C — Process Document du 18 août 2025
  12. Heng Lu — On the Agency Problem at the Core of Internet Governance