- From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
- Date: Sun, 14 Jun 2015 22:42:09 -0700
- To: Holger Knublauch <holger@topquadrant.com>, public-data-shapes-wg@w3.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 06/13/2015 09:40 PM, Holger Knublauch wrote: > On 6/12/2015 13:37, Peter F. Patel-Schneider wrote: >> Changing the order of triples in a shapes or data graph document, or >> even just running the system again, might end up producing different >> answers if care is not taken in fleshing out this approach, even in >> cases where there is no negation or even disjunction. > > Does anyone have a test case that demonstrates such a non-deterministic > scenario? AND, OR and XOR all use rdf:Lists and are therefore ordered. > sh:valueShape needs to walk through all values of the property, so order > shouldn't matter there either. (Apologies if the answer to these > questions is already somewhere on the mailing list - I found this topic > hard to follow) 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. >> Picking a bad propagation rule for a "Duh" is going to produce >> something that I think will be unusable---I don't even know if there is >> any good set of propagation rules. > > Maybe it would help if we made sh:hasShape return three possible values: > true, false and unknown. Then the writers of custom SPARQL queries can > better specify how they are going to treat the undefined cases. I believe > we need the "unknown" value anyway, e.g. when a JavaScript implementation > encounters a SPARQL query that it cannot handle. What are the propagation rules for unknown? Should there be multiple unknowns? Should there also be an error value? > Thanks, Holger peter -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVfmWxAAoJECjN6+QThfjzt8UH/RZzkGkscZyy8Sm4gkqE56uH Mu8hbCTC9zM2P0qpe2+17eKwWvOL11kx0cVKodlrwvjo38lN7k39V5JY1bKxyvYU tlqf6+BgldQ5qgNi0t3sNoysjjOuazS7wddb44JLARj8avXnJN/s4/WW8CwRdIHa iUIiUxBLWAtPx2gQd1rYy3ANj29OV8u063PCapEaHZ8HGhtXyTv1N0p6tWzHEiY/ +X7DHIaMOuPMhdsbK+uDRZiNERDgN9y8Id6sFpyUiNNc6n6C+1L9KfFOAXVgbDfR 0Zu6u8OJqzn0oO9acXTGvibrTkZGWT7jE41rEBuqsyPpGBj3xThwyPNvajK3MKY= =mREe -----END PGP SIGNATURE-----
Received on Monday, 15 June 2015 05:42:43 UTC