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

-----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.


>> 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.

> 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.

> 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.


>> 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.
 I do not see that the translation approach excludes other languages like
JavaScript any more or less than an approach based on sh:hasShape.

>> 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.

> 
> Thanks, Holger


peter

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJVeNfmAAoJECjN6+QThfjzOh0H/2hdLeA0vncUQFJj1LNHp6bk
RnydX6kcYsr4Spab4q3WX6LQn/Cbb8w2UQmZOWAIV+qirwDGzWIPiGxmWy6OXy8a
/LsiJsv/p1u54lRKWa6rVOOUZzj5wZmxKrrk+iCa6D4MfYFFyZ5usIULPWkJs6PX
cgXNr6YsHp48ASqQwtahWRnaIeq/ljd1UY/iPeD/OyA2AfLJ4GedfBxDGov9vRs3
DFUGeMx4jx5l+S/PXB1endjl0hrBi5hTRqYlGAP86zxS4G0WE/veZN181h1XpWrB
Cd85qwbYl1FSf1V/KOFbawNpa6jGZ5tXUNSUM+E6apnYsseeQ/FufO1cGzmM1xI=
=elSd
-----END PGP SIGNATURE-----

Received on Thursday, 11 June 2015 00:36:25 UTC