- From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
- Date: Wed, 15 Jun 2016 11:27:22 -0700
- To: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>, Holger Knublauch <holger@topquadrant.com>
- Cc: public-data-shapes-wg <public-data-shapes-wg@w3.org>
On 06/15/2016 01:23 AM, Dimitris Kontokostas wrote:
[...]
> 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
[...]
I agree.
As far as I can tell, all core constraint components can be implemented via
single SPARQL queries of the form
SELECT ... WHERE {
[boilerplate]
...
} ...
provided that the boilerplate produces an extra solution mapping where ?this
is bound to the focus node and ?value is unbound. The only two difficult
core constraint components are
sh:equals which can be implemented as
SELECT ?v WHERE {
[boilerplate]
OPTIONAL { $fn $eq ?ve FILTER ( sameTerm(?value,?ve) || NOT bound(?value) ) }
FILTER (BOUND(?value) || BOUND(?ve))
BIND ( IF(BOUND(?value),?value,?ve) AS ?v )
} GROUP BY ?v HAVING ( (COUNT *) = 1 )
sh:hasValue which can be implemented as
SELECT WHERE {
[boilerplate]
FILTER (sameTerm(?value,$hasValue) )
} HAVING ( COUNT * < 1 )
I think that this means that the boilerplate can (and should!) be replaced
by a form of pre-binding that utilizes a set of solution mappings instead of
a single mapping. This would eliminate the need for code generation, even
for paths.
peter
Received on Wednesday, 15 June 2016 18:27:54 UTC