Re: SHACL for SHACL

I have just added a paragraph to the end of section 3.4.3 to explain why 
we ended up with the current design. It's a genuine trade-off. By 
requiring a specific definition of recursion, ShEx also excludes some 
implementation strategies and significantly increases the complexity of 
the language. I expect future CGs for SHACL to define one or more 
dialects that do support recursion, similar to how we now have OWL-RL 
and other dialects of OWL.

We will leave it to market forces to decide, and in some situations it 
is best to leave things undefined to allow solutions to evolve without 
being too prescriptive. On the topic of recursion there was a very wide 
spectrum of opinions in the WG, indicating that there may not be a 
single simple answer. It is also far easier for a Community Group 
(consisting of like-minded people) to make decisions than for a strict 
formal WG that has to produce full consensus between every individual 
member. I would encourage the authors of future "comparison bake-off 
papers" between ShEx and SHACL to take these different view points into 
consideration.

Holger


On 5/04/2017 6:36, Jose Emilio Labra Gayo wrote:
> On Tue, Apr 4, 2017 at 7:37 AM, Holger Knublauch 
> <holger@topquadrant.com <mailto: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:
>
>     Thevalidation
>     <http://w3c.github.io/data-shapes/shacl/#dfn-validation>withrecursive
>     <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
>     <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 
> <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