Re: on divergence between textual and SPARQL definitions

Not at all.

First, some of the divergences do not solely relate to problems with EXISTS.
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.

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:36:47 UTC