Re: declaring (practically) insensible shapes to be ill-formed

This was my opinion from the start, but I lost that discussion. (In case 
that anyone suspects a TopQuadrant conspiracy, note that I didn't 
discuss that topic with Irene but she came to the same conclusion 
independently).

A proposal would be to declare that NodeShapes are ill-formed if they 
use any of the following properties:

- sh:minCount
- sh:maxCount
- sh:uniqueLang
- sh:equals
- sh:disjoint
- sh:lessThan
- sh:lessThanOrEquals
- sh:qualifiedValueShape

Declaring these ill-formed would allow us to skip many irrelevant test 
cases, reduce implementation costs and short-cut many useless 
discussions. The cost of making these illegal is lower than the cost of 
keeping them.

Note that we still have the related topic of what to do if a constraint 
component defines no suitable validator marked in red (awaiting user 
feedback) in 6.2.3. Currently this allows the case where a user-defined 
constraint component is not "working" in certain contexts. The proposal 
above is just an application of a similar principle.

Holger


On 8/02/2017 8:19, Irene Polikoff wrote:
> I know that this topic has been previously discussed in 
> https://www.w3.org/2014/data-shapes/track/issues/139
>
> However, we now have a couple of WG members who have not participated 
> in this discussion and we are starting to get some questions on this 
> from the broader community as evidenced in a recent comment from 
> Olivier Corby as to why all constraint components are available with 
> both node shapes and property shapes. Thus, I thought, perhaps, we 
> should revisit the topic.
>
> At one point we used to disallow some constraint components for node 
> shapes, but currently all are allowed. With this, a user can write a 
> shape such as
>>>
>>> ex:MinCountExampleShape
>>>  a sh:NodeShape ;
>>>  sh:targetClass ex:Person;
>>>     sh:maxCount 2 ;
>>>  sh:minCount 2 .
>
> It will be considered a well-formed shape. Given any data graph with 
> instances of ex:Person, the validation result will always be the same:
>
>   * The maxCount constraint will never produce a validation result -
>     because any resource is always just one resource.
>   * The minCount constraint will always produce a validation result -
>     because any resource is always just one resource.
>
>
> I see this shape as an “insensible shape” in that no one would ever 
> create such a shape except as a mistake i.e., what they really meant 
> to say and check for was something else. I considered calling it an 
> “illogical shape”, but I didn’t because my use of the word “illogical” 
> would be colloquial - the spec defines what such shape means and how 
> it should be interpreted.
>
> Nevertheless, the interpretation is so completely impractical, I 
> believe a typical developer or a data modeler is very unlikely to 
> correctly understand it on their own - no matter what we say in the 
> spec unless we explicitly prohibit it. Further, it would be very hard 
> to explain the meaning of such shape to them and, once they understood 
> it, they will wonder why such shapes are allowed in the first place. 
> Even further, the explanation is so counter-intuitive that they are 
> very likely to quickly forget it and go back to a more 
> intuitive/plausible interpretation of this shape - which is that it 
> constraints the number of members of the ex:Person class.
>
> Does anyone sees an issue with saying that the use of certain 
> constraint components (such as min and max count, QCR and property 
> pair constraints) in a node shape creates an ill formed shape? The 
> cost of disallowing certain constraints is very low.
>
> Additionally, by doing this, the WG will save time because we will 
> have fewer cases to cover by tests. Given the WG time line it is an 
> important additional argument for returning to this issue. Disallowing 
> such shapes is also likely to decrease costs for implementers.
>
> Regards,
>
> Irene