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

Peter,

your email summarizes the situation well. I hope we can resolve ISSUE-1 
(Inferencing) in the meeting this week so that we can make progress here.

With regards to a question that I raised yesterday, it seems that you 
would also prefer that the system would bind ?this with all resources 
with an rdf:type triple (my option 2), if the query is not binding.

Do you have an algorithm that determines whether an arbitrary SPARQL 
WHERE clause is binding a given variable (?this)?

Thanks,
Holger


On 6/3/2015 7:53, Peter F. Patel-Schneider wrote:
> -----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 Wednesday, 3 June 2015 00:51:34 UTC