Re: comments / questions on the SHACL abstract syntax document

(Moved to WG mailing list)

I think these differences just confirm the concern that having two 
different, competing specs about the same issues causes a lot of 
confusion and unnecessary inconsistencies. Here, why should we duplicate 
the validation conditions especially if more details and even SPARQL 
queries and the mapping to result vocabulary were already written down 
in the main spec? The abstract syntax claims there is only "fail" while 
in fact there are details about how many violations are reported etc. 
Furthermore, the term failure is already used with different meaning in 
the SHACL spec.

I believe a more helpful way to write the Abstract Syntax document would 
be to focus on the Abstract Syntax itself and its mapping to the RDF 
vocabulary. Then leave the details of the interpretation to the 
normative doc. In other words, drop the "Semantics" from the Abstract 
Syntax document. This was my understanding when we voted to have this 
document in the first place. I would vote -1 to publish this parallel 
universe.

Holger


On 25/08/2016 21:52, Eric Prud'hommeaux wrote:
> * Eric Prud'hommeaux <eric@w3.org> [2016-08-24 18:23-0400]
>> Many thanks for the comments. It's not a big deal but in principle
>> these should have gone to <public-data-shapes-wg@w3.org> since you are
>> both in the WG.
>>
>> I believe I've addressed the first point and contested the second. See
>> below.
> Revisited the 2nd point. See below.
>
>
>> * Irene Polikoff <irene@topquadrant.com> [2016-08-23 08:01-0400]
>>>> From:  Iovka Boneva <iovka.boneva@univ-lille1.fr>
>>>> Date:  Tuesday, August 23, 2016 at 6:25 AM
>>>> To:  <public-rdf-shapes@w3.org>
>>>> Subject:  comments / questions on the SHACL abstract syntax document
>>>> Resent-From:  <public-rdf-shapes@w3.org>
>>>> Resent-Date:  Tue, 23 Aug 2016 10:33:22 +0000
>>>>
>>>>      
>>>>   1) is a difference between the SHACL abstract syntax and the SHACL
>>>> specification
>>>>   2) is a potential error in both SHACL abstract syntax and SHACL
>>>> specification.
>>>>   
>>>>   Here above,
>>>>   "SHACL abstract syntax" refers to
>>>> http://w3c.github.io/data-shapes/shacl-abstract-syntax/ Editor's Draft 23
>>>> August 2016
>>>>   "SHACL Specification" refers to https://www.w3.org/TR/shacl/  Working Draft
>>>> 14 August 2016
>>>>   
>>>>   
>>>>   1)
>>>>   ISSUE 2 in SHACL abstract syntax Section 5.1.2
>>>> http://w3c.github.io/data-shapes/shacl-abstract-syntax/#RDFtermequivalence
>>>>   
>>>>   The 'hasValue' parameter is not a particular case of the 'in' parameter,
>>>> contrary to what is suggested by ISSUE 2.
>>>>   As far as I understand the SHACL specification:
>>>>   - 'hasValue' tests whether one of the value nodes has the specified value,
>>>> and disregards the other value nodes.
>>>>   - 'in' tests whether all the value nodes have a value that is included in
>>>> the set
>>>>   
>>>>   The 'hasValue' parameter differs from most of the other parameters with
>>>> this regard, which can be misleading to users. So the question whether this
>>>> parameter should be treated in the same way as the other parameters is of
>>>> independent interest, imho.
>>>>   
>>> I agree with how Iovka described hasValue. It is indeed different from ‘in’.
>> ~ moved HasValue to N-ary parameters with the definition:
>>
>>    HasValue := val:RDF term
>> Testing a HasValue parameter against a value node returns fail if the
>> set of value nodes is non-empty and no element of value nodes is the
>> same term as <val>.
>>
>> https://github.com/w3c/data-shapes/commit/48f595d94cde459c68f4abf17139056f7c752d69
>>
>>
>>>>   2)
>>>>   In Section 5.1.6
>>>> http://w3c.github.io/data-shapes/shacl-abstract-syntax/#Comparisonwithsiblin
>>>> gproperty
>>>>   
>>>>   The semantics of comparison with specified property is incomplete: it is
>>>> undefined in some cases.
>>>>   It does not say what happens if there are several value nodes with which to
>>>> compare.
>>>>   
>>>>   For instance, constraint :
>>>>   
>>>> <IssueShape> sh:property [ sh:predicate ex:submittedOn; sh:lessThan
>>>> ex:reproducedOn ] .
>>>>   
>>>>
>>>> Graph
>>>>   
>>>> <issue1> ex:submittedOn "2016-07-08T10:23:45Z"^^xsd:dateTime ;
>>>>           ex:reproducedOn "2016-07-08T13:53:00Z"^^xsd:dateTime ;
>>>>   ex:reproducedOn "2016-07-08T09:53:00Z"^^xsd:dateTime .
> Oops, I answered for two submittedOns rather than two reproducedOns.
>
>
>>>> Does the test pass or fail ?
>>>>   
>>>>
>>>> As far as I can see, the SHACL specification il also incomplete in this
>>>> case.
>>>>   
>>> On the second item, I believe that the violation must be produced and that
>>> the spec is clear on the semantics of this constraint:
>>>
>>> The existence of the following raises a violation
>>>
>>> ?s ex:submittedOn ?value1.
>>> ?s ex:reproducedOn ?value2.
>>> ?value1 >= ?value2
>>>
>>>
>>> The fact that there is also {?s ex:submittedOn ?value3} that does not meet
>>> the above condition and, thus, doesn't cause the violation, doesn't matter.
>> I think the answer comes from the combination of the evaluation of Constraints:
>>
>>    The result of validating a set of value nodes against a set of unary
>>    parameters is fail if any individual value node failed any Parameter,
>>    otherwise pass.
>>
>> combined with e.g. LessThan:
>>
>>    Testing a LessThan parameter against a value node returns fail if
>>    there is no node v in (focus node, sibling, v) in the data graph or
>>    the evaluation of (value node < v) in SPARQL1.1 Operator Mapping
>>    returns false or results in a type error.…
> In an effort to be explicit about n-ary arguments, I've changed this to:
>
> Let siblingVals be the set of objects in triples matching
>    (focus node, sibling, siblingVal).
> Testing a LessThan parameter against a value node returns fail if
> evaluating the SPARQL1.1 Operator (value node < siblingVal) for any
> siblingVal in siblingVals returns false or results in a type error.
>
> https://github.com/w3c/data-shapes/commit/e40c6f4de16deb0c216b6a61be0ad7cf5a07950f
>
> This revealed that Disjoint could also be considered "NotEquals".
>
> https://github.com/w3c/data-shapes/commit/f5e32a77d80a340cdc1b55a2e3168aeff3328e9d
>
>
>> I believe we can evaluate LessThan on each value individually. I've
>> added two examples to point this out:
>>
>>    <issue1> ex:submittedOn "2016-07-08T10:23:45Z"^^xsd:dateTime ;
>>             ex:reproducedOn "2016-07-08T13:53:00Z"^^xsd:dateTime .
>> + <issue2> ex:submittedOn "2016-07-08T10:23:45Z"^^xsd:dateTime, "2016-07-09T12:45:23Z"^^xsd:dateTime ;
>> +          ex:reproducedOn "2016-07-08T13:53:00Z"^^xsd:dateTime .
>>    <issue3> ex:submittedOn "2016-07-08T10:23:45Z"^^xsd:dateTime ;
>>             ex:reproducedOn "2016-07-08T09:53:00Z"^^xsd:dateTime .
>> + <issue4> ex:submittedOn "2016-07-08T09:00:00Z"^^xsd:dateTime, "2016-07-08T09:53:00Z"^^xsd:dateTime ;
>> +          ex:reproducedOn "2016-07-08T09:53:00Z"^^xsd:dateTime .
>>    <issue5> ex:submittedOn "2016-07-08T10:23:45Z"^^xsd:dateTime ;
>>             ex:reproducedOn "2016-07-12"^^xsd:date .
>>
>> https://github.com/w3c/data-shapes/commit/ea0ab7a9075bc2853933846438985b2a936711fa
> I Wanted to addn an n-ary example but xsd:dateTimes were becoming
> painful visually. I went with contrived but terse criticalities and
> priorities example:
>
> Intro:
>   Supposed different departments can assign different criticalities (how
>   important is it) and priorities (how soon should it get fixed) to
>   issues and that no priority may be lower than a criticality:
>
> Schema:
> # Lower number means higher priority or criticality.
> <IssueShape> sh:property [ sh:predicate ex:priority; sh:lessThanEquals ex:criticality ] .
>
> Data:
> <issue1> ex:criticality 3; ex:priority 2 .
> <issue2> ex:priority 1, 4 . # No criticality against which to compare
> <issue3> ex:criticality 2, 5; ex:priority 1, 4 .
> <issue4> ex:criticality ex:Low; ex:priority ex:Medium .
> <issue5> ex:criticality ex:Low; ex:priority 1 .
>
> Validation:
> shape  node  result reason
> <IssueShape> <issue1> pass
> <IssueShape> <issue2> pass
> <IssueShape> <issue3> fail 4 greater than 2.
> <IssueShape> <issue4> fail "Medium" greater than "Low".
> <IssueShape> <issue5> fail 1 not comparable with ex:Low.
>
> https://github.com/w3c/data-shapes/commit/5da5930c735bcf7a92448e0afcba247ee194093b
>
>
>>> Irene
>>>
>>>>   
>>>>   
>>>> -- 
>>>> Iovka Boneva
>>>> Associate professor (MdC) Université de Lille
>>>> http://www.cristal.univ-lille.fr/~boneva/
>>>> +33 6 95 75 70 25
>>>>   
>>>>
>>>>
>> -- 
>> -ericP
>>
>> office: +1.617.599.3509
>> mobile: +33.6.80.80.35.59
>>
>> (eric@w3.org)
>> Feel free to forward this message to any list for any purpose other than
>> email address distribution.
>>
>> There are subtle nuances encoded in font variation and clever layout
>> which can only be seen by printing this message on high-clay paper.
>>

Received on Thursday, 25 August 2016 23:55:36 UTC