Re: ValidationResult for missing data?

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.

>
> 2. There seems to be no way to determine which part of the data graph 
> (ie, what triples or what nodes) are covered by the shapes and found 
> valid. If the data graph contains additional data not covered by any 
> of the shapes, we don't have an easy way of stripping that data.

The definitions in the spec only cover the "negative" cases, i.e. what 
target nodes produce errors. The spec furthermore does not prescribe any 
algorithm, or whether and how these target nodes even need to be touched 
upon. The result vocabulary thus also does not include terms for 
positive results. Since this is likely a common use case, we have 
defined dash:SuccessResult as a possible term:

     http://datashapes.org/dash.html#SuccessResult

The algorithm to find these is hopefully straight-forward - just get the 
set of target nodes for a shape that doesn't show up in the violation 
report.

Holger


>
> Is there something we are missing? Are these unusual requirements? Are 
> there best practices know to deal with these requirements?
>
> Thank you for your support!
>
> Best regards,
> Florian
>

Received on Thursday, 30 November 2017 14:28:08 UTC