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

For nodeKind?  I think that just eliminating
EXISTS { FILTER and }
does the trick, but maybe there is something that I can't see.

peter



On 06/29/2016 09:22 AM, Arnaud Le Hors wrote:
> 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 ) )) .
>> >>     }
>> >> }
>> >>
>> >>
>> >>
>> >>
>> >
>>
>

Received on Wednesday, 29 June 2016 16:56:21 UTC