Re: comments / questions on the SHACL abstract syntax document

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.


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

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


> 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 Wednesday, 24 August 2016 22:23:45 UTC