- From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
- Date: Wed, 25 Mar 2015 07:44:10 -0700
- 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 I'm not in favour of this kind of solution. It splits the language in two. It will be hard to describe. It will diminish interoperability. peter On 03/25/2015 07:34 AM, Richard Cyganiak wrote: > >> On 24 Mar 2015, at 15:35, Peter F. Patel-Schneider >> <pfpschneider@gmail.com> wrote: >> >> I believe that the current design of SHACL >> (https://w3c.github.io/data-shapes/shacl/) will make recursive shapes >> very problematic. >> >> Both variations in >> http://w3c.github.io/data-shapes/shacl/#sparql-AbstractValueShapePropertyCo nst >> >> raint >> do not work correctly. (Consider how the designs would work on the >> SHACL versions of the examples in >> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Mar/0377.htm l.) >> >> >> Does anyone have a proposal on how to handle recursive shapes that does not >> give rise to difficulties? > > One possible design would be to have two language features, > sh:valueShapeValidated and sh:valueShapeInformative. > > sh:valueShapeValidated gives rise to a violation if the value doesn’t > satisfy the specified shape. This is like the current sh:valueShape. But > shape definitions with cycles of this features are illegal. > > sh:valueShapeInformative allows cycles, but an implementation is not > required to check it. In other words, an implementation may use any means > of its own choice to determine whether it considers the value to be > satisfying or not. One option is to do nothing, and accept any value. > Another option is to do something clever with recursion. Another option > is to inspect the URI given as the value. Another option is to check if > the value has an rdf:type that has the required shape associated. > > Best, Richard > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJVEsm6AAoJECjN6+QThfjzo3kH/1Lp5HoFjUKdM7e/Updgd4O0 3bzb+CBCLSQpKdz9dpnvynHQmotEcyscqiGIKbF99wPFYCvCjqTB9AAtFLAiR/wN Bz1CHO0KDcyOBcnKfl+Z/7zNxRkocuq/3IupC5NttU7bF6jHCtgue1er1gO0h6y1 VQi/Uffu0lhUF+4VbtJEncNjgBTEyLVF3FVRoD4FxIUbaL6VJ3Lt8+3kT0ipMPbO /Yb3pGx61l+8c0xTiB3QtciGNc8U8AJQK3OYqHvl6H3pF/mfocoFbgtq/tSoCZfL o9DQLAuXbULT5+7HxuG7n00cobkgMUm1MAirpnLROojrUtxer9aVV3+pp4aDtCY= =E2Ed -----END PGP SIGNATURE-----
Received on Wednesday, 25 March 2015 14:44:40 UTC