C'est avec plaisir que je présente une nouvelle application dans…
SHACL (RDF Shapes Constraint Language) : enfin la possibilité de valider des données RDF
Edit (16/04/2020) : intéressé pour essayer SHACL ? testez SHACL Play!
La vie des standards est parfois un peu difficile à comprendre, et c’est particulièrement vrai pour ce qui concerne le web de données. Pourquoi en effet existe-t-il depuis 2004 un standard – OWL – permettant de faire des raisonnements automatiques sur des données, ce dont on a rarement besoin, alors qu’il n’existe aucun standard W3C pour vérifier si des données sont conformes, ce dont on a toujours besoin ? la réponse est sans doute dans les besoins et les problématiques des participants au W3C à l’époque, et dans la vision d’un web « sémantique » qui penchait plus vers un idéal d’Intelligence Artificielle que vers un idéal de Données Liées. Seulement on a vite compris que pour faire du raisonnement il faut avoir des données correctes.
Une nouvelle recommandation W3C prévue pour juin 2017, SHACL (SHapes Constraint Language), va remédier à ce manque en permettant d’exprimer des contraintes de vérification sur un graphe RDF.
Le problème avec OWL
Je participe à beaucoup de projets qui impliquent des transformations et des publications de données RDF ou SKOS sur le web. Et c’est bel et bien d’abord des problématiques de validation et de vérification de données que nous avons, et pratiquement jamais des besoins de raisonnements. Or une ontologie n’est pas faite pour vérifier la conformité des données à une spécification, ni faite pour décrire la structure d’un formulaire de saisie de données répondant à ces spécifications.
Ce que nous faisons donc systématiquement est donc de quand même créer une ontologie, mais de « tordre » l’interprétation de cette ontologie en l’utilisant pour vérifier des contraintes. Par exemple le fait d’exprimer que la propriété « a_pour_auteur » a pour « domaine » la classe « Document » en OWL/RDFS veut dire « si X porte la propriété a_pour_auteur, alors c’est un Document », et certainement pas « la propriété a_pour_auteur ne devrait être exprimée que sur des Document »; mais c’est pourtant comme cela que l’ontologie créée est utilisée dans ce contexte (en dérivant par exemple des règles de vérification SPARQL à partir des axiomes OWL).
SHACL
SHACL permettra de spécifier la « forme » (Shape) à laquelle on souhaite qu’un graphe RDF réponde. Cette spécification s’exprime par exemple comme cela (Attention, cet exemple est extrait de la version temporaire de SHACL au 02/01/2017 et peut changer dans la recommendation finale) :
ex:PersonShape a sh:Shape ; # Applies to all persons sh:targetClass ex:Person ; sh:property [ # Constrains the values of the ex:ssn property sh:predicate ex:ssn ; sh:maxCount 1 ; sh:datatype xsd:string ; sh:pattern "^\\d{3}-\\d{2}-\\d{4}$" ; ] ; sh:property [ sh:predicate ex:child ; sh:class ex:Person ; sh:nodeKind sh:IRI ; ] ; sh:property [ rdfs:comment "A person's parents are represented via ex:child used in the inverse direction." ; sh:path [ sh:inversePath ex:child ] ; sh:name "parent" ; sh:maxCount 2 ; ] .
Comment décoder cet exemple ? « Sur les ex:Person, il faut que la propriété ex:ssn (numéro de sécu) soit présente au maximum une fois, et qu’elle soit une chaine de caractère qui réponde à une certaine expression régulière. Il faut également que la propriété ex:child soit une référence à des IRI/URI qui soit une autre ex:Person. Il faut également qu’une ex:Person soit référencée au maximum 2 fois par ex:child ». Et ainsi de suite.
La version publique de SHACL est publiée à https://www.w3.org/TR/shacl/ mais je vous recommande d’ici juin de vous référer au document en cours d’écriture à https://w3c.github.io/data-shapes/shacl/.
Validateurs SHACL
De la même façon que des ontologies OWL peuvent être interprétées par des raisonneurs OWL, les contraintes SHACL seront vérifiées par des vérificateurs SHACL. L’implémentation la plus avancée est sans doute celle de TopQuadrant (les éditeurs principaux de la recommendations SHACL) qui a publié en open-source l’implémentation de SHACL utilisé dans TopBraid.
Europeana a également annoncé un ensemble de règles SHACL pour vérifier les données EDM (Europeana Data Model), ainsi qu’une implémentation d’un validateur SHACL.
Il faut également noter que, si SHACL permet de valider des données a posteriori, la recommandation inclut également ce qu’il faut pour utiliser les règles pour créer des formulaires de saisie (ordre des propriétés, libellés/regroupement des zones, etc.), ce qui permettra donc de spécifier la structure de formulaires de données sémantiques.
Une technologie importante pour la publication et l’intégration de données
SHACL va modifier profondément la façon dont on mène les projets web de données. Plutôt que de définir une ontologie forcément un peu bancale ou limitée (car pas utilisée pour son objectif principal qui est de donner un point de vue sur des données), on commencera par définir un jeu de contraintes SHACL que l’on souhaite vérifier sur les données. Tous les projets d’échange et d’intégration de données vont pouvoir tirer parti de cette nouvelle brique.
Cela assainira également le discours autour du web de données : il ne sera plus obligatoire de passer par une étape où l’on doit expliquer ce qu’est une ontologie ! Bref, je vois SHACL comme un composant important dans l’ensemble d’outils dont nous disposons pour partager et lier des données de qualité sur le web. Et vous, pensez-vous que SHACL vous sera utile ?
Illustration de l’article : By Deutsche Fotothek, Public Domain, https://commons.wikimedia.org/w/index.php?curid=6483869
Rester concret, « down to earth », ne pas se laisser prendre par les modes ni les grandes théories. +1.
J’apprécie — et tend moi-même à pratiquer ainsi.
Ce qui n’empêche pas de se tenir au courant des grandes théories — et d’y piocher ce qui peut servir
Je rejoins Antoine Zimmerman sur la complémentarité de OWL et SHACL.
Le problème avec OWL, c’est le mauvais usage qui en est fait quand on veut valider ou contraindre des données. Les contraintes en OWL vise à définir la sémantique (un parent est une personne qui à au moins un enfant) et non à contraindre le contenu d’une base de donnée (il faut absolument renseigner les enfants pour toute personne indiquée comme parent dans la base de données des allocataires de la CAF). OWL peut apporter tant pour la phase de conceptualisation d’un application faisant partie du système d’information (communication s’appuyant sur un langage partagé interprétable précisément -> qualité de la communication) que pour l’agrégation sémantique (on revient au sens de données afin de les interpréter correctement avant de les lier en établissant de liens implicites par le moyen des moteurs d’inférence à partir de règles déclaratives, ce qui est bien plus simple, bien plus sur et donc moins couteux que de la faire de manière procédurale).
Bienvenue à SHACL donc, qui contribue à des besoins qui ne sont pas dans le périmètre de OWL. Ne pas hésitez à redécouvrir OWL et à faire l’effort de comprendre l’usage qui peut en être fait pour apporter de la valeur à l’entreprise pour améliorer l’interprétation des données et la communication.
« Et c’est bel et bien d’abord des problématiques de validation et de vérification de données que nous avons, et pratiquement jamais des besoins de raisonnements »
Tout a fait d’accord, cette nouvelle recommandation devrait apporter beaucoup au monde du web des données !
L’opposition que tu fais entre OWL et SHACL est quelque peu inappropriée à mon avis. Pour faire simple :
SHACL permet le contrôle.
OWL permet la souplesse.
Si mon application évolue dans un environnement ouvert, décentralisé et hétérogène, j’ai besoin de la souplesse de OWL. Si j’ai un système qui gère de la données, j’ai besoin de contrôle. Les deux se complètent bien.
Si j’ai X a pour auteur Y, ou bien X est un livre, je m’attends à ce qu’on me présente X quand je demande tous les documents. Je veux un truc qui exprime que le domain de « a pour auteur » est « document », et la classe des livres est une sous-classes de « document ». Je le veux au sens de OWL.
Cela n’empêche pas d’utiliser également une vérification SHACL qui dit que si je trouve des descriptions de bouquins, je ne les traite (p.ex., ne les enregistre dans ma base de données RDF) que si chaque bouquin a la propriété my:isbn explicitement et non pas your:isbn, même si peut-être selon toi, your:isbn est équivalent à my:isbn.
Au passage, on peut exprimer des contraintes de validation avec [OWL + un raisonneur + un peu de code] que SHACL ne suffit pas à exprimer. Par exemple, je souhaite n’autoriser le triplet X a_pour_auteur Y que si je sais que X est un document. Le raisonneur et son ontologie me diront si on peut inférer que X est un document, et si ce n’est pas le cas, je refuse le triplet.
L’intérêt de SHACL est qu’il permet de séparer les préoccupations en externalisant dans une représentation concise et déclarative tout ce qui concerne la validation de données.
Notons aussi que OWL n’est pas le seul langage de représentation de connaissances pour RDF. On peut faire une ontologie sous forme de règles SWRL, RIF, SPIN, SPARQL construct, Jena rules, voire combiner tout ça.
Merci pour cet apport de nuances. Je te rejoins effectivement sur la complémentarité entre OWL et SHACL, et on aura sans doute besoin des 2, même si pour moi la distinction entre ce que l’on met dans l’ontologie et ce que l’on met dans les contraintes est encore floue (et peut-être qu’on y mettra un peu la même chose d’ailleurs). Et je continuerai à faire des ontologies, pas de soucis là-dessus.
Le fond de mon billet était bien que jusqu’à présent, si j’avais un système qui gérait de la donnée (RDF), je n’avais rien (dans les standards W3C) pour faire du contrôle.
Le triplet [OWL + un raisonneur + un peu de code] peut être parfois suffisamment compliqué à mettre en oeuvre pour limiter cette possibilité. Et il me semble que SHACL est tout à fait capable d’exprimer la contrainte que tu donnes en exemple :
ex:a_pour_auteur_Shape a sh:Shape ;sh:subjectsTargetOf ex:a_pour_auteur ;
sh:class ex:Document .
« Pour tout sujet de la propriété a_pour_auteur, je vérifie que son type est ex:Document (directement ou par un lien de sous-classe) ».
« directement ou par un lien de sous-classe » . Justement, le lien de sous-classe, c’est l’ontologie. Et il faut un raisonneur pour l’exploiter. Évidemment, si l’ontologie n’est qu’une hiérarchie de sous-classes, pas la peine d’utiliser un raisonneur OWL mais il faut quand même implémenter la transitivité de la relation de sous-classe qui est propre à la sémantique de rdfs:subClassOf et non à la spec de SHACL. Mais si l’ontologie est plus expressive, implémenter le petit exemple que j’ai donné avec SHACL + du code nécessite de coder toutes les règles de raisonnement nécessaire à cette ontologie. L’idéal, pour une application plus complexe et riche, c’est de combiner SHACL et OWL (ou éventuellement un autre langage d’ontologies/de règles).
Mon point est que dans beaucoup des projets que je vois, l’objectif d’utilisation des technologies du web de données est un objectif de reprise/nettoyage/aggrégation/éventuellement alignement/fusion/publication de données; et est moins un objectif de modélisation d’un domaine de connaissances. Donc l’utilisation d’un raisonneur ne se justifie que rarement dans ce type de projet (mais je ne dis pas que ce n’est pas justifié dans d’autre cas).
La transitivité de la relation rdfs:subClassOf est prise en compte dans la spec SHACL directement et ne nécessite pas l’utilisation d’un raisonneur; voir la définition de SHACL type et SHACL instance. Donc pour des ontologies simples qui ne reclassifient pas les instances sur la base de règles (« defined classes »), pas besoin de raisonneur pour faire une validation avec SHACL (il me semble).
Tout à fait.
Pour ceux qui voudraient s’essayer à SHACL, il y a maintenant un « bac à sable » : http://shacl.org/playground/
Je trouve SHACL bienvenu. Je travaille avec OWL pour définir exactement ce qu’est la donnée par les classes et comment une donnée s’articule autres classes. OWL est essentiel pour mes requêtes et vérifier la cohérence du Graph, ou pour assigner une classe à une donnée orpheline de classe (on est jamais à l’abris d’une erreur). Ici, OWL a tout son intérêt.
Cependant, les utilisateurs de mes outils sont complètement perdus sans une interface de type formulaire. Avec SHACL, on va pouvoir générer facilement une interface de formulaires automatique. En gros, plus besoin de parler d’ontologie à nos chers utilisateurs. C’est un bien pour eux, et pour nous. C’est un mal, car le temps passer au développement d’une ontologie sera encore moins bien compris par les utilisateurs des plateformes.
Si seulement SHACL avait été finalisé avant que ne prenne ma retraite … c’est un outil attendu depuis 15 ans, vous allez enfin pouvoir travailler sérieusement
A tous ceux qui s’intéressent à SHACL, je signale un nouvel outil SHACL Play que j’ai mis en ligne, mais pas encore annoncé officiellement (sauf maintenant !) : http://shacl-play.sparna.fr/. Il y a notamment un « catalogue de Shapes » partagé via un document collaboratif dans Github : https://github.com/sparna-git/SHACL-Catalog/blob/master/shacl-catalog.ttl