Re: on divergence between textual and SPARQL definitions

On 12/11/2016 04:57 PM, Holger Knublauch wrote:
> 
> 
> 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?

The ones I descibe just below.

>> 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?

All of them.

> 
> 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 02:01:54 UTC