Re: “SHACL Minus SPARQL”

> On 3 Mar 2015, at 21:49, Peter F. Patel-Schneider <pfpschneider@gmail.com> wrote:
> 
> I would like to see the core of a proposal for something that would support
> "SHACL minus SPARQL" as well as the core of a proposal for "SHACL plus
> SPARQL".
> 
> I think that I could fairly easily put together a proposal for most of the
> former, but I am puzzled as to how to handle recursion and closure, so I
> would like to see how a proponent of this approach would handle recursion or
> closure.  

By closure, do you mean “closed shapes” as described here?
https://www.w3.org/2014/data-shapes/wiki/Requirements#Expressivity:_Closed_Shapes

I’m not sure that this can be easily supported.

One way to do it might be to attach a second bit of SPARQL to each “macro definition”/“shape node”. That bit of SPARQL would CONSTRUCT the triples that are considered to be “covered” by a successful “macro”/“shape” evaluation. A SHACL processor would collect all those triples, and if any triples in the input RDF graph under consideration are not among those “covered”, then the closedness constraint is violated.

Personally I’m not fully convinced that this requirement is a good idea and necessary for SHACL 1.0, and there are many cases where I don’t know what the desired behaviour would be. I’d be quite comfortable with postponing this to a future version of SHACL.

My thoughts on recursion are too muddled to be of much help.

Best,
Richard



> My recent proposal is, I think, along the line of "SHACL minus
> SPARQL", but it supports neither recursion nor closure.
> 
> I'm less certain how the "SHACL plus SPARQL" would work.  It seems to me
> that a vital part of "SHACL plus SPARQL" would be a proof that the core
> formalism is equivalent to some subset of SPARQL.  If this is the case, then
> why not turn things around and make SPARQL the spec and have the other
> semantics proved equivalent to SPARQL constructs?  I am also puzzled as to
> how recursion and closure can be handled in this approach.
> 
> peter
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> 
> iQEcBAEBAgAGBQJU9ix0AAoJECjN6+QThfjzMxAH/iZ2Tl0XtrAPqxWBB6OhRIQ+
> IdebmmfrLf4wZQH2kMZkAydoM9jAKFQWhqFy7znSelOHcbpMHP56uvq1fzVZloQA
> nHa4rgDTC6B0nqJhpreVbO0znOArXzYmYZdBewdg1z/JX8cYr65pnI/o1bd1PgS6
> Uugf10l7Rsknomto76Th9JHPZg67IL+mSJ4POqxvYwzn88NDHrZyJ7p6mnzwVpQj
> LjrKnZ6TsJMAd2VGRpR6b5zGy1+tSxMSZpldqcGKl9dfy4aTmzxs0l2faZ77Jerg
> UZnO+wp+XsiAD/dHqqgDMhYtA+XyfF43MQYHImpSyCFHPcpQ/0W1muceiwESxTA=
> =uY+4
> -----END PGP SIGNATURE-----
>

Received on Wednesday, 4 March 2015 14:38:12 UTC