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

>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 15:50:46 UTC