Re: on removing pre-binding from the core of SHACL

Argh.  I should know better than to make a general statement without checking
all the various cases.

Some of the ASK-based core SPARQL constraint components cannot be handled
using the mechanism I initially outlined because there is no BGP for the
SPARQL processor to work with.  These constraint components need a different
approach along the lines of:

A value node V validates for sh:DatatypeConstraintComponent with value D for
parameter sh:datatype precisely when the SPARQL expression
   DATATYPE($v) = $d
evaluates to true with $v bound to V and $d bound to D.

I think that this approach can be used on the ASK-based constraint components
that can't be handled using my initial approach.

peter


On 11/11/2016 07:27 PM, Peter F. Patel-Schneider wrote:
> The specification of the core of SHACL uses a non-standard mechanism, namely
> pre-binding.
> 
> 
> For example class targets are specified as:
> 
> 
> The following SPARQL query specifies the semantics of class targets. The
> variable targetClass is assumed to be pre-bound to the given value of
> sh:targetClass.
> 
> SELECT DISTINCT ?this    # ?this is the focus node
> WHERE {
>   ?this rdf:type/rdfs:subClassOf* $targetClass .    # $targetClass is
> pre-bound to ex:Person
> }
> 
> 
> (Note that this wording needs to be significantly changed, as it currently
> doesn't actually talk about how the query determines targets.)
> 
> 
> The use of pre-binding is unnecessary here.  All that is required to remove
> this use is to say instead:
> 
> 
> The following SPARQL query specifies the semantics of class targets.  When
> validating a data graph the set of targets for a value V of sh:targetClass
> on a shape is the set of RDF nodes containing precisely the mappings of the
> SPARQL variable target in the solution sets of the following SPARQL query
> on the data graph that map the SPARQL variable targetClass to V.
> 
> SELECT ?target $targetClass
> WHERE {
>   ?this rdf:type/rdfs:subClassOf* $targetClass .
> }
> 
> 
> 
> Pre-binding can be eliminated from constraint components that currently use
> ASK queries via the following wording:
> 
> A value node V validates for sh:ClassConstraintComponent with value C for
> parameter sh:class in a constraint if the following query returns a solution
> mapping that maps the SPARQL variable value to V and the SPARQL variable
> class to C.
> 
> SELECT $value $class {
>  $value rdf:type/rdfs:subClassOf* $class .
> }
> 
> This can also serve as the start of removing the dependency of core SPARQL
> on full SPARQL.  What else is required is a SPARQL specification of how
> value nodes are determined along the lines the following for path-based
> property constraints.
> 
> The set of value nodes for a focus node F for a property constraint with
> path P is the set of RDF nodes containing precisely the mappings of the
> SPARQL variable value in solution mappings of the following SPARQL query
> after path substition that map the SPARQL variable this to F.
> 
> SELECT $this $value
> WHERE {
>   ?this $PATH ?value .
> }
> 
> 
> Other constraint components require more changes from the current document.
> Here is wording for sh:MinCountConstraintComponent.  I think queries and
> wording for all core constraint components can be devised.
> 
> A focus node F validates for sh:MinCountConstraintComponent with value m for
> parameter sh:minCount in a constraint if the following query after path
> substitution returns a solution mapping that maps the SPARQL variable this
> to F and the SPARQL variable count to a value no smaller than m, unless m is
> less than or equal to 0 in which case every focus node validates.
> 
> SELECT $this ( COUNT ( DISTINCT ?value ) AS ?count )
> WHERE {
>   $this $PATH ?value .
> }
> GROUP BY $this
> 
> 
> I believe that pre-binding can be completely removed from the specification of
> the core of SHACL.
> 
> 
> Peter F. Patel-Schneider
> Nuance Communications
>

Received on Saturday, 12 November 2016 06:39:14 UTC