- From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
- Date: Thu, 29 Oct 2015 12:21:32 -0700
- To: Holger Knublauch <holger@topquadrant.com>, public-data-shapes-wg@w3.org
On 10/28/2015 10:29 PM, Holger Knublauch wrote: > On 10/29/2015 14:14, Peter F. Patel-Schneider wrote: [...] >> 8 >> >> All this is analogous to how constraints work, but with >> the additional restrictions: >> * All subjects of sh:scope triples must be IRIs >> * The arguments of a scope template must not be blank nodes >> -> >> All this is analogous to how constraints work. > > I had introduced those two clauses for a reason, when I implemented the SPARQL > code generation. This is complicating. If the subjects of sh:scope triples are > blank nodes, then it becomes impossible to generate SPARQL code that "points" > at the scope declaration. As far as I remember, the problem was that each > scope essentially becomes a nested SELECT DISTINCT clause. Due to the > inside-out-evaluation policy of SPARQL, it is becomes impossible to pass > pre-bound variables into such clauses, especially not blank nodes (see second > bullet item above). So my work-around was to rely on property functions (magic > properties) that I defined for Jena to produce the bindings, passing in the > scope shape as a URI. > > Do you have examples where scope template arguments must be blank nodes? Do > you have arguments for blank nodes as subjects of sh:scope? Although I could > understand why conceptually such things should not matter, I believe allowing > either will vastly complicate the implementation of this feature. It would be > good to have a second implementation look into this problem space to confirm > or reject the problems that I have encountered. If someone has a better > solution then I am happy to change my view point. Meanwhile, I'd suggest to > stay conservative with an approach that is better under control. It appears to me that these two requirements come from a particular implementation - one that requires access to the shape graph at validation time. There are other implementation possibilities so why add restrictions to SHACL based on this particular implementation? peter
Received on Thursday, 29 October 2015 19:22:04 UTC