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

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

The issue under discussion is how to handle scopes that are expressions.
This kind of scope appears to be needed to handle certain examples, the bug
example where a scope could be "all nodes that have a value of :reported for
property :status".

At first glance there does not appear to be any problem with such scopes.
In a SPARQL solution you would just turn the scope into a bit of SPARQL,
perhaps something like
  ?this :status :reported .

However, some expressions turn into SPARQL that doesn't "bind".  (SPARQL
requires binding so that it doesn't interate over the entire universe -
whether the requirement makes sense for SPARQL is out of scope here.)
For example, you might want to have a scope something like "all nodes that
have no value for property :status".  This turns into something like
  FILTER NOT EXISTS ( ?this :status ?that )
which is not binding.

What should be done for such scoping expressions?

My initial solution was to forbid them.  If anyone wanted to use such a
scope they would have to do something themselves to provide a binding.
I also proposed a solution where a SHACL processor would automatically add
in extra SPARQL to provide a binding that would in essence iterate over all
nodes in the graph.

Holger prefers requiring that expressions not be allowed to be scopes by
themselves but that they can only be used in conjunction with a class scope.
This works well when there is a class that can be so used, as in

ex:MyShape
    sh:scopeClass :Bug ;
    sh:filterShape [
        sh:property [ sh:predicate :status;
        sh:hasValue :reported ]
    ] ;
    sh:constraint ....

However, when there is no such class he would use rdfs:Resource as the
"universal" class, as in

ex:MyShape
    sh:scopeClass rdfs:Resource ;
    sh:filterShape [
        sh:property [ sh:predicate :status;
        sh:hasValue :reported ]
    ] ;
    sh:constraint ....

That's still fine, except that to work correctly it requires RDFS inference.
Otherwise rdfs:Resource is just another class, and one that need not appear
at all an RDF graph that contains classes.

Holger would get around this by adding a special case for rdfs:Resource,
essentially adding in part of the RDFS semantics for this class.  I don't
view this as a viable solution.  If rdfs:Resource is going to be used for
this purpose then it should have its full RDFS meaning.  (Of course, if RDFS
reasoning is going to be required for SHACL then rdfs:Resource will have its
RDFS meaning.)


My current preferred solution is to allow expresions as scopes and to
require that SHACL engines add in a binding expression when needed.  This
would allow for shapes like

ex:MyShape
    sh:scope [
        sh:property [ sh:predicate :status;
        sh:cardinality 0 ]
    ] ;
    sh:constraint ....

This is independent of whether RDFS reasoning is going to be required for
SHACL.  If RDFS reasoning is required, then non-binding scopes can be made
binding by adding in
  ?this rdf:type rdfs:Resource
If RDFS reasoning is not required, then the SPARQL specification would have
to use a more complex binder, but implementations would be free to do
something that is equivalent and maybe more efficient.

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

iQEcBAEBCAAGBQJVbiXDAAoJECjN6+QThfjzK3AH/R3Ix83JAOuMEY7Cr5fKZrtW
rJQ+nxtu9+smzAP2MN9Tuh7+2b8m8bpSAKogSoHBsvYkv1u31bVfM5KE0NOfTk2V
JvxZLCdCS6NHVixe87SW6YS8DNVCsFvPxoPC7RUb9SIipNK3rSaUq0SWAJq/rWea
cclFJ9q5SxGHgWRl8/g4Uhs/AoJPKbgDQGUSjaLZSDfvadLyBkI0l4NicJPM1gdQ
w5uKV7/0f5WaF91qR4X10bEbF/AGtqCbtb8zzYe05o1rfukqMHws6sCU8oc4hyLc
IHhroTBle9j1oA7tYAAtgMaVYIfhlXFtSlLFziMWt/y6SovmpLlSUjK7qf9ckno=
=ubzm
-----END PGP SIGNATURE-----

Received on Tuesday, 2 June 2015 21:53:40 UTC