Re: on divergence between textual and SPARQL definitions

On 12/12/2016 10:36, Peter F. Patel-Schneider wrote:
> Not at all.
>
> First, some of the divergences do not solely relate to problems with EXISTS.

Which ones?

> There are also problems with pre-binding as detailed in the original message
> in this thread.  These problems affect every ASK-based constraint component as
> well as every target and constraint component that uses a pre-bound variable
> in a BGP.  I think that this covers every SPARQL definition in Sections 2 and
> 4 except the one for sh:targetNode.
>
> Second, the problems that the current definition of EXISTS causes are
> inadequately recorded.

Which ones?

Holger



>
> peter
>
>
> On 12/11/2016 03:05 PM, Holger Knublauch wrote:
>> So this whole thread is simply a variation of ISSUE-170 which is already
>> recorded.
>>
>> If, for some reason, the SPARQL EXISTS semantics are not clarified during the
>> life time of the SHACL WG, we have the option to
>>
>> a) remove the SPARQL definitions that explicitly use EXISTS in their WHERE
>> clause (others only have a textual definition too)
>> b) decouple the evaluation of ASK-based definitions from the SELECT ... NOT
>> EXISTS ... templates of 6.4.2
>>
>> Both changes look like straight-forward fallback plans to me.
>>
>> Holger
>>
>>
>> On 12/12/2016 5:14, Peter F. Patel-Schneider wrote:
>>> sh:in is another example
>>>
>>> Any place where a variable binding that could be to a blank node is carried
>>> into an EXISTS and the variable is used in a BGP is a problem.  But all uses
>>> of EXISTS have to be carefully examined as there are other problems with
>>> EXISTS.
>>>
>>> peter
>>>
>>>
>>>
>>>
>>> From: Holger Knublauch <holger@topquadrant.com>
>>> Date: Sat, 10 Dec 2016 11:02:54 +1000
>>> To: "public-rdf-sha." <public-rdf-shapes@w3.org>
>>> Message-ID: <3cd4b9fb-fcfe-6ee7-c314-e3c6dc64c99b@topquadrant.com>
>>>
>>> Peter, you stated there are several places but only enumerated one
>>> (sh:class). Are the others also only about the EXISTS issue?
>>>
>>> Holger
>>>
>>>
>>> On 9/12/2016 12:46, Peter F. Patel-Schneider wrote:
>>>> There are several places where the textual definition of validation differs
>>>> from the SPARQL definition.
>>>>
>>>>
>>>> Consider, for example the shapes graph
>>>>
>>>> se:s1 rdf:type sh:Shape ;
>>>>     sh:targetNode ex:n ;
>>>>     sh:property [ sh:predicate ex:p ;
>>>>                   sh:class ex:c ] .
>>>>
>>>> and the data graph
>>>>
>>>> ex:n ex:p ex:m .
>>>> ex:m rdf:type ex:c ;
>>>>      ex:p ex:l .
>>>>
>>>>
>>>> According to the textual definition of sh:ClassConstraintComponent this data
>>>> graph conforms to this shapes graph as no validation result is produced for
>>>> ex:n because its sole value for ex:p is a SHACL instance of ex:c in the data
>>>> graph.
>>>>
>>>>
>>>> The SPARQL definition here uses the following SPARQL query
>>>>
>>>> SELECT DISTINCT $this ?value
>>>> WHERE {
>>>>      $this ex:p ?value .
>>>>      FILTER NOT EXISTS
>>>>        { $value rdf:type/rdfs:subClassOf* $class . }
>>>>      }
>>>>
>>>> with this pre-bound to ex:n and class pre-bound to ex:c.
>>>>
>>>> According to the SHACL document
>>>> evaluating this SPARQL query will produce a non-empty solution sequence,
>>>> namely
>>>>      { { (this, ex:m), (value,ex:l) } }
>>>> because
>>>>      $this ex:p ?value .
>>>> will produce the set of solutions
>>>>      { { (this, ex:n), (value,ex:m) } ,
>>>>        { (this, ex:m), (value,ex:l) } }
>>>>
>>>> Therefore according to the SPARQL definition of sh:ClassConstraintComponent
>>>> this data graph does not conform to this shapes graph.
>>>>
>>>>
>>>>>>>>>>>>>>>>>>>>>> ISSUE<<<<<<<<<<<<<<<<<<<<<<<<
>>>> The textual and SPARQL definitions conflict in several places.  One or the
>>>> other needs to be fixed or dropped.
>>>>>>>>>>>>>>>>>>>>>> ISSUE<<<<<<<<<<<<<<<<<<<<<<<<

Received on Monday, 12 December 2016 00:57:34 UTC