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

"Anyway, this will be tested in practice in implementation(s)"

I remain very skeptical about the whole idea of defining how errors should 
be reported. I believe we should define what it takes for a graph instance 
to be valid and leave it to the implementations to decide what to do 
beyond reporting whether a document is valid or not.
--
Arnaud  Le Hors - Senior Technical Staff Member, Open Web Technologies - 
IBM Software Group




From:   Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
To:     Holger Knublauch <holger@topquadrant.com>
Cc:     public-data-shapes-wg <public-data-shapes-wg@w3.org>
Date:   10/06/2015 01:28 PM
Subject:        Re: shapes-ISSUE-96 (Violation IDs): Should the validation 
results  contain stable IDs to indicate the type of violation [SHACL Spec]





On Tue, Oct 6, 2015 at 12:03 PM, Holger Knublauch <holger@topquadrant.com> 
wrote:
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.

I know, but this might need some minor tweaking for nested constraints, 
otherwise it would always be a link to OR/AND/NOT constraint or a blank 
node which will not be useful. If we want to use violation id in these 
cases then we should point to the lowest constraint level. Anyway, this 
will be tested in practice in implementation(s)
 
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.

sh:flag is always combined to sh:pattern and cannot be used alone, as for 
sh:qualifiedMinCount is similar sh:minCount.
Again, I find this feature useful. I am not sure if this should get into 
the core spec or a separate document, we already had problem getting 
consensus for the current reporting vocabulary.

Dimitris


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