Re: Anyone in support of CONSTRUCT constraints?

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