Re: Boierplate macro (Was: Re: ISSUE-139: single implementations of all core constraint components)

On 15/06/2016 15:34, Dimitris Kontokostas wrote:
>
>
> On Wed, Jun 15, 2016 at 1:57 AM, Holger Knublauch 
> <holger@topquadrant.com <mailto:holger@topquadrant.com>> wrote:
>
>     I am not keen on macros - people should still be able to
>     understand what's happening, and have valid SPARQL queries in
>     front of them. However, since the introduction of path constraints
>     we are already in the code injection business anyway, so we could
>     just as well do it right.
>
>     The boilerplate solution is basically a generalization of the
>     templates used for ASK queries. We all share the goal of reusing
>     code. At the same time, I am against limiting what people can
>     express because the framework would only support certain patterns.
>     For example there are cases where queries need to iterate over the
>     same value set twice (comparing values), or to do existential
>     checks instead of allValues iteration, see sh:hasValue.
>
>     With all this said, here is what I believe may work well. I have
>     not tried this out yet, so I may be missing something.
>
>     As placeholder for the path, let's use a special variable $path
>     that can only be used as predicate of triple patterns. Depending
>     on the context, the engine would replace those triple patterns
>     with suitable code. For node constraints, this path is interpreted
>     as "the empty path starting at the focus node, i.e. the focus node
>     itself".
>
>     The standard placeholder line would be
>
>         $this $path ?value .
>
>     which for example would be replaced with
>
>         $this ex:parent ?value .   (property)
>         ?value ex:parent $this .   (inv property)
>         $this ex:parent/ex:parent ?value   . (path)
>         BIND ($this AS ?value) .     (node constraint)
>
>
> What would be fine for me is
>
>     $this ex:parent ?value .   (property)
>     $this ^ex:parent ?value .   (inv property)

What do you see as advantage of generating this ^ compared to the triple 
pattern from my email?

>     $this ex:parent/ex:parent ?value   . (path)
>
> which could be an extension of pre-binding (and possibly rename 
> pre-binding to something more fitting)
> Maybe this should be accompanied with related syntax changes as well

This topic is orthogonal to pre-binding. The code changes get injected 
into the SPARQL string before execution. The constraint parameters would 
still get pre-bound.

>
>     BIND ($this AS ?value) .     (node constraint)
>
> this get's too complicated imho

We don't need to spell those details out for node constraints, because 
each implementation may handle them differently. We just need to 
describe what the outcome would be equivalent to.

Holger