Re: update to SHACL-SPARQL

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_expression

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


On 5/23/2015 0:09, Peter F. Patel-Schneider wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> 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
>
> iQEcBAEBCAAGBQJVXziEAAoJECjN6+QThfjzJoQIAIcY9XsFrKABCaR2Bssi1cMa
> tc0mKmKG/JJgiQyZObe3/SYK3e6j8C3xbG8Cf2NB5pd2Rrn8L90BFDmHR9SsE94s
> Fnd0b1oMWpla8R6kQAvIKbwy+MeR5al6nRV3MCJS2b0CWMjUgk66HI2F0rpRaknF
> P709cZrL3MtZkG62Clu4gEmsy2+kwfdphZ5LIenxabR8H3qCUvm2Zchy8oDPsHY1
> QoH/4NrzZRMvpKyP1sm2UiOM65ccfMeueDKd6Vvvw5RBxzn6hlA/5FM8EIx29agA
> pYec6tou2OL8izzl2DgSikdYDOdIri/3Yn23j/5HTX1uQ0l8R6wk2SqJV6Sy1uY=
> =iT3I
> -----END PGP SIGNATURE-----
>