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

Cet article SHACL (RDF Shapes Constraint Language) : enfin la possibilité de valider des données RDF est apparu en premier sur Sparna Blog.