Re: ValidationResult for missing data?

On 2/12/2017 0:22, Florian Kleedorfer wrote:
> 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?

Yes that should work, but of course takes you outside of what other 
tools would understand unless they also run your pre-compiler.

Holger



>
>
> As for your second suggestion: very useful hint, too! Still processing...
>
> Thanks
> Florian
>
>
>

Received on Friday, 1 December 2017 19:30:38 UTC