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

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.

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.


On Tue, Oct 6, 2015 at 4:42 AM, Holger Knublauch <holger@topquadrant.com>
wrote:

> On 10/3/2015 3:12, Peter F. Patel-Schneider wrote:
>
>> The proposal appears to be to add some other information to validation
>> result
>> identifying the SHACL syntactic construct that was violated.
>>
>> So if the shape is something like
>>
>> sx:s1 sh:scopeClass ex:c1 ;
>>   sh:property
>>    [ sh:predicate ex:foo ;
>>      sh:minCount 2 ] .
>>
>> and the data is something like
>>
>> ex:i1 rdf:type ex:c1 ;
>>   ex:foo ex:v1 .
>>
>> then the validation result would be something like
>>
>> [ rdf:type sh:ValidationResult ;
>>    sh:severity  sh:Violation ;
>>    sh:focusNode ex:i1 ;
>>    sh:focusNode ex:i1 ;
>>    sh:predicate ex:foo ;
>>    sh:xxxx sh:minCount ] .
>>
>> The claim is that this helps users and verification tests by identifying
>> what
>> happened.
>>
>> However, this information alone does not solve either case.  Consider a
>> shape
>> that has two property constraints on the same property, both with
>> sh:minCount
>> values.   No help here either for users or for validation.
>>
>
> The spec already mentions sh:sourceConstraint which points at the exact
> constraint (resource):
>
>     http://w3c.github.io/data-shapes/shacl/#results-source
>
> In combination with the proposed new property this provides all
> information necessary to trace back the origin of a violation.
>
>
>>
>> sh:message can already be used for this purpose.  It does not identify
>> which
>> part of a property constraint was violated but if anyone cares the
>> property
>> constraint can be split up into several property constraints, each which a
>> different message.  (This does demonstrate, however, another issue with
>> omnibus property constraints.)
>>
>> So, I don't see any advantage of adding this extra information to
>> validation
>> results.
>>
>
> sh:message is IMHO a weak mechanism - it may even produce a different
> string depending on the selected user's locale.
>
> Holger
>
>
>


-- 
Dimitris Kontokostas
Department of Computer Science, University of Leipzig & DBpedia Association
Projects: http://dbpedia.org, http://http://aligned-project.eu,
http://rdfunit.aksw.org
Homepage:http://aksw.org/DimitrisKontokostas
Research Group: http://aksw.org