Re: on divergence between textual and SPARQL definitions

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<<<<<<<<<<<<<<<<<<<<<<<<
>>
>> Peter F. Patel-Schneider
>> Nuance Communications
>>
> Received on Saturday, 10 December 2016 01:03:58 UTC
>
>      This message: [ Message body ]
>      Next message: Holger Knublauch: "Re: on sh:resultPath"
>      Previous message: Peter F. Patel-Schneider: "Re: on divergence between
> textual and SPARQL definitions"
>      In reply to: Peter F. Patel-Schneider: "on divergence between textual and
> SPARQL definitions"
>
>      Mail actions: [ respond to this message ] [ mail a new topic ]
>      Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [
> by author ]
>      Help: [ How to use the archives ] [ Search in the archives ]
>
> This archive was generated by hypermail 2.3.1 : Saturday, 10 December 2016
> 01:03:59 UTC

Received on Sunday, 11 December 2016 23:06:12 UTC