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

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 ) )) .
>>>     }
>>> }
>>>
>>>
>>>
>>>
>>
>
>

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600

Received on Wednesday, 29 June 2016 18:34:10 UTC