Re: recursive shapes in SHACL

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I don't think that recursive shapes is even at the feature stage at this momen
t.

peter


On 03/25/2015 01:04 PM, Arnaud Le Hors wrote:
> 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
>> 
> 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-AbstractValueShapeProperty
C
>
>>>> 
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.h
t
>
>>>> 
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

iQEcBAEBAgAGBQJVExi9AAoJECjN6+QThfjz6RIIAJMpxZ9LwROP8HxNOdcbJnIA
Fq4lcVIutRZiCW2/ikXZtnyyhTtN98nYUBd2fuvuKoY1ewSQFKnEUeN1pzDfcVNC
Knhw+e42JPdiUDdFdL5QQCiU1ZaUyI4PkJkOsh3lrfJph5Nu43TnSNoOQa7kusBb
9kH+QOXsqucg5krGKh79ivpr2xfztoqE6LK4Zdv6672DLzHxoBtegXpMs/APAd+b
QxaAfZseEu3l1BheWtlY64Ku1q8H9NGiKmAgxAJZjQPTwjcxBURPq/99+9SVstb8
jw1gVBHXkwkroRlHsradJNihoKFa6EYQcB+cYHHRcFty+mrKLbQ3Ij9grlE4mYQ=
=rQOE
-----END PGP SIGNATURE-----

Received on Wednesday, 25 March 2015 20:21:50 UTC