From validation of the data in the knowledge graph to further projects of data integration and dissemination, many different usages of SHACL specifications were explored…

… and more exploratory usages of SHACL are foreseen !

“

A knowledge-graph powered open data portal

The European Parliament Open Data Portal (EPODP) went live in January 2023. Its particularity is that it is not a mere aggregation of documents or dump files from business applications in custom formats; but rather a collection of datasets each extracted from a central semantic knowledge graph, itself aggregating data migrated from approximately twenty business applications. The result is a semantically interoperable open data portal : the semantic of its data model is clearly defined and documented, and reuses widely deployed existing ontologies. It already provides its data to different consumers (most notably the europarl website and the EU law tracker) in a context of cross-institutions interoperability. The data captures the activity of the parliament : as co-legislator together with the Council of the EU, the European Parliament (EP) holds plenary sittings, in which reports originating from committees, as well as motion for resolutions, are amended and voted; after the vote, the final adopted texts are published.

The focus on semantic interoperability of EPODP maximizes the potential of reuse and linkage of its datasets, and maximizes the quality of the offered data. It comes however at a cost when building the portal : deep analysis and understanding of the existing data and documents structure is required to capture the business semantic. SHACL is the way to formally encode this business semantic – but how is it deployed in practice ? how is it maintained ? what are the different types of SHACL specifications used ?

SHACL at the center of a model-driven approach

SHACL in the EPODP is at the basis of multiple model-driven usages depicted in the following diagram:

There was two key drivers for introducing the use of SHACL in the EPODP project : validation of the data in the knowledge graph, and generation of public documentations of the models. The same SHACL specification that captures the business semantic is directly actionable to be published as a documentation and to validate the data. The produced documentation is a set of public files, such as the ELI-EP application profile documentation and others accessible from the EPODP developer’s corner. The SHACL Play documentation generator is used to produce the documentation pages. Data validation happens at earlier stages, after data transformation steps.

Two additional usages of SHACL specifications were explored : one was to generate SPARQL queries to extract the content of datasets from the larger knowledge graph. The SHACL specification of a dataset content is interpreted to generate SPARQL CONSTRUCT queries, executed against the entire knowledge graph, to return a subset of data corresponding to the specification. The query generation was implemented in SHACL Play, however the EPODP chose to continue using manually crafted SPARQL queries to generate the datasets. The other usage was to complement the SHACL specifications with the mapping rules used to feed the corresponding properties or classes in the graph. This has the advantage that the mapping rules are documented and maintained alongside the specification and not in a separate document. This work is ongoing.

More exploratory usages of SHACL are foreseen : generating a query user interface based on the SHACL specification, using the Sparnatural query builder, and also input forms to facilitate the creation of DCAT datasets descriptions. Additionally, automated generation of the JSON-LD context and the JSON schema of the API are foreseen.

Not « 1 SHACL to rule them all », but application profiles, dataset definitions, and migration specifications

The definition of the EPODP knowledge graph is not captured in a single SHACL specification, but rather in three different application profiles, each being a selection of classes and properties of one sub-domain : ELI-EP covers the description of documents and activities, ORG-EP covers the definitions of EP organisations (such as committees, political groups, etc.) and members of the parliament, and SKOS-EP covers how controlled vocabularies are structured. In addition, DCAT-EP is the specification for how dataset records are described in the EPODP catalog – but this is not part of the knowledge graph per se.

