- From: Florian Kleedorfer <florian.kleedorfer@austria.fm>
- Date: Fri, 01 Dec 2017 15:22:14 +0100
- To: Holger Knublauch <holger@topquadrant.com>
- Cc: public-rdf-shapes@w3.org
Hi Holger! Thanks for your hints - comments below. Am 2017-11-30 12:22, schrieb Holger Knublauch: > On 30/11/2017 20:40, Florian Kleedorfer wrote: >> Hi, >> >> We're looking at using SHACL for checking if a data graph contains the >> data we expect, hoping that the ValidationResults can be reported to a >> GUI that allows users to fill in the missing data or correct wrong >> data. This report is why we like shacl: it tells you what is >> wrong/missing. When valid, the data covered by the shapes graph should >> be extracted from the data graph. We are facing two problems that make >> us question if SHACL is the right tool for this: >> >> 1. If the data graph does not contain any nodes that are identified as >> focus nodes, there are no validation results. That is, the case in >> which the data does not look at all like what we expect is >> indistinguishable from the case in which the data is completely valid. > > For constraints that apply to the whole graph (including empty > graphs), you can use fixed targets with sh:targetNode, e.g. > > https://www.w3.org/wiki/SHACL/Examples > > Note that these target nodes are not required to exist in any triples > - the shape will still be executed. > I see - if we want to use a static shape that does not contain any ABox URIs found in the actual data we want to validate against, then we'd have to use the 'trick' from the example, using the URI of one of the classes. That's a bit technical - it has the desired effect, but it is not a straightforward way to specify that we require data for a shape. The system we are building is just a framework, so the actual shapes are written by framework users (programmers). Each one of them has to understand this trick in order for the resulting system to work properly. That might be acceptable, or it might be prohibitive. However, it should be possible to generate such shapes based on the existing ones. Eg, scanning for all sh:targetClass triples and generating the targetNode shape with the inverse rdf:type property path. If so, we could add a 'SHACL extension' (that will only work in our framework) that allows for making shapes 'required', for example: consider the simplified shacl-playground sample shape: @prefix dash: <http://datashapes.org/dash#> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . @prefix schema: <http://schema.org/> . @prefix sh: <http://www.w3.org/ns/shacl#> . @prefix xsd: <http://www.w3.org/2001/XMLSchema#> . @prefix sh-ext: <http://www.example.org/shacl-ext#> . @prefix ex: <http://www.example.org/data#> . schema:PersonShape a sh:NodeShape ; sh:targetClass schema:Person ; sh-ext:required true; sh:property [ sh:path schema:givenName ; ] . And because of the "sh-ext:required true" triple, this shape is added to the shapes graph prior to evaluation: ex:PersonRequiredShape a sh:NodeShape ; sh:targetNode schema:Person ; sh:property [ sh:path [ sh:inversePath rdf:type]; sh:minCount 1; ] . That should work, right? As for your second suggestion: very useful hint, too! Still processing... Thanks Florian
Received on Friday, 1 December 2017 14:22:51 UTC