Re: comments / questions on the SHACL abstract syntax document

* 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.
> 

-- 
-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 11:52:58 UTC