Re: recursive shapes in SHACL

I also think it is better to have a single language construct sh:valueShape
to increase interoperability.

What I am not yet sure is about the real need to forbid recursive shapes at
this point. From my point they increase the expressiveness of the language
and appear commonly when one is trying to model some domain.

I agree that the interaction between recursive shapes and other features of
the language can increase the computational complexity and it is possible
that some of those interactions can even generate some non-intuitive
results.

But this situation is not new in the design of any language and there are
lots of languages that contain features whose interaction can lead to
non-intuitive situations or even infinite loops.

I think the point where we can establish that kind of prohibitions is in
the definition of SHACL profiles which can be based on different
combinations of language constructs and some restrictions like not allowing
recursive shapes to improve tractability of the shapes defined using those
profiles.

In this way, the full SHACL vocabulary can define the set of common
language constructs while SHACL profiles can limit which combinations
employ and which combinations forbid in a way similar to OWL2 profiles.

Since Peter raised his concerns about recursive shapes I have not even had
time to check those examples in my implementation due to several other
duties. I have some ideas right now on how to define the semantics in a
stable way but I had not time to check them yet. I would prefer to have
some time to think about possible solutions before taking a firm decision
on this.

Best regards, Jose Labra

On Wed, Mar 25, 2015 at 3:44 PM, Peter F. Patel-Schneider <
pfpschneider@gmail.com> wrote:

> -----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-----
>
>


-- 
-- Jose Labra