Re: Shape Expressions Schemas (was Re: ISSUE-22 Recursion - Status of Core SHACL Semantics draft)

Le 16/11/2015 15:36, Peter F. Patel-Schneider a écrit :
> On 11/16/2015 12:41 AM, Iovka Boneva wrote:
>> Le 13/11/2015 05:10, Peter F. Patel-Schneider a écrit :
>>> I was looking at Shape Expressions Schemas [1] and was puzzled by a particular
>>> statement about the motivating example.
>>> On page 3, the paper states: "On the other hand, even in presence of EXTRA,
>>> an issue shape can still be is:reproducedBy only one tester."
>>> I do not believe that this is correct.
>> This is correct.
>> The EXTRA properties allow to "consume" only those triples that match none of
>> the triple constraints (here, neither <ProgrammerShape> nor <TesterShape>
>> Iovka
>>> In the example, a node that validates under IssueShape could have an arbitrary
>>> number of values for is:reproducedBy that validate under TesterShape, so long
>>> as at most one of them do not validate under ProgrammerShape.
>>> Is my reasoning correct here?
> This is the question that needs to be answered.
> In previous versions of ShEx, this would be correct reasoning.  Has something
> changed?  Are repeated properties in ShEx no longer additive?  This may be the
> case, reading the semantics of grouping near the bottom of Page 5, but I don't
> know whether this change is intentional or not.
> It would be very useful to have some sort of change log for ShEx.  Just about
> every account of it has significant differences from the other accounts.

I think I misunderstood this question in my previous answer.
There is no change in ShEx semantics, it remains additive.

The sentence you were referring to is a short intuitive explanation for 
EXTRA, and following your question I understand that this is misleading, 
because of the interference with the is:reproducedBy @<ProgrammerShape> 
triple constraint.

You are right, there can be nodes neighbours of the focus node that 
satisfy <TesterShape>, but also satisfy @<ProgrammerShape> and are 
"consumed" by the is:reproducedBy @<ProgrammerShape> triple constraint 
(thus considered as programmers).

If one wants to ensure that there is exactly one neighbour satisfying 
<TesterShape>, one should write

<IssueShape>  EXTRA is:reproducedBy
     is:reproducedBy @<TesterShape> ,
     is:reproducedBy @<ProgrammerShape> AND !@<TesterShape>,

So, one again, there is no change in ShEx semantics, it remains additive.

>>> peter
>>> On 11/11/2015 07:50 PM, Arthur Ryman wrote:
>>>> I had a telecon with Iovka this week. She reviewed the issues I found
>>>> in the draft and did make one correction to the definition of
>>>> negshapes.
>>>> Some of the issues I found were about the semantics of the oneOf
>>>> operator. However, Iovka said that this operator was problematic for
>>>> other reasons and has been dropped from the latest version of ShEx.
>>>> Iovka said that the draft is no longer being maintained. Her latest
>>>> version of the semantics of ShEx is given in [1]. I pointed out that I
>>>> had proposed a different approach to positive recursion. [2]
>>>> We agreed to look at each others articles and decide how to proceed.
>>>> [1]
>>>> [2]
>>>> -- Arthur

Iovka Boneva
Associate professor (MdC) Université de Lille
+33 6 95 75 70 25

Received on Tuesday, 17 November 2015 09:54:29 UTC