- From: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
- Date: Wed, 15 Jun 2016 11:23:08 +0300
- To: Holger Knublauch <holger@topquadrant.com>
- Cc: public-data-shapes-wg <public-data-shapes-wg@w3.org>
- Message-ID: <CA+u4+a1Vd1sB5JZmoErzkrT86i=Ba1Q02-5m9BFAXrB6D=u9mw@mail.gmail.com>
On Wed, Jun 15, 2016 at 9:56 AM, Holger Knublauch <holger@topquadrant.com> wrote: > > > On 15/06/2016 15:34, Dimitris Kontokostas wrote: > > > > On Wed, Jun 15, 2016 at 1:57 AM, Holger Knublauch <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? > It is completely different in my view, in my case it is just string substitution by replacing $path with the property path generated by the shape definitions what you suggest is changing the sparql query "basic graph patterns". > > $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. > The problem here is that we have $predicate from sh:[Inverse]PropertyConstraint and $path from sh:PathConstraints so $path is a pre-bounded variable like $predicate I think it will complicate things further if we add yet another variable substitution mechanism in SHACL. I believe it is best to merge these two in a single mechanism and (possibly) extend/change pre-binding > > > > 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 > > -- Dimitris Kontokostas Department of Computer Science, University of Leipzig & DBpedia Association Projects: http://dbpedia.org, http://rdfunit.aksw.org, http://aligned-project.eu Homepage: http://aksw.org/DimitrisKontokostas Research Group: AKSW/KILT http://aksw.org/Groups/KILT
Received on Wednesday, 15 June 2016 08:24:04 UTC