SHACL (RDF Shapes Constraint Language) : enfin la possibilité de valider des données RDF

SHACL (RDF Shapes Constraint Language) : enfin la possibilité de valider des données RDF

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

Next Post:
Previous Post:
There are 7 comments for this article
  1. Emmanuel Barthe at 16 h 19 min

    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 :-)

  2. Vincent at 10 h 45 min

    « 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 !

  3. Antoine Zimmermann at 15 h 46 min

    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.

    • thomas Author at 16 h 20 min

      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.

      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.

      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.

      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.

      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) ».

      • Antoine Zimmermann at 20 h 30 min

        « 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).

        • thomas Author at 8 h 53 min

          Justement, le lien de sous-classe, c’est l’ontologie. Et il faut un raisonneur pour l’exploiter

          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).

          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

          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).

          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).

          Tout à fait.

  4. Pingback: Créer des référentiels SKOS/RDF à partir d'Excel - Sparna Blog

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Vous pouvez utiliser ces balises et attributs HTML : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>