Re: ISSUE-95: Template Simplifications

On 10/30/2015 5:21, Peter F. Patel-Schneider wrote:
> 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?

I fully agree it would not be a good practice to tailor a spec towards a 
specific implementation. Yet it is also unnecessary to over-generalize 
support for corner cases (such as blank node shapes) that later make 
implementations much harder. I was struggling to get this working with 
Jena if blank nodes are permitted. I would like to see how other 
implementations solve this issue. I would also like to hear convincing 
use cases where bnodes are needed. Why would anyone write a stand-alone 
Shape that is a bnode? (I certainly can see nested shapes such as 
sh:valueShape as blank nodes, but those don't carry scopes).

Holger

Received on Thursday, 29 October 2015 22:55:38 UTC