Re: SHACL for SHACL

On Tue, Apr 4, 2017 at 7:37 AM, Holger Knublauch <holger@topquadrant.com>
wrote:

> Jose,
>
> as someone who is working on implementations for both SHACL and ShEx, and
> member of both groups, would you see a way to reformulate our current
> paragraph so that it would represent a more liberal definition of
> recursion?
>

The problem is combining recursion with the rest of the language features.

Currently in 3.4.3 we state:
>
> The validation <http://w3c.github.io/data-shapes/shacl/#dfn-validation>
> with recursive
> <http://w3c.github.io/data-shapes/shacl/#dfn-recursive-shape> shapes is
> not defined in SHACL and is left to SHACL processor implementations. For
> example, SHACL processors may support recursion scenarios or produce a
> failure when they detect recursion.
>
> I think there is generally no problem with the recursive use of sh:node,
> sh:property etc as long as no negation is used and no focus node/shape
> combination is reached twice. I can see that ShEx has
>
>     http://shex.io/shex-semantics/#negation-requirement
>
> which looks related.
>
> (I am not at all confident that at this stage such changes could still be
> realistically made, yet we are not in CR yet).
>

ShEx was designed to support recursive definitions from the start and the
different language features were added taking into account that their
semantics combined well with recursion.

In the case of SHACL, the addition of language features followed a
different approach that makes it more difficult to assess if the language
will still have a well defined semantics combined with recursion.

It is a pity that SHACL lacks recursion and any use of SHACL that goes
beyond toy examples, requires defining cyclic data models which are more
naturally expressed with recursion.

That's what happened to me when we were defining the WebIndex data model
that was described in this paper [1]. In that model, it was just natural to
declare the shapes recursively.

Although sometimes, those cyclic data models can be emulated using target
declarations, it forces every node to have a discriminating rdf:type
declaration, which is too restrictive.

I already tried to convince the WG to do the effort of allowing recursion
some time ago but there was a lot of resistance. As you say, at this stage,
such a change doesn't look realistic and I am not sure if it would have
support by the rest of the WG members.


>
> BTW of course many if not most implementations of SHACL will still support
> recursion, it's just that the spec doesn't prescribe this right now, so
> most likely the practical use of SHACL will diverge from the official
> document here.
>

And that's a big problem. If there is a feature that is used in practice a
lot, but whose semantics depends on implementations, then the shapes graphs
that employ that feature will not be interoperable because their semantics
will depend on which SHACL processor one uses.

Regards, Jose Labra

[1] Validating and describing linked data portals using shapes, Jose-Emilio
Labra-Gayo, Eric Prud'hommeaux, Harold Solbrig, Iovka Boneva,
https://arxiv.org/abs/1701.08924



> Thanks,
> Holger
>
>
>
> On 4/04/2017 15:23, Jose Emilio Labra Gayo wrote:
>
>
>> Unfortunately this exercise confirms my long-held belief that the current
>> work-around to avoid structural recursion leads to unmaintainable and
>> redundant shape definitions. SHACL users will get negatively surprised by
>> this. I believe we have made a mistake in SHACL by generally making
>> structural recursion undefined.
>>
>
> I completely agree on that.
>
> In fact, that is one of the main differences between ShEx and SHACL.
>
> --
> Regards, Jose Labra
>
>
>


-- 
Saludos, Labra