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

Hi!

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

FWIW, the PROV-DM [1] also mentions "nonsensical" descriptions:

[2]) 5.7.2.2 prov:location -> "While the attribute prov:location is 
allowed for several PROV concepts, it may not make sense to use it in 
some cases. For example, an activity that describes the relocation of an 
entity will have start and end locations, as well as every place in 
between those points."

[3]) 7. Creating Valid Provenance -> "This specification defines 
PROV-DM, a data model that allows descriptions of the people, [...]. 
However, with this data model, it is also possible to compose 
descriptions that would not make sense: for instance, one could express 
that an entity was used before it was generated, or that the activity 
that generated an entity started after the entity generation."

and more importantly ->

"A set of constraints have been defined for PROV and can be found in a 
companion specification [4]. They SHOULD be used by developers to 
compose provenance descriptions that are valid, and by implementers of 
reasoning engines aiming to check whether provenance descriptions have 
problems. "

Which (imo) basically boils down to either:

1) Declaring certain combinations of Node-/PropertyShapes + Properties 
as being invalid upfront (maybe also distinguishing between invalid 
(e.g., NodeShape+minCount) and ill-formed (e.g., value of sh:minCount is 
!= xsd:integer), or

2) Adopting the PROV-DM approach by providing a set of Shapes for 
validating the ShapesGraph


br, simon


[1] https://www.w3.org/TR/prov-dm/
[2] https://www.w3.org/TR/prov-dm/#term-attribute-location
[3] https://www.w3.org/TR/prov-dm/#valid-provenance
[4] https://www.w3.org/TR/prov-constraints/

Am 2017-02-08 01:52, schrieb Holger Knublauch:
> 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
---
DDipl.-Ing. Simon Steyskal
Institute for Information Business, WU Vienna

www: http://www.steyskal.info/  twitter: @simonsteys

Received on Wednesday, 8 February 2017 06:08:20 UTC