Re: Anyone in support of CONSTRUCT constraints?

To be honest, I’d prefer a simpler design where a violation is represented as a set of key-value pairs, with some keys such as “root” and “path” having special meaning.

The current design uses a Constraint Violation Vocabulary to represent them as RDF graphs. That seems unnecessarily complicated to me.

In many use cases, a processor would immediately turn the violation RDF graph back into key-value pairs via a SPARQL SELECT query against the violation RDF graph.

Further advantages of a design where a violation representation consists of key-value pairs:

- For constraints expressed as SPARQL, the each result in the SELECT evaluation is already a set of key-value pairs, so the SELECT query would directly (or with minimal post-processing along the lines of the rules in 13.1.2) return violations in the expected representation.

- A mechanism like “Injecting Annotation Properties into Constraint Violations” would be unnecessary, as the author of the constraint could simply return some extra variables in the SELECT query.

- Test cases might become simpler, as comparing SELECT results is easier than comparing RDF graphs.

Richard



> On 27 Mar 2015, at 01:08, Holger Knublauch <holger@topquadrant.com> wrote:
> 
> On 3/26/2015 18:43, Dimitris Kontokostas wrote:
>> Hi Holger,
>> 
>> I would like to add an additional way to enrich the results of a SPARQL query.
>> Examples are in [1,2] where below a SPARQL query we can request / inject additional data in the results.
>> In RDFUnit I allow only the variable ?resource in the SELECT query (not exactly but sort of) so most cases are already handled by the additional variables you introduced in SHACL.
>> However this approach can compensate some of the expressiveness we loose from CONSTRUCT and can add additional metadata in the results e.g. what is missing in [3] or anything the user wants.
> 
> Thanks, this makes sense to me. It provides flexibility for example to have constraint violations that hint at a fix suggestion and provides a natural extension point for features that are not yet standardized - who can anticipate what people will use SHACL for!
> 
> I have included a draft for this feature:
> 
> http://w3c.github.io/data-shapes/shacl/#sparql-constraints-annotations
> 
> Please let me know what you think. We can obviously marry this with a string templating mechanism later, once have reached that part :)
> 
>> 
>> Regarding one of the problems in SELECT queries you mentioned
>> `-multiple result values in the same sh:Error (e.g. multiple sh:value)`
>> I think SELECT gives us more freedom to do what we want. In RDFUnit I group multiple values in the same violation  (along with all other requested metadata) by post-processing the results.
>> I am not sure if we all agree if multiple sh:value should be in the same error or not (I think they should be grouped) but we can specify the behavior we want later on.
> 
> My current draft assumes that there is at most one sh:path and at most one sh:value per violation. This assumes simplicity, which may not be sufficient on the long term, yet simplify adoption by tools that display those violations. For example if someone double-clicks on a constraint violation, the system would focus exactly one input field. As you say we can change this later, once we are more confident about that trade-off.
> 
> Thanks,
> Holger
> 
> Diff: https://github.com/w3c/data-shapes/commit/15623ec9a160e9c7e190ac9416a26fa0a3eb6229

Received on Friday, 27 March 2015 10:58:07 UTC