Summary

  • Le groupe Data Shapes du W3C a publié le 17 septembre 2026 un premier projet public intitulé SHACL 1.2 Inference Rules. Un premier projet SHACL 1.2 Rules existait déjà depuis décembre 2025.
  • Le texte sépare le graphe de départ du graphe inféré. Le lien sh:sourceRule entre un triplet déduit et sa règle est une possibilité offerte au moteur, non une obligation générale.
  • Le statut de projet public n'est ni une Recommandation ni une approbation par les membres du W3C. Les tests cités ne couvrent pas, à eux seuls, toute la conformité.

Un graphe peut devenir plus riche sans que sa source le soit. Un moteur prend des assertions existantes, applique des règles et produit d'autres triplets. À l'écran, le nouveau triplet peut ressembler à tous les autres. Dans une enquête ou une décision, pourtant, son origine est différente : il dépend d'un calcul, d'une version de règles et d'un ensemble précis de données.

C'est sur ce passage que porte le projet annoncé le 17 septembre. Le W3C n'a pas inventé les règles SHACL cette semaine : sa publication de décembre 2025 présentait déjà un projet SHACL 1.2 Rules. Le nouveau document, baptisé Inference Rules, expose notamment le graphe de base, le graphe des inférences et leur réunion comme graphe d'évaluation. SHACL Core reste centré sur la validation des données ; ici, il s'agit de produire des énoncés supplémentaires.

Le détail d'exécution compte. Les règles peuvent être réparties en couches, ordonnées et répétées. Certaines produisent des triplets temporaires qui servent au calcul puis disparaissent du résultat final. Il serait donc trompeur de traiter la photographie finale du graphe comme le journal complet de son élaboration. Elle montre ce que le moteur a retenu, pas nécessairement toutes les étapes.

La portée exacte de sh:sourceRule

La section 9 autorise un moteur à produire, en option, des triplets supplémentaires qui relient un énoncé inféré à la règle productrice. La propriété sh:sourceRule fournit ce lien ; la valeur devrait être un IRI. Si ces traces sont créées, elles ne doivent pas être visibles aux règles pendant leur exécution. Cette précaution évite que le récit de l'inférence devienne lui-même une entrée susceptible de changer l'inférence.

Le mot important reste « option ». Le projet ne promet pas que tout moteur livrera cette trace. Même présente, la seule identité d'une règle ne dit pas quelle version du graphe a été utilisée, si le traitement a atteint son terme ou qui a accepté le résultat. Ce sont des questions pour l'application qui emploie les triplets, non des faits que l'on peut attribuer par défaut au W3C.

Les limites ne sont pas seulement documentaires. Un type de règle non pris en charge doit provoquer un échec. Le moteur peut aussi déclarer un échec après une limite configurée d'itérations ou de triplets produits. Le chapitre de sécurité évoque l'épuisement de calcul et de mémoire, ainsi que la création de données applicatives arbitraires. Un résultat partiel présenté comme complet déplacerait donc le risque vers celui qui s'en sert.

Enfin, il faut nommer le statut réel. Ce premier projet public suit la voie des Recommandations, mais le W3C précise qu'il ne vaut pas approbation et qu'il peut évoluer. Réussir la suite de tests ne prouve que les aspects examinés. La primauté du code en fonctionnement décrite par Lu Heng sert ici de discipline éditoriale : vérifier le comportement reproductible avant de donner au document plus d'autorité que son état ne lui en confère.

Sources