- From: Holger Knublauch <holger@topquadrant.com>
- Date: Mon, 15 Jun 2015 17:22:26 +1000
- To: public-data-shapes-wg@w3.org
On 6/15/2015 16:32, Peter F. Patel-Schneider wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 06/14/2015 10:48 PM, Holger Knublauch wrote: >> On 6/15/2015 15:42, Peter F. Patel-Schneider wrote: >>> Changing results without negation and without disjunction requires a >>> (sloppy) short-circuit evaluation on conjunction. Consider a >>> conjunction where othe left branch evaluates to true and the right to >>> error.. If the left branch is evaluated first and short-circuited the >>> result is true. If the right branch is evaluated first then the result >>> is error. >> But we assert that engines must go from left to right (just like with && >> in any programming language), so the second case cannot happen. > Who has so asserted this for SHACL? (It looks as if SPARQL does not enforce > left-to-right evaluation for and and or, and also in other places.) You are right. My draft did not spell out this assumption, and the current implementation in SPARQL using rdf:rest*/rdf:first is not correct because the order of path evaluation results is explicitly undefined in the SPARQL spec. I have added notes to the spec that this is a bug, and that the loop needs to be replaced with a tail-recursive helper function: https://github.com/w3c/data-shapes/commit/651fc4921a0b614596b1069a70c4cba3389e8283 Thanks for pointing this out. (I couldn't find a definite statement whether && and || in SPARQL are ordered, but I assume most users would intuitively expect ordering like in programming languages). > >> Do you have any other example of non-determinism? > With recursion through negation, the order in which objects are selected > during shape recognition can affect results in systems that handle loops by > memoizing, even with only two values. Consider a shape like > S = all R not S > and a graph like > V1 R V2 . > V2 R V1 . > Starting with V1 makes V1 in S and V2 not. > Starting with V2 makes V2 in S and V1 not. > > Examples like this have been discussed already. Wouldn't this problem be resolved by disallowing memoizing? sh:hasShape is our own function that we can define in whatever way we want. Holger > > Turning the different shape results into different constraint violations can > be done using a qualified cardinality restriction applied to a node > connected into several elements in a larger version of this loop. > > [...] > >> HTH Holger > peter > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQEcBAEBCAAGBQJVfnGKAAoJECjN6+QThfjzjooIALCxw3cEY6hM97R6Xs/AJAXb > s+IP6oB4lyQzJ5cEkgwPVUhpRYwQA/30g0Y4h2i0d/gv7EsRxQvun/A+e8tYSA1S > FVbXRB7N5gRMox6uZ3dZxwOdBK7bdL9h8yfL1VJTeK+M5Rr6HLeIPCBc3SunMOzx > NgMR2w7J0tCjLQiIWadCY9MvPlgkjDYcLcLJKDo80YE7ESXlh/wV5MxUHZMNoGQ2 > pQLxyFXITqj8sdFtSLcwrwDLrZMfvrmIkG6yC0iV+vkMXX9erkDv0zrH2B+BCJN+ > I4nOcps2+3eU9j8Av/BEbxbJ9BhULZQmanFF3/NHfa/fSpi90caaL4qzpuPmiuM= > =VZVL > -----END PGP SIGNATURE-----
Received on Monday, 15 June 2015 07:24:45 UTC