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.

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.

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

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.