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

Received on Wednesday, 25 March 2015 17:15:11 UTC