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

Peter,
do you have a different definition we could use?
--
Arnaud  Le Hors - Senior Technical Staff Member, Open Web Technologies - 
IBM Cloud


"Peter F. Patel-Schneider" <pfpschneider@gmail.com> wrote on 06/29/2016 
11:50:11 AM:

> From: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
> To: kcoyle@kcoyle.net, public-data-shapes-wg@w3.org
> Date: 06/29/2016 11:51 AM
> Subject: 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 thecore 
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 
beexpressed
> > 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 ) )) .
> >>     }
> >> }
> >>
> >>
> >>
> >>
> > 
>