Re: update to SHACL-SPARQL

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

To make selection by expression work well, the translations to SPARQL need
to be adjusted to make most of them binding.  I have done so for
https://www.w3.org/2014/data-shapes/wiki/Shacl-sparql

As I also state in https://www.w3.org/2014/data-shapes/wiki/Shacl-sparql it
is possible to do away with the need for binding by adding some SPARQL that
binds against all nodes in an RDF graph.

peter


On 05/29/2015 09:18 PM, Holger Knublauch wrote:
> Hi Peter,
> 
> this topic is related to a parallel thread on the Requirements list
> 
> https://www.w3.org/2014/data-shapes/wiki/Requirements#Selection_by_expressio
n
>
>  but I find it hard to track these Requirement pages, and there is not
> enough space there, so I have raised a proper ISSUE on the underlying
> topic:
> 
> https://www.w3.org/2014/data-shapes/track/issues/62
> 
> On your specific solution I don't think your suggestion works in general,
> and we would cause an unnecessary and hard-to-explain limitation on the
> type of Shapes that people can use. You state that most SHACL conditions
> will be binding. This may be true, but there are plenty that are not
> binding. See for example the definition of sh:hasValue [1]:
> 
> SELECT ?this (?this AS ?subject) ?predicate WHERE { FILTER NOT EXISTS { 
> ?this ?predicate ?hasValue } }
> 
> or the simple use case to iterate over all resources from a given
> namespace:
> 
> FILTER STRSTARTS(STR(?this), "http://mynamespace/"))
> 
> Basically anything that only consists of a FILTER would be in this
> category. We can control this in the core language, but not for general
> SPARQL constraints.
> 
> In the ISSUE above I suggest to at least enforce ?this rdf:type
> rdfs:Resource, which may be similar to what you propose below. I believe
> this should cover the relevant use cases in a cleaner and more consistent
> way, without limiting SPARQL or shapes expressivity.
> 
> Thanks, Holger
> 
> [1] 
> http://w3c.github.io/data-shapes/shacl/#sparql-AbstractHasValuePropertyConst
raint
>
> 
> 
> On 5/23/2015 0:09, Peter F. Patel-Schneider wrote: At the VF2F Holger
> pointed out a couple of problems with my proposal.
> 
> To address these, I added a requirement that constraints be binding and 
> modified some of the translations to make more constraints be binding.
> I also emphasized that some of the translations are inefficient and that
> the translations are only a specification.
> 
> 
> 
> An example of a non-binding constraint is
> 
> NBC sh:shapeScope [ sh:property ex:p; sh:maxCardinality 1 ]; sh:shape [
> sh:property ex:q ; sh:minCardinality 1 ] .
> 
> Translation of this constraint into SPARQL would normally result a query 
> where there was nothing to make bindings to return.  The solution to the 
> problem in Stardog ICV is to add in a pattern like
> 
> ?this rdf:type rdfs:Resource .
> 
> It probably is not a good idea to count on SPARQL implementations, even
> ones that do RDFS inferencing, to make this kind of inference so I
> instead make the requirement that SHACL conditions be binding.  I expect
> that nearly all potential SHACL conditions will be binding, so I don't
> think that this is much of a limitation on SHACL.
> 
> 
> 
> 
> peter
> 
>> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJVach4AAoJECjN6+QThfjzORwIAJu05y3M+R6q2QTKfegiSQKt
k9Jc0W3iNBCI8y51iDn+TZDRoKmogn3byohqxSjfnyA/LRgPCjwKZP2OIgZ0VTYJ
SJOAVBjlqwfyfKUWxGPmGXV4fYAJIev67JZ8B/7aekC2hi/43PsqAWSIukCJQgN1
vE4zttqxY6dgBrvUv77ngwglN9xpdZJ8OqEra9gWtRjUvgEtoB0bXNmyzCVOaK+v
XyTVGVIefWRWFNyEOUo12rc+gYPOyYuweEVMfHj5RRbOFcDn46K0sBNuPsGY9Ylw
bqSfHEUvsfqyUB6Sunh9HDKBHa502CKcE9/6zwPKyuqhSscUAYoovrhzBEslSKU=
=XH33
-----END PGP SIGNATURE-----

Received on Saturday, 30 May 2015 14:26:30 UTC