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