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

Thank you, Peter. I think this is the best explanation/documentation 
I've seen on this, and will hang on to it. I still think the spec could 
be made clearer (you seem to be the only one who has understood it thus 
far), but it appears that we aren't yet at "how it works" but still at 
"does it work?"

The logical question from these remarks of yours is: shouldn't this be 
confirmable with testing? I am mindful of the comments of Andy that some 
of this may be often glossed over by individual SPARQL implementations. 
If there is anything here that is not in that category, testing would be 
the way to go, no?


On 6/29/16 12:10 PM, Peter F. Patel-Schneider wrote:
> 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)
>  $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,
>>> **********
>>> 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]
>>>>> 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 ((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 ) )) .
>>>>>     }
>>>>> }

Karen Coyle
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600

Received on Thursday, 30 June 2016 17:48:09 UTC