- From: Holger Knublauch <holger@topquadrant.com>
- Date: Thu, 16 Jun 2016 09:22:00 +1000
- To: public-data-shapes-wg <public-data-shapes-wg@w3.org>
On 16/06/2016 4:27, Peter F. Patel-Schneider wrote:
> 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.
A solution that would only allow querying the value nodes in the
beginning is not working for me. It would cripple the expressivity too
much and lead to very inefficient queries (e.g. existential checks don't
need to iterate over all values). We need an approach where access to
the path values can happen at any place within the query, and the $path
solution supports that. I see nothing particularly difficult about using
that kind of "magic" property, neither from an implementation
perspective nor for the user.
However I could see that the syntax $path looks too similar to other
pre-bound variables and may therefore confuse readers. We could change
it to $PATH or something more geeky such as %%PATH%% if that makes the
intent clearer. The latter would have the downside that the query string
is no longer valid SPARQL syntax, which may be regarded as an issue or a
feature depending on the viewpoint. Maybe someone has ideas for a better
syntax.
(To be clear, in my proposal neither $path nor $predicate would be
pre-bound variables anymore - pre-binding would be limited to the
parameters, and $this is typically produced by code that loops over all
focus nodes anyway)
Holger
Received on Wednesday, 15 June 2016 23:22:32 UTC