Re: shapes-ISSUE-96 (Violation IDs): Should the validation results contain stable IDs to indicate the type of violation [SHACL Spec]

On 10/6/15 5:36 PM, Dimitris Kontokostas wrote:
> I agree that this can indeed be useful. For simple cases it can work 
> well but for nested constraints, as Peter mentioned, with and/or/not 
> it is not clear what happens.
>
> In nesting cases, even the current spec is problematic.  e.g. when an 
> 'and' operator fails, does sh:sourceConstraint link to the 'and' 
> constraint or the lowest shape in the hierarchy that failed? and if it 
> links to one of those how can the engine identify the correct 
> constraint path that lead to that error? Additionally, what happens 
> when the constraint is a blank node?
> These details can be solved in time and when they do the violation id 
> annotations can follow the same approach.

For nested constraints, the current spec states that the top-level 
constraint will be attached to the result object. Some tools may want to 
use sh:detail to link to additional information such as the 
subconstraint(s) that failed.

For constraints that are blank nodes the links from the result object 
are only meaningful as long as the bnode can be resolved, e.g. for the 
duration of the corresponding Jena objects.


>
> Another comment from my side is that for the core vocabulary, 
> violation id's are (probably) aligned with the facets e.g. 
> sh:minCount, sh:maxLength, etc and there is no need to re-define new uris.
> This of course depends if we want to support only core or a 
> generalized solution.

I would favor a general solution. Also, we don't really have a 
one-to-one mapping between properties and constraints at this stage, 
e.g. sh:pattern+sh:flags, sh:qualifiedValueShape+sh:qualifiedMinCount 
are actually pairs.

Holger

Received on Tuesday, 6 October 2015 09:04:27 UTC