Re: Anyone in support of CONSTRUCT constraints?

On Fri, Mar 27, 2015 at 3:08 AM, 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 :)
>

I like it, Maybe this is a good idea to extend this to the core vocabulary
for constant annotations as well. Something like

sh:property [
  sh:minCount 3
  sh:resultAnnotation [
    sh:annotationFacet sh:minCount
    sh:annotationProperty ex:a
    sh:annotationValue <a constant value or IRI>
]

Possibly, if we skip  sh:annotationFacet this will can to all the
sh:property facets or if it is defined in the shape level to all the shape
facets / sparql queries. But this needs some extra thinking

Having this at the high level vocabulary will make it easy for shape
creators to add error metadata for each possible violation.
It can be used for instance to add tags to violation groups for easier
retrieval or for faceted violation browsing (or link to a spin fix
template).
We started a related project for RDFUnit but didn't have time to finish it


>
>
>
>  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
>



-- 
Dimitris Kontokostas
Department of Computer Science, University of Leipzig
Research Group: http://aksw.org
Homepage:http://aksw.org/DimitrisKontokostas