Together, ELI-EP, ORG-EP and SKOS-EP specify the structure of the entire knowledge graph from which the datasets are extracted. In addition, the structure of each dataset family available in the EPODP (such as adopted texts, plenary documents, parliamentary questions, etc.) is also described in SHACL, referred to as « DSD » for « Dataset Definition ». While the application profiles describe every possible properties on generic shapes, the DSDs will specify only the subset of properties used in a dataset, with possibly different cardinalities or range. For example, ELI-EP specifies that « a Work may have the property eli:adopts«  (with no minimum cardinality (eli:adopts is defined as « Indicates that the work represents the adopted work of one or several related works »). The DSD for adopted texts datasets specifies the shape of « Adopted texts » as a subset of the Works, and indicates that the minimum cardinality of eli:adopts is 1 for this particular subset. Besides, some properties, such as eli:amends are not available for adopted texts, thus not declared in the DSD.

In addition, specifications of the conversion of some data sources are also specified in independent SHACL files. The articulations of these 3 kinds of SHACL files and the reused ontologies is depicted in the following diagram:

There is currently no reuse or reference of shapes across the different specifications. Each is independent. A nice improvement would be to study how SHACL DSDs could be derived from the application profile SHACL, without redeclaring the identical constraints.

Editing SHACL in spreadsheets

In total 16 SHACL specifications are currently published in the EPODP, and around 80 are used to validate data migrated from each individual sources. The first step in the specification of each model is the design in a diagram such as the ones visible in the public documentations of the models. The EPODP team is then using spreadsheets to encode the specifications, adapted from the one provided in the SHACL Play suite. The spreadsheet is converted to SHACL using the xls2rdf converter. Spreadsheets provide a simple editing solution, with an easy learning curve, made even easier with a few formulas to compute cell values automatically. It even provides ways for editing advanced patterns (such as the ability to directly turtle lists for sh:or, or blank nodes for property paths), but of course still limits the expressivity. The following screenshot shows how property shapes look like in the spreadsheet:

Results and future perspectives

The EPODP use-case shows how SHACL can be applied in a systematic way in a data integration and dissemination project : at the data transformation step, at the knowledge graph level, and at the data dissemination. Public documentation, data validation, data extraction are tasks that can be be automated based on a SHACL specification. While the context is one of a large public institution, the same approach can be applied in industrial contexts. The SHACL specifications are a cornerstone of such projects, enabling semantic interoperability at large and a mutual understanding between business experts, data analysts, developers, and data consumers.

”

Veronika’s book will be divided into three parts :

1. Back to Basics
Introduction to logic and RDF, brief skimming of the topics. Also covering various world assumptions.

2. Getting to know the stuff
Introduction to SHACL, including core, sh-sparql, advanced features.

3. Working with the stuff
SHACL Stories. Use cases, user stories and implementations.

Image : © European Union, [2024] – EP

Cet article European Parliament Open Data Portal : a SHACL-powered knowledge graph est apparu en premier sur Sparna Blog.

“

The Sparnatural knowledge graph explorer leverages SHACL specifications to drive a user interface (UI) that allows end users to easily discover the content of an RDF graph. What is the best way to make this UI-oriented SHACL specification ? if a SHACL specification for the knowledge graph structure already exists, can it be used directly ? does it require customization ? or is the Sparnatural SHACL spec completely decoupled from an existing knowledge graph spec ? and what if no SHACL spec exists at all ?

We faced all these different situations while deploying Sparnatural, and used various approaches to produce a satisfying end-user oriented specification. In particular, the Nakala repository is one of the latest graph for which Sparnatural was deployed. Nakala is a data repository that aims to preserve and disseminate data produced by French research projects in the Humanities and Social Sciences, in compliance with the FAIR principles. Nakala is a service offered by Huma-Num, a research infrastructure dedicated to the digital humanities. The Nakala knowledge graph contains `dcterms` metadata provided by researchers to describe the resources they upload. Additional non-dcterms metadata can also be provided. The metadata varies in quality and quantity depending on the researcher. When exposed in a SPARQL endpoint, resources, collections of resources and agents are described using the Europeana Data Model (EDM).

As the EDM dissemination channel for Nakala was new, no SHACL specification existed for it. We could have designed one for Sparnatural from scratch, but the choice was make to generate it automatically, with no human intervention. This was for three reasons : ease of configuration, flexibility in maintenance over time, and pedagogical reason, as it was important to explain the structure of the graph to target users.

Sparnatural UI

Let’s first have a look at what the Sparnatural UI looks like on an example from Nakala:

Once you know that « ProvidedCHO » stands for « Provided Cultural Heritage Object », and that « asWKT » encodes the location of a Place, you will be able to understand that the query searches for all ProvidedCHO entries gathered into a certain collection (« Cartes Université Bordeaux Montaigne » – a collection of maps), and selects their location and an optional description (and yes, the results of this query are displayed on a map, but that’s out of scope).

SHACL is derived automatically

In this project we wanted the shortest path from the graph to the query UI. Hence we used a SHACL generation algorithm, available in SHACL Play. By issuing SPARQL queries on an RDF graph, the algorithm determines the NodeShapes (targeting the classes used as values of `rdf:type`), and PropertyShapes (from all predicates used on instances on each class) of the model, with their node kinds, datatypes, class range, and cardinalities. It generates `sh:or` constraints when multiple datatypes or ranges are found. Note that in the case of Nakala a large variety of ranges are used, since the data comes from very open user inputs : the same `dcterms` property can be either an IRI or a Literal, with varying datatypes.

In addition, the algorithm computes some statistics on the dataset : the number of targets of each NodeShapes, the number of occurrences and the number of distinct values for each property shapes. The statistics are expressed using the `void` vocabulary, and `dcterms:conformsTo` is used to link void partitions to the corresponding shapes.

The SHACL Play documentation tool was then used to generate a report of the generated SHACL combined with the statistics. A few errors were spotted in the exported data, and fixed. We also saw that around 70 properties were present only a few times out of 700.000+ ProvidedCHO records. These properties were applied by probably a single or very few researchers when describing their data. It was decided to filter them out to keep the final UI simple, with an extra filtering step : based on statistics, property shapes used less than 0.1% of the number of targets of their node shapes are removed.

Here is a screenshot of the report : the right column shows the number of distinct values, and the column before is the number of total occurrences; we can immediately see that `dct:isReplacedBy` occurs only once, and `dct:isRequiredBy` occurs 81 times. They will be filtered out.

Sparnatural reads SHACL

Sparnatural can then read the SPARQL specification, together with the dataset statistics. When designing a query, value selection widgets for literal properties are determined by looking at the `sh:datatype` constraint (for number, dates, boolean, or map widgets). For IRI properties, statistics are used to distinguish between list and autocomplete widgets. Predicates with less than 500 distinct values will use a dropdown list, and those with more will use an autocomplete search field. The range is determined by reading `sh:class` or `sh:node`. The label to show in dropdown lists or to search on autocomplete field is determined by looking at a `dash:propertyRole = dash:LabelRole` annotation.

How about labels ? Sparnatural can read them from classes and properties of the original OWL file, if provided with it. Otherwise local names of target classes or predicates are used.

Other configuration techniques

Other Sparnatural deployments, such as the DBPedia demo are designed in SHACL from scratch, using spreadsheets. This requires more manual work, but has the advantage of tailoring the UI to exactly what needs to be shown, including user-oriented labels/tooltips/icons, hiding some properties, taking shortcuts or declaring inverses using property paths, etc. In the case of DBPedia, no SHACL spec exists, and deriving it automatically for the entire graph would probably not make a lot of sense, hence the necessity for a manual design.

For other projects we are working on a third configuration technique : a SHACL spec that describes the exact content of the graph is first built. It is used to publish the documentation of the model and to validate the data. A separate shapes file containing a Sparnatural-specific configuration layer is then added on top of it. That layer can hide shapes by applying an `sh:deactivated` annotation on them, can specify the UI widgets to use, add additional `dash:LabelRole` flags, add shortcut or inverse properties, etc.

The 3 configuration paths are shown in the following diagram:

Your query UI in minutes

We combined 4 tools (all open-source) : an algorithm to generate a « profile » in SHACL of an RDF dataset, a statistical report generator, a SHACL filter based on statistics, and the Sparnatural query UI. The ability to generate the SHACL profile and review it in the report provided a way to understand the structure of the data in a matter of minutes, while hours would have been necessary with SPARQL queries, without a guarantee of completeness. The provision of the query UI was made by dropping the SHACL file and the statistics to Sparnatural, without manual intervention. This shows the pivotal role of SHACL for data quality and model-driven approaches for knowledge graphs projects.

”

We look forward to reading Veronika’s book, and you ?

Cet article Nakala : from an RDF dataset to a query UI in minutes – SHACL automated generation and Sparnatural est apparu en premier sur Sparna Blog.

The possible entities, connections and properties that are shown to the user need to be specified to Sparnatural. This configuration is written in a SHACL specification. This specification encodes both the structure of the knowledge graph (as we want it to be presented to the user), plus some additionnal UI-oriented information, like icons, order of entries, or value selection widgets to use.

How can the SHACL configuration of Sparnatural be produced ? we faced 3 different situations : either we do it manually, or (semi-)automatically, or with an off-the-shelf specification complemented with manual annotations. We will give you a brief description of each possibility below.

Write your SHACL manually (in Excel)

SHACL has one main disadvantage : there is no widely available, free-to-use SHACL editor to create/edit these specs (while Protégé, for example, allows anyone to edit an OWL ontology). To overcome this lack of tool, we are using an Excel-to-SHACL conversion tool, xls2rdf. We (and our users) write the specification in an Excel template, that is then turned in SHACL by an API call to xls2rdf. This is what we described in a previous post.

We have a good documentation on how to design your Sparnatural documentation in Excel, if you want to try it (but see the Hello Sparnatural tutorial first to setup your working test page). And we are here to help if you need to ! (ask questions on the Github repository).

If you are looking for a general-purpose SHACL Excel template, there is one in SHACL Play.

Get your SHACL automatically (statistics included)

SHACL is machine-readable and also writable, so we can use our SHACL generation algorithm to produce a SHACL « profile » of an RDF dataset. The algorithm sends SPARQL queries to identify all classes and properties, with their range, cardinalities, datatype, etc. This SHACL profile can be fed to Sparnatural directly. With an additionnal bonus : it is also very useful to gather statistics of the dataset at this stage. Number of instances of each class, number of occurrences of each property and number of distinct values. Why is it useful ? first because Sparnatural is able to show them in the UI, giving a hint to the user on how many entities of each type exist in the dataset:

second because by knowing how many distinct values exist for a given property, Sparnatural can show either a dropdown list (if there are less than 500) or an autocomplete search field (if there are more).

Also, as a side effect, seeing the profile and statistics of your dataset can help you spot errors (« why does the statistics tells me that this identifier is not always present ? it should be mandatory ! »).

You can also provide the OWL ontology to Sparnatural along with the SHACL specification. Simply pass the 2 files in the configuration of the component. The ontology can be leveraged for 2 things : the hierarchy of classes and properties from the ontology can be used in the Sparnatural UI, and all labels and comments of classes and properties can be read to be displayed in the UI, giving nice defaults if they are not present in the SHACL spec.
This automated SHACL generation was the one used for the Nakala Sparnatural query interface, and here is how the properties look like, you can see it is organized according to the DublinCore properties hierarchy:

Grab an off-the-shelf SHACL specification

Some clients do write and publish SHACL specifications. Yes. This is the case for example for the European Parliament in their open-data portal. They publish the documentation of their data-model with our SHACL Play documentation generator. The specification existed long before we tried Sparnatural on their data. We simply took their specification, loaded it in Sparnatural and… voilà ! it worked seamlessly, but to make it nicer we added in a separate file additionnal icons and tooltips information.

SHACL Synergies

There is a lot of synergies to find with a SHACL configuration in a model-driven perspective. You can publish the documentation, validate data, power your Sparnatural UI, and generate your API JSON schema from the same specification file. And probably much more – what would YOU do with a SHACL specification of your knowledge graph ?

Cet article Sparnatural SHACL configuration : manual, automated, off-the-shelf est apparu en premier sur Sparna Blog.

To make it short, Sparnatural is a client-side component that allows non-expert users to explore an RDF Knowledge Graph by building SPARQL queries with little effort. 

Fully configurable – and customizable – it can be plugged to any existing SPARQL endpoint, without additional server required to adapt to your knowledge graph ontology. 

Innovative and intuitive, it aims at bringing your knowledge graph to your end-users in a visual way that « gamifies » the knowledge graph experience. 

Nb : Sparnatural is open source, under a LGPL-3.0 license.

So far, the configuration was made through an OWL ontology…

Sparnatural in SHACL ! 

… until now,

But the times they are a-changin’ …

You can now configure Sparnatural starting from a SHACL configuration spreadsheet !

SHACL in a nutshell 

Defined by a W3C Working Group, SHACL, as for « Shapes Constraint Language », is « a language for validating RDF graphs against a set of conditions. These conditions are provided as shapes and other constructs expressed in the form of an RDF graph. » 

First published in 2017, it has become a widely used standard to :

• describe structural constraints on data graphs ;
• validate that data graphs satisfy a set of conditions ;
• but also build user interface, generate code and integrate data !

The latter we will leverage for our brand new Sparnatural SHACL configuration.

Yes, in a spreadsheet !

SHACL may be quite unfamiliar for our users.

A good thing is you don’t need to be a SHACL expert to build your SHACL-shaped Sparnatural configuration.

Indeed ! the entire configuration is done via a spreadsheet whose columns correspond to the SHACL model.

Still, you can observe that all the Sparnatural features are here :

• the nodes & the edges of the knowledge graph, of course ;
• its labels and literal attributes (different kind of notes) ;
• but also the Sparnatural search widgets, icons, etc.

Give it a try ! 

Go to the DBpedia Museums demo :

Navigate the graph 

Start with picking up a class from the list and navigate through the properties to another class of the graph, search for a value…

… then click on the arrow to launch the query ▶️

Click on « Toggle SPARQL editor » below the query builder to display the corresponding SPARQL query :

… no need to say that you can create even more elaborate queries, just by adding new parameters when navigating through the knowledge graph !

Sample queries 

To give you a quick overview of it, you can also try to launch one of the sample queries we added to the demo.

On the screenshot below we can observe this one is a quite more complex query, using an optional parameter as we noticed that some values happen to be missing on DBpedia, either for Movements or Artworks…

Can we deduce that 19th-Century French women artists records are rather incomplete in English DBpedia ?

We’ll let you investigate on this point.

Multilingual 

It is also possible to translate (and display) your configuration in any language of your choice, so that you can showcase your knowledge graph in different languages – even if the graph itself does not contain labels or values with this language… 

Here translated in French :

Fully documented 

This new version of Sparnatural comes with an extensive documentation of all the features that can be used to date, from basic installation to more advanced configuration of the tool.

Get started with Hello Sparnatural !

Cet article Sparnatural : say it with SHACL ! est apparu en premier sur Sparna Blog.

To inaugurate my first article on Sparna’s blog, let’s share a little feedback of mine today about Sparna’s well-known SKOSPlay! whose 10 years’ birthday is to celebrate this year !

10 yo, quite a historic tool ! but more than ever actual in a context where the semantic technologies get front of the scene anew due to growing interest shown by the digital humanities movement to data interoperability projects via the standardized knowledge structuration (Wikipedia-Wikidata projects e.g., as semantic wiki devices), and also due to the last progress of artificial intelligence, now able to processing large amount of data and soon fully leveraging the potential of ontologies and knowledge graphs.

From asking for a taxonomy to querying RDF files with an API…

This said, in a more practical way, semantic web standards are not always easy to manipulate as a professional – if non-initiate to SPARQL and nor confirmed data scientist, and even when you have got to deal with a simple structured list of terms !

Either your data is already SKOS-standardized (great !), there sometimes come to have a gap between normalization step and visualization step that requires a bit more technical IT skills. Either – most of time – the common muggle-born is to start with a plain Excel spreadsheet, create a list, add some hierarchy, maybe other scope notes or definitions and… end far puzzled wondering how to get a 5-star data vocabulary ⭐ !

A SKOSPlay!-within-a-SKOSPlay!

Wink to @belett, anything possible now with SKOSPlay!

Aiming at visualizing (and printing !) SKOS thesauri, taxonomies and vocabularies at the very beginning, SKOSPlay! is a full online free and open source tool leveraging semantic technologies (RDF, SPARQL, inference, Linked Data) to generate downloadable HTML or PDF documents. More and more new features have been added since then : alignments display, OWL and SKOS-XL files processing, autocomplete fields and permuted indexes generating …

Hello @veronikaheim, maybe SKOSPlay! could match your need ?

… among other nice and useful developments.

But as an Excel aficionada, the one that I prefer is the Excel-to-RDF converter tool.

One sheet. One import. One result. Easy-peasy, happy terminologist :))

(And you can even keep your custom colors templates and formats !!! 🦄 )

Come on & let’s SKOSPlay!

Let’s figure out you want to display or construct a small vocabulary you could quickly visualize in a standardized SKOS-structured way :

Now to fit in the SKOS model your data has to follow a particular template you can fullfill by downloading on SKOSPlay! website.

First you have to define the header of the template : the global scheme of your vocabulary, its URI, title and description :

Adding the terms of your list (with the URIs)… Here with the “@en” language indication on top of the column as I am to create an English-French multilingual vocabulary :

Recreating the arborescent structure through the Excel template (don’t mind my color palette, I always like colouring my Excel sheets to better visualize the info at a glance !).

The hierarchical broader-narrower structure is to be recreated by adding a “skos:narrower” column (or skos:broader, as you want, with only 1 broader value per line) where you will list the different specific values front of the more generic one (separated by comas). Here I used a PREFIX too in order to shorten my http:// URIs, SKOSPlay! can process them anyway !

Then adding a few notes and other information (multilingual values, skos:notation, any other default properties known in the converter (see the documentation) or different custom elements of yours by adding other PREFIXes :

Your Excel template is ready to go ! quite an easy configuration in my demo here, but SKOSPlay! can also deal with skos:Collections, SKOS-XL and other advanced RDF structures : blank nodes, RDF lists, named graphs. And now possible to generate OWL and SHACL files with the converter too !

Now it’s time to turn your (finally-not-so-dirty-) data into a SKOS-charming file. Take your favorite magic wand SKOSPlay! Excel-to-RDF converter tool and load your Excel file in it (adding some optional parameters if needed).

Well done, it’s a wonderful RDF-ized vocabulary file (here in a Turtle format but you have also RDF/XML, N-Triples, N-Quads, N3 and TriG available) :

Wingardium Visualiza !

We’re almost done. Go back to the website, tab “Play!”, load your last RDF-serialized file and go to the next step to chose the kind of display you want to get, endly press (SKOS)Play! and … abracadataaaaaaa !

Many different options to visualize your arborescent data. Tree, static and dynamic, but also more « professional » and printable sorts of displays like alphabetical, hierarchical or permuted views :

And KWIC (as for « KeyWord In Context ») :

Even possible to load an online Google spreadsheet (mine is shared here), just by adapting a little its URL for the converter’s need. Interesting feature in a collaborative purpose when you are team-building a vocabulary !

The whole pack fully documented and findable on Sparna’s website & Git. Some recent users even produced a short video tutorial to show what they managed to do with different SKOSPlay! visualization tools.

Already knew about SKOSPlay! ? go see his little brother, SHACLPlay! and feel free to give us some feedback in the comments 

Happy Birthday SKOSPlay! & Long live Semantic Web !

A bit more Vouvray with your nougat de Tours ?

Cet article 2013-2023 : ‘Tis SKOSPlay!’s Birthday ! est apparu en premier sur Sparna Blog.

1. Give the input RDF data to be validated, by uploading an RDF file, pointing to a URL, or copy/pasting inline data;
2. Give the SHACL rules to use for validation, by uploading a file, pointing to a URL, copy/pasting inline data, or selecting the shapes from the catalog (see below);
3. Validate, and get a human-readable report generated from the SHACL raw validation report;
4. Access to the report in its RDF or CSV variant;

Here is a screenshot of how the validation report looks like :

SHACL Play! features :

1. Free, no registration required, no limit;
2. Easy-to-use input form;
3. Multiple RDF serialisations supported (Turtle, RDF/XML, n3, TriG);
4. Versatile input methods for both RDF data and SHACL rules (upload, URL, copy/paste, catalog);
5. Human-readable validation report, for quick analysis of the issues to be fixed in the data (or adjusted in the shapes);
6. Downloadable validation reports in CSV or raw RDF;
7. Asynchronous validation to avoid timeouts, for large datasets (greater than 100000 triples);
8. Permalinks to validation reports when both RDF dataset and SHACL rules are online;
9. Catalog of online public shapes for documentation and quick validation (see below);

SHACL Play also features a command-line variant (see the documentation on the Github wiki).

Future features could include :

1. Improved display of validation report, with possibly different styles of report (depending on the « styles » of the Shapes):
2. Human-readable display of a SHACL graph;
3. Online data transformation engine based on SHACL Rules, with a first focus on converting an OWL ontology to SHACL constraints (see this excellent description of one possible set of rules to derive SHACL shapes from an OWL ontology, by Irene Polikoff from TopQuadrant);

The Shapes Catalog

SHACL Play includes a catalog of online Shapes. The catalog is collaboratively editable by modifying the Shapes Catalog source file on Github, through pull requests.

Adding an entry to the catalog allows to:

• See the shapes listed in the catalog page;
• Get a form to directly validate data against these Shapes, e.g. if you want to validate your Shapes against « SHACL for SHACL » you can go to http://shacl-play.sparna.fr/validate?shapes=shsh;
• Get a direct permaling to the validation report if the validated RDF data is also online, so there even no need to submit anything through a form to get a validation report. e.g. http://shacl-play.sparna.fr/validate?shapes=shaclplay-catalog&url=https://raw.githubusercontent.com/sparna-git/SHACL-Catalog/master/shacl-catalog.ttl is the direct link for the validation of the Shapes Catalog source file against the Shapes Catalog SHACL file;

Another SHACL Validator

Another SHACL validator is the SHACL playground is at https://shacl.org/playground/. However the UI is too technical for newcomers, and it relies on a Javascript validator in the browser, thus I am not sure it would be capable of validating large Datasets.

How to edit/create SHACL rules ?

You need to create your own set of SHACL rules ? You don’t have a tool to do that and you don’t want to write Turtle file by hand ? One technique I use is to edit them in an Excel spreadsheet that is converted in RDF using SKOS Play Excel 2 RDF converter. Here are 1 example of such a file : OpenArchaeo shapes in Excel.

You could start from this template and modify it to create your own Shapes Graph.

Now let’s SHACL Play!

Post illustration : « Calculateur » Bulletin des sciences mathématiques 1922, found from https://www.bnf.fr/fr/mathematiques-informatique-et-sciences-du-numerique, from Gallica at https://gallica.bnf.fr/ark:/12148/bpt6k9620547z/f123.item

Cet article SHACL Play! free online SHACL validator for RDF data est apparu en premier sur Sparna Blog.

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.