Re: recursive shapes in SHACL

One possibility is to have recursion marked as a feature "At risk". This 
would allow us to have more time to experiment and gather feedback before 
committing to it. Of course, this would still require that we have 
something to put in the spec that we think might work.
--
Arnaud  Le Hors - Senior Technical Staff Member, Open Web Technologies - 
IBM Software Group


"Peter F. Patel-Schneider" <pfpschneider@gmail.com> wrote on 03/25/2015 
10:14:40 AM:

> From: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
> To: Jose Emilio Labra Gayo <jelabra@gmail.com>
> Cc: Richard Cyganiak <richard@cyganiak.de>, "public-data-shapes-
> wg@w3.org" <public-data-shapes-wg@w3.org>
> Date: 03/25/2015 10:15 AM
> Subject: Re: recursive shapes in SHACL
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> My view is that right now there are no implementations of recursive 
shapes
> for any language close to SHACL. There are not even any workable formal
> foundations for recursive shapes that can be adapted to work for SHACL, 
as
> far as I can tell. Of course, there may be advances in this area, but my
> view is that the working group should be putting together something that 
has
> at least a well-defined meaning and some evidence for efficient
> implementation.
> 
> I think that this argues very strongly that recursive shapes should not 
be
> in SHACL for now, and certainly not in the core of SHACL. If future work 
in
> this area produces something usable then recursive shapes could be again
> considered for SHACL.
> 
> 
> peter
> 
> 
> On 03/25/2015 09:29 AM, Jose Emilio Labra Gayo wrote:
> > 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 <mailto:pfpschneider@gmail.com>> wrote:
> > 
> > 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 <mailto: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-AbstractValueShapePropertyC

> o
> >
> >>>
> >>> 
> 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.ht

> m
> >
> >>>
> >>> 
> 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
> > 
> > 
> > 
> > 
> > 
> > -- -- Jose Labra
> > 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
> 
> iQEcBAEBAgAGBQJVEu0AAAoJECjN6+QThfjz0nwH/38SyPKju/+jmVAl7iEIu2lU
> UZl8OzjwnNZ7QcbDKFCO3cbVLZsvyNGinRDo5e36fMVJXmbshD4pCaFCEu1KJooJ
> HdwnNWsTaaAoh+xuntlj/PweYJwoIdBYTKhVIOPH9rLdU8gYLDo6avk1N/44+tKA
> Y8zNUtsYv4q7Ew+Rf5SAQt/+vTrMH2sUJpH8hYUtL7upWNg0ASFqwgqcbaPSnWa1
> KLyx3irCufVkPMKkBbKPD70pZLWoqP2Dh30YFM0YXk6qQ0C2iZ6sgXkICi3vSh1H
> pfMrFuhP2yjKfgKM0nTVaqIBC4BR2G1nIbn4gwtx2nqCvSxsQfHSICiGIdS7TCM=
> =ykZ4
> -----END PGP SIGNATURE-----
>