Re: update to SHACL-SPARQL (ISSUE-62)

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



On 05/31/2015 11:12 PM, Holger Knublauch wrote:
> On 5/31/2015 0:26, Peter F. Patel-Schneider wrote:
>> -----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.
> 
> The latter is basically what I suggest too, only that I would make this
> fact more explicit. In my suggested design, people would associate their
> shapes with rdfs:Resource to state that they apply to all resources. (We
> can discuss whether this means everything with an rdf:type statement or
> every subject in the graph, but that doesn't matter too much). This
> ensures that ?this will always be bound, but doesn't prescribe how an
> engine implements this: if the constraint already binding then it doesn't
> need to add the ?this a rdfs:Resource clause prior to execution, leading
> to exactly the same situation as in your approach.

Using rdfs:Resource either requires a dependence on RDFS reasoning or a
special case for this class.  I'm fine with the former, but that might not
go well with the working group.  I'm not fine with the latter.

> However, I believe my approach is cleaner because it handles every case 
> consistently, without having to specify some algorithms that explain in
> detail how to determine whether a SPARQL query is already binding, and
> how to inject a binding clause otherwise. It is also more consistent for
> the case when you invoke the engine to validate a single resource - it
> would simply walk up the class hierarchy to collect all relevant
> constraints and wouldn't need to look into some global constraint objects
> outside of the tree.

As I indicate above, I don't view this approach as clean, unless you depend
on RDFS reasoning.   Without RDFS reasoning or having a special case for
rdfs:Resource, even if you use the approach of walking up rdfs:subClassOf
links you will only get classes that have an explicit ancestor of
rdfs:Resource and nodes that have an rdf:type link.

> Overall I really wonder what use cases would not be covered by my design
> but yours... We had discussed before that other communities may define
> their own shape selectors anyway.

All scoping can be done inside global constraints, so there is no need for
scoping by expression.  The differences then are mostly stylistic---if you
want a constraint on nodes that have a filler of :verified for :status, do
you want to do

[ rdf:type sh:Shape;
  sh:scope [ sh:property :status ;
             sh:hasValue :verified ] ;
  sh:constraint ... ]

or

[ rdf:type sh:Shape;
  sh:classScope rdfs:Resource ;
  sh:constraint [sh:or ( [ sh:not [ sh:property :status ;
                                    sh:hasValue :verified ] ]
                          ... ) ] ]


> Holger

peter

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

iQEcBAEBCAAGBQJVbD58AAoJECjN6+QThfjzthYIAMPf0tiYGIxgu6BezzhU95GL
8SISC4wPGn/BD2sn9bZb0pyYWm4BxmI1VdrpePeIlXXQw1MgJFNNCQSP4IPDCLOH
JGTVkjS1pZIV3EXbJnvbFao5gD/nl7yZ+6k34f1xfNLYNdJk5JbuMMh+BtC/g6ei
JAAPjsIckw3HnGs/7vbtywWo/5V5ufB4tnQAjgEyXI3IXLdlFyYQG0+yWawq3E+W
gNrL9BYUgoHL2ONC1JbkP3sSdhCZjtU7BhyWnBOJDm6NBnDDUycE4kAFF9TQla4B
4KzJRybwYaLREeEx5Bn7eKxi8sGJBhI9h1liz9x/WjxCQpGsVsm2cBRmB1vhOaU=
=uYe9
-----END PGP SIGNATURE-----

Received on Monday, 1 June 2015 11:14:43 UTC