- From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
- Date: Wed, 04 Mar 2015 07:21:26 -0800
- To: Richard Cyganiak <richard@cyganiak.de>
- CC: "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yes, I mean closed shapes, i.e., all triples in a graph (or around a node) have to be somehow consumed by the shape. I don't think that your idea of constructing the matched triples will work in the presence of disjunction, at least without considerable code embedded into the SPARQL engine. peter On 03/04/2015 06:37 AM, Richard Cyganiak wrote: > >> 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 > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJU9yL2AAoJECjN6+QThfjzpCoH/0IqTnt8+4VL9f8Rbf/cyUhx dNWWS8Wn5snRN6cCJaZeLI4dQt/fa15jlG3/V2y+bZZQTWPnhBGBzr4Ti0g7rZP5 KVDsnMflcCEU07yMjfvkXTPngvHwSUqdcwDu3pQ9hyYvSgE4SbY8Gp4aaFb8e7Sc FNUqd8u5SSE9XHf7zXGWW+9CBdiYBNSlt9Af3IyS6iuR2Iu8KNjlH4+4H4AApGlp m2O3HogHmEWqwysUpV9GXGYA6miwvXJ3+/ESvf0X2xhrzPXZ2v7LxbYuwtiDW2hl yKQIYPoVsYdFrrjZDsz5Fk2AL87LIxanaxBnw5dkmuRZ6sB47HkvKdNXsmPUpik= =bB9a -----END PGP SIGNATURE-----
Received on Wednesday, 4 March 2015 15:21:58 UTC