Re: shapes-ISSUE-172 (sh:nodeKind SPARQL definition): the sh:nodeKind SPARQL definition is unnecessarily complex [SHACL Spec]

When a SHACL shape is validated against a data graph the first thing that the
definition of SHACL requires is that the scope of the shape is determined.
Then, well actually after filtering, for each node in that scope, well
actually each node that passes all the filters, the constraint components of
the shape are invoked on that node, and with several other parameters also
specified.  This "glue" is specified outside of SPARQL, so there needs to be a
way in the definition of SHACL of getting all these parameters to affect the
SPARQL query that provides the definition of the constraint components.

Otherwise there would be no connection between $this and the current focus
node, or between $predicate and the predicate of the constraint, etc., and a
query like

SELECT $this ($this AS ?subject) $predicate (?value AS ?object)
WHERE {
 $this $predicate ?value .
 FILTER NOT EXISTS { ?value rdf:type/rdfs:subClassOf* $class } .
}

would return far too many results.

All this is definitional (i.e., in the current constitution of SHACL) not
implementational (i.e., in some particular SHACL product).  Although it does
appear to be much too programmatic, this is mostly an illusion.  Of course, a
different definition methodology of SHACL that didn't use SPARQL at all is
possible, but that's not the way that things have turned out.


Is pre-binding necessary for SHACL in its current form?  No, neither
sh:hasShape nor pre-binding is necessary as validation for the current SHACL
language can be done entirely within SPARQL.

Is pre-binding necessary if SHACL is specified using a function like
sh:hasShape?  Probably not, as it should be possible to post-filter the
results of the SPARQL queries.  This would probably be very inefficient and
would require modifications to many of the queries.

Is the particular definition of pre-binding that is used in the current SHACL
specification necessary?  Definitely not, and the current definition may even
be one that is not easy for most SPARQL systems to provide as it uses an
analogue of spooky action at a distance and it appears that most SPARQL
systems implement at least EXISTS (which is very closely related to
pre-binding) without spooky action at a distance even though the SPARQL
definition of EXISTS needs spooky action at a distance.  If the definition of
pre-binding was changed then I think that a few SPARQL queries would have to
be changed.


peter


On 06/29/2016 11:33 AM, Karen Coyle wrote:
> Peter, I absolutely agree with the spirit of this. What I'm less sure about is
> why this would involve binding or pre-binding. To me, pre-binding implies that
> there is data being passed from one programmatic function to another. This is
> a program function, and I don't see it as necessary for the definitional use
> of SPARQL here. Where in the use of SPARQL as a formalism do we have to
> explain how values are passed to SPARQL if SPARQL is being used only to define
> the formalisms of how two graphs are compared? In most formalisms, you give A
> and B and then show the ways that A and B can interact, but you don't have to
> explain where you get A and B from.
> 
> kc
> 
> On 6/29/16 8:50 AM, Peter F. Patel-Schneider wrote:
>>> From Section 1.5 "Relationship between SHACL and SPARQL" of the SHACL
>> specification, http://w3c.github.io/data-shapes/shacl/#shacl-sparql
>>
>> **********
>> This specification uses parts of SPARQL 1.1 in the normative definition of the
>> semantics of the SHACL Core constraints and scopes. However, SPARQL is not
>> required for the implementation of the SHACL Core language.
>>
>> SPARQL variables using $ marker represent external values that must be
>> pre-bound in the SPARQL query before execution.
>> **********
>>
>> So, although it may not be necessary to understand SPARQL to use the core part
>> of SHACL, SPARQL is used to provide the normative definition of parts of
>> SHACL.  This was a working group decision of quite some time ago.  It doesn't
>> mean that core SHACL implementations need to be SPARQL implementations, just
>> that the behaviour of SHACL is given in part by some bits of SPARQL.
>>
>> So in particular, parameterized SPARQL queries provide the meaning of the
>> SHACL core constraint components.  ISSUE-170 is about a problem in SPARQL that
>> affects the meaning of queries that provide the meaning of many of the SHACL
>> core constraint components.  ISSUE-171 is about the SPARQL query that provides
>> the meaning of sh:classIn not corresponding to the intuitive meaning of
>> sh:classIn.  ISSUE-172 is about the SPARQL query that provides the meaning of
>> sh:nodeKind being unnecessarily complex.
>>
>> peter
>>
>>
>>
>> On 06/29/2016 08:27 AM, Karen Coyle wrote:
>>> Replying to all three of Peter's new issues: Are we really talking about
>>> SHACL, or is this about a particular implementation? Could this be expressed
>>> in a way that avoids tying SHACL to specific code? I know that we agreed to
>>> use SPARQL as a formalism, but I'm beginning to doubt that is what we have
>>> here.
>>>
>>> kc
>>>
>>> On 6/29/16 5:39 AM, RDF Data Shapes Working Group Issue Tracker wrote:
>>>> shapes-ISSUE-172 (sh:nodeKind SPARQL definition): the sh:nodeKind SPARQL
>>>> definition is unnecessarily complex [SHACL Spec]
>>>>
>>>> http://www.w3.org/2014/data-shapes/track/issues/172
>>>>
>>>> Raised by: Peter Patel-Schneider
>>>> On product: SHACL Spec
>>>>
>>>> There is no need for EXISTS in
>>>>
>>>> SELECT $this ($this AS ?subject) $predicate (?value AS ?object)
>>>> WHERE {
>>>>     $this $predicate ?value .
>>>>     FILTER NOT EXISTS {
>>>>         FILTER ((isIRI(?value) && $nodeKind IN ( sh:IRI, sh:BlankNodeOrIRI,
>>>> sh:IRIOrLiteral ) ) ||
>>>>                 (isLiteral(?value) && $nodeKind IN ( sh:Literal,
>>>> sh:BlankNodeOrLiteral, sh:IRIOrLiteral ) ) ||
>>>>                 (isBlank(?value)   && $nodeKind IN ( sh:BlankNode,
>>>> sh:BlankNodeOrIRI, sh:BlankNodeOrLiteral ) )) .
>>>>     }
>>>> }
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>

Received on Wednesday, 29 June 2016 19:10:57 UTC