W3C home > Mailing lists > Public > public-data-shapes-wg@w3.org > May 2016

Re: On various syntax issues

From: Holger Knublauch <holger@topquadrant.com>
Date: Fri, 20 May 2016 11:19:18 +1000
To: "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org>
Message-ID: <a5403e26-2d66-2d02-b954-d8fb0a97cbad@topquadrant.com>
On 20/05/2016 10:58, Peter F. Patel-Schneider wrote:
> On 05/19/2016 03:47 PM, Holger Knublauch wrote:
>>
>> On 20/05/2016 1:07, Peter F. Patel-Schneider wrote:
>>> It seems to me that one of the goals of syntax simplification is to end up
>>> with a simpler syntax.  One aspect of having a simpler syntax, to me, is
>>> that constructs that intuitively make sense are permitted, particularly if
>>> similar constructs are also permitted.
>>>
>>> 1/ Because existing property constraints can be conjoined, it should be
>>> possible to conjoin existing shapes, like
>>>
>>> ex:s1 rdf:type sh:Shape ;
>>>    sh:nodeKind sh:IRI ;
>>>    sh:class ex:Citizen .
>>>
>>> ex:s2 rdf:type sh:Shape ;
>>>    sh:property [ sh:predicate ex:child ;
>>>             sh:class ex:Person ] .
>>>
>>> ex:s3 rdf:type sh:Shape ;
>>>    sh:scopeClass ex:Person ;
>>>    sh:filter [ sh:property [ sh:predicate sh:age ;
>>>                   sh:minInclusive 18 ] ] ;
>>>    sh:and ( ex:s1 ex:s2 ) .
>>>                           
>>> So sh:and is needed unless there is another simple way to achieve this.
>> This can be written using sh:shape (in case it gets approved):
>>
>> ex:s3 rdf:type sh:Shape ;
>>   sh:scopeClass ex:Person ;
>>   sh:filter [ sh:property [ sh:predicate sh:age ;
>>                  sh:minInclusive 18 ] ] ;
>>   sh:shape ex:s1 ;
>>   sh:shape ex:s2 .
>>
>> So unless we want to create a sh:and as an alternative syntax aligning with
>> sh:or, I don't think we need sh:and.
> This new feature probably means that sh:and is redundant.  Whether it is a
> good idea to have sh:or and sh:not without a matching sh:and is a separate matter.
>
>>> 2/ If a boolean construct is allowed in one place it should be allowed in
>>> similar places.
>>>
>>> Because disjunction is allowed in node constraints (shapes) it should also
>>> be allowed in property constraints, like
>>>
>>> ex:s4 rdf:type sh:Shape ;
>>>    sh:scopeClass ex:Taxpayer ;
>>>    sh:property [ sh:predicate ex:dependent ;
>>>             sh:or ( ex:s1 ex:s2 )
> This may now be allowed.  The situation is a bit unclear because the
> description of sh:or starts "SHACL supports a high-level syntax for
> disjunctive constraints that can be used to test whether the focus node has at
> least one out of several shapes." which does not work for (inverse) property
> constraints.  There is similar language for sh:not and sh:and.

Ok thanks for reporting this. Fixed by switching to "value node":

https://github.com/w3c/data-shapes/commit/75f921ed1cc36ad0c36bb9a9821bdf473eefedc2

>
>>> Because disjunction of node constraint (shape) components is allowed so should
>>> disjunction of property constraint components, like
>>>
>>> ex:s4 rdf:type sh:Shape ;
>>>    sh:scopeClass ex:Taxpayer ;
>>>    sh:property [ sh:predicate ex:dependent ;
>>>             sh:or ( ex:s1 ex:s2 [ sh:minCount 5 ] ) ] .
> This does not appear to be allowed.  ISSUE-135 is tracking whether (some)
> constraints are allowed as arguments to sh:and/sh:or/sh:not but that doesn't
> appear to even allow this useful and simplifying construction.

Ah OK, I missed the [ sh:minCount 5 ] which I guess is supposed to be a 
property constraint. I am against supporting this, because it is not 
worth going through the complexity of having multiple possible 
constraint types as members of sh:or lists and the resulting complexity 
of assigning a default predicate in some of them. Once someone has 
scenarios that are as complex as the above, it should be acceptable to 
use an outside sh:or. It will also be easier to explain to users and to 
implement by tools if all members of sh:or lists are shapes.

Holger


>
>> Yes this extension of sh:or had been approved recently and the spec had been
>> updated.
>>
>> Holger
>>
>>
Received on Friday, 20 May 2016 01:19:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:33 UTC