Re: shapes-ISSUE-63 (sh:hasShape): Nested shapes: sh:hasShape function versus recursive SPARQL code generation [SHACL Spec]

On 6/11/2015 10:35, Peter F. Patel-Schneider wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
>
>
> On 06/10/2015 04:40 PM, Holger Knublauch wrote:
>> On 6/11/15 3:07 AM, Peter Patel-Schneider wrote:
>>> It may have been convenient to use sh:hasShape for or, Xor, and not,
>>> but the results are not correct, as violations are not correctly
>>> defined.
>> Are you referring to the fact that recursion is not specified yet, or in
>> what other cases are results not correct?
> Using sh:hasShape here produces incorrect results for violations.

I still don't understand what you mean. Can you give an example (apart 
from recursion)?

>
>
>>> sh:hasShape may have uses outside of SHACL, but that can only be a
>>> minor point here.
>>>
>>>
>>> I'm not against extension functions, so long as there is a clear,
>>> clean, and consistent definition for them.
>> That sounds good. We can at least address that.
>>
>>>
>>> As far translating SHACL shapes to single SPARQL queries, I claim that
>>> https://www.w3.org/2014/data-shapes/wiki/Shacl-sparql provides such an
>>> approach.
>> You can claim whatever you like, but since your approach isn't
>> well-defined
> What parts of https://www.w3.org/2014/data-shapes/wiki/Shacl-sparql are not
> well defined?
>
>> we have no way of proving you wrong. Your document conveniently glances
>> over some details with "... add other kinds of SHACL Shape Nodes here as
>> needed ..."
> I believe that I have included adequate examples to cover a variety of
> cases, and show how other kinds of RDF-encoded shapes could be handled.  As
> RDF-encoded shapes do not add any expressive power, the only reason to add
> them is as a convenience to users.  In any case, not having a particular
> RDF-encoded shape does not have any bearing on the well-definedness of the
> proposal.
>
>> ignoring templates,
> Templates also do not add any expressive power and not having templates does
> not have any bearing on the well-definedness of the proposal.
>
>> ignoring the complications of variable scoping in SPARQL (e.g. with
>> sub-selects),
> I am not aware of any problems arising from variable scoping.

For example, your

FILTER { SELECT ?this WHERE { ?this <path> ?V } GROUP BY ?this
   HAVING ( COUNT (DISTINCT ?V) = <cardinality> ) }


doesn't work because the inner SELECT will use new bindings for ?this - 
it's evaluated from the inside out. Beside, the FILTER syntax isn't 
valid at all.

>
>> ignoring the problem of how to avoid variable clashes when SPARQL
>> snippets are pasted together,
> For RDF-encoded shapes, this is handled by the well-known device of
> requiring fresh variables.  Writers of raw SPARQL are expected to know
> enough to use snippets that behave correctly.
>
>> ignoring how to specify things like Xor (which together with qualified
>> cardinality restrictions may be very problematic),
> I am not aware of any issue with respect to XOR and qualified cardinality
> restrictions.

Your approach outlines how to map AND and OR (UNION), so how would you 
do Xor and QCRs?

>
>> ignoring how to produce violation messages etc.
> The proposal is quite explicit that it defines violations only so far as the
> results of the SPARQL query.   I do not see how this makes the proposal not
> be well-defined.

It may be well-defined but fails to address the approved requirements on 
error reporting.

>
>
>>> The translation approach has the distinct advantage that the query
>>> optimization techniques in existing SPARQL engines can be directly
>>> applied to the resultant query.  An approach using a SPARQL extension
>>> function will need special support.
>> Any translation approach would also require special support, only that
>> it shifts the workload to the SHACL engine, vastly complicates the spec,
>> and completely excludes other languages like JavaScript.
> The translation approach requires a SHACL engine to translate from SHACL to
> SPARQL.  I do not think that this requires significantly more effort than
> the SPARQL construction required in an approach based on sh:hasShape.  I do
> not see that the spec is any more complex than a spec based on sh:hasShape.

This may be hard to measure and boils down to a matter of taste. We can 
agree to disagree here.

>   I do not see that the translation approach excludes other languages like
> JavaScript any more or less than an approach based on sh:hasShape.

This is important for the upcoming meeting. Your whole specification 
assumes that SPARQL is the only execution language. My design is more 
general, and defines its Operations as language neutral algorithms. 
Applied to sh:hasShape, this means that we can even mix and match 
languages, e.g. use JavaScript-based features (to make web requests etc) 
as part of an otherwise SPARQL-based shape. It also means that we can 
rely on sh:hasShape for the definitions of the logical operators such as 
AND and OR, following our resolution to use SPARQL as much as possible.

>
>>> However, the biggest problem with sh:hasValue is that it makes the
>>> current SHACL spec ill-formed.
>> Again, due to recursion?
> The examples do involve recursion, yes.

So, assuming we agree on a resolution to recursion (which should be 
doable), then the function is no longer ill-formed, and your concerns 
may be addressed. You may still prefer to rely on a translation 
approach, but I see no strong reasons for this preferences. In fact I 
believe you are mixing up specification and optimization. We are just 
writing a spec here; whether an implementation wants to produce a single 
or multiple queries shouldn't matter. We are unnecessarily getting into 
some low-level issues with SPARQL.

Holger

Received on Thursday, 11 June 2015 01:00:57 UTC