Re: ISSUE-51: Updated draft and proposal

Just a quick update to illustrate how tool support could use 
sh:SuccessResults (see attached screenshot of ongoing TBC work).

Note that we will not be able to make the details of generating 
SuccessResults mandatory, because they are implementation-specific. For 
example we cannot prescribe that engines must populate the sh:focusNode 
field of a sh:SuccessResult because many engines will put the iteration 
over the focus nodes into the SPARQL queries, from where there is no 
simple way to collect which focus nodes were actually visited. 
Furthermore, some engines may include optimizations so that not every 
shape/constraint will be visited. An example is that sh:minCount=1 can 
be skipped if we already know that sh:hasValue is true. All this 
strengthens the viewpoint that SuccessResults can only be optional.

Holger


On 8/28/2015 9:04, Holger Knublauch wrote:
> In response to the discussions today, attached is an updated diagram 
> proposing the redesigned validation results vocabulary. For the 
> details, I have also attached the Turtle file.
>
> Severity has exactly three instances: Info, Warning and Error
>
> Failure currently has the following instance:
> - IOFailure (any networking or file loading problem)
> - SyntaxFailure (e.g. invalid SPARQL query, malformed SHACL structure)
> - UnsupportedRecursionFailure
>
> I am not 100% happy with the naming of "ValidationResult". To me, 
> every one of the three result classes represents validation results. 
> Can someone suggest a better term to group together "regular" results 
> with a severity?
>
> Otherwise, this is my PROPOSAL to resolve ISSUE-51.
>
> Holger
>