Re: ISSUE-22: Proposal based on sh:hasShape

Hash: SHA256 permits recursion through negation.
 As that is the basis for SHACL, recursion through negation appears to still
be on the table.  Even without having recursion through negation, having
recursion and negation together is tricky.  I don't think that there is
support for removing all negation (including, of course, XOR and several
other constructs) from SHACL.

It is possible to devise a well-behaved semantics for recursion through
negation by going to multiple interpretations, of course, but I don't know
if that approach has significant support in the working group.

As far as I can tell, Holger has suggested that running SHACL might result in
  I'm sorry, I can't decide what to do here.
in many cases, even those where there might be considerable support for
providing one particular answer.  There are a lot of issues with this
approach, including just how widely the various "Duh" answers propagate.
Changing the order of triples in a shapes or data graph document, or even
just running the system again, might end up producing different answers if
care is not taken in fleshing out this approach, even in cases where there
is no negation or even disjunction.  Picking a bad propagation rule for a
"Duh" is going to produce something that I think will be unusable---I don't
even know if there is any good set of propagation rules.


On 06/11/2015 06:39 PM, Arnaud Le Hors wrote:
> "Peter F. Patel-Schneider" <> wrote on 06/11/2015 
> 05:15:48 PM:
>> Recursions through negations (including XOR, QCRs, etc.) are much
>> tougher.
>> There has been quite a bit of discussion on this in the working group 
>> mailing list already.
> Yes, I understand. But most people seem to be willing to simply declare
> that one cannot use negation along with recursion.
> Are you saying that treating your example from ISSUE-66 as invalid, as
> Holger suggested, is better from that point of view (negation)? -- Arnaud
> Le Hors - Senior Technical Staff Member, Open Web Technologies - IBM 
> Software Group
>> peter
>> On 06/11/2015 04:29 PM, Arnaud Le Hors wrote:
>>> Holger Knublauch <> wrote on 06/10/2015
>>> 06:11:24 PM:
>>>> From: Holger Knublauch <> To: RDF Data
>>>> Shapes Working Group <> Date:
>>>> 06/10/2015 06:13 PM Subject: ISSUE-22: Proposal based on
>>>> sh:hasShape
>>>> I would like to write down the solution to the recursion issue that
>>>> I have currently implemented in my prototype, and welcome comments 
>>>> whether this would resolve the issue.
>>>> Recursive evaluation of shapes can only be triggered via the 
>>>> sh:hasShape function. sh:hasShape takes three arguments:
>>>> sh:hasShape(?focusNode, ?shape, ?shapesGraph)
>>>> Proposal: sh:hasShape must fail with a constraint violation, if it 
>>>> encounters a recursive call involving the same combination of 
>>>> arguments.
>>> I'd like to know what makes you choose to declare this a failure. 
>>> Couldn't we just as well decide that in this case the recursion
>>> stops there assuming the constraint is satisfied (for the next
>>> iteration)? This would mean that Peter's example in ISSUE-66 would be
>>> valid:
>>> ex:i rdf:type ex:C . ex:i ex:p ex:i .
>>> with the shape
>>> exs:S rdf:type sh:Shape; sh:classScope ex:C ; sh:property [
>>> sh:predicate ex:p ; sh:minCount 1 ; sh:maxCount 1 ; sh:valueShape
>>> exs:S ] .
>>> As a user this seems quite natural to me but maybe there are other 
>>> examples for which this wouldn't be the case. I don't know. -- Arnaud
>>> Le Hors - Senior Technical Staff Member, Open Web Technologies - IBM 
>>> Software Group
>>>> The constraint violation could have a system generated message such
>>>> as "Failed to evaluate constraint due to unsupported recursive use
>>>> of sh:hasShape" and point at the focus node that was visited
>>>> twice.
>>>> This would still allow most interesting cases that involve
>>>> recursion between shapes, but excludes cases where the same
>>>> instances are visited more than once.
>>>> What am I missing?
>>>> Thanks, Holger
>> -----BEGIN PGP SIGNATURE----- Version: GnuPG v2
>> +UhFZFtvRIG3JZJaV8r4pBGYZu8eRiXovtmxlV9U9H7TOnCPt0JHZK5mDNpvQbxk 
>> MnJrxu/68Q1qYcVGN1j2ZReX9GPRNuF7bwhSgPmUv239LRv30ROtZXwCRpJ7sMEl 
>> 3ME3Er3pHjGbugrHxG/ZwJiFQJbgds89Qw5z+wCbWmPzR/rh4UE4VOu5t4b0IWAj 
>> /3dxqPQWMNldTg1auVd2Dct9eZop6ToxochxImkbPkMFj762NcFfkbcD+tF6Fy3t 
>> SpiOzWj/kMdmgDUTec0n9e+YznZWvcVPwktFKN7+pHpt08mm7ODiRnW3Q0um3DU= =8nfB 
>> -----END PGP SIGNATURE-----
Version: GnuPG v2


Received on Friday, 12 June 2015 03:37:41 UTC