Re: Shapes and/vs constraints

Hi Karen,

a simple, clear explanation for this question may not exist because this 
isn't a simple question. A detailed look at the consequences is needed. 
Let me enumerate a few reasons why I think merging these concepts is a 
bad idea:

0) Separated concepts is how the spec is currently written. This may be 
brushed away by saying that nothing is finalized yet, but if we changed 
this now, any early adopter will need to redo their early adoption. Who 
knows what users will be saying and what we will discover. We as a 
Working Group, our specs and the implementations would be thrown back 
significantly if we made such a change now. For any such change at the 
current stage, there need to be good reasons.

1) Simplification was mentioned as the main reason for merging these 
concepts. However, that simplification comes at significant costs, 
because we would lose the ability to distinguish different use cases and 
roles. Calling everything a "shape" is blurring the lines.

2) An important role is the distinction between the various constraint 
types: NodeConstraint, PropertyConstraint, InversePropertyConstraint. 
Not all constraint properties (such as sh:closed) make sense in all 
three contexts. Having separate concepts (and subclasses of 
sh:Constraint) provides a natural way of stating under which conditions 
which properties make sense.

3) There is nothing conceptually difficult about the current design, and 
therefore no need to change anything. "Shapes are a collection of 
constraints and define a scope". Shapes are similar to class 
definitions, and intuitive to understand by most people. Property 
constraints declare a property at a class.

4) There is already long practical experience with this design. Both 
Resource Shapes and SPIN have separated shapes and constraints. This 
pattern has proven to work well.

5) Having separate concepts makes it easier to define the metamodel. A 
metamodel with base classes sh:Shape and sh:Constraint makes it natural 
to define their properties based on rdfs:range/rdfs:domain or similar 
techniques.

6) Shapes have different attributes than constraints. An example is that 
only shapes can have a scope. Other examples are the linkage with 
classes and future extensions such as rules. If shapes were also playing 
the role of constraints, then many of these shapes would serve as 
sub-objects that only make sense in the context of their parent shape 
(just like property constraints now). It makes no sense to have scopes 
or rules on such sub-shapes.

7) Constraints have different attributes than shapes. For example, 
sh:PropertyConstraints can have sh:name, sh:description and sh:group. 
Merging these concepts would need to state that all shapes may have 
sh:name and sh:description, which is incorrect. The domain of sh:name 
includes sh:PropertyConstraint, not sh:Shape.

8) For property constraints, sh:predicate belongs into the constraint, 
not outside. Peter's design is quietly pretending that no such thing 
exists, and he uses an extremely ugly trick based on an rdf:List where 
the first member is the sh:predicate and the second member is a shape. 
Here you have the equivalent of sh:PropertyConstraint, but as a poorly 
structured and implicit object. In fact the presence of this 
intermediate List proves that some object is needed, if only to specify 
the predicate.

9) If we drop constraints then the syntax is becoming inconsistent, as 
there will be multiple ways to state the same thing. I mentioned this 
before but Peter has not continued that thread. As soon as you want to 
specify a different sh:severity for a constraint, you need an object to 
attach this to. This leads to the following two patterns:

ex:MyShape a sh:Shape ;
     sh:closed true .

ex:MyShape a sh:Shape ;
     sh:shape [ sh:closed true ; sh:severity sh:Warning ] .

Such different patterns are a nightmare for users, for tool developers 
and anyone who wants to make sense of a shapes document. Completely 
different code needs to be written only to set different severity. 
Algorithms become more complicating.

10) In Peter's design, shapes carry different semantics depending on 
where they are used. If they appear in the rdf:List that is the value of 
sh:propValues, then they are interpreted to apply to the set of values 
of the property which is the first item in that rdf:List. In Proposal 3, 
their semantics only depends on their rdf:type (although that rdf:type 
may be derived from the default value type).

There may be more reasons but it's 3:22 am here so my brain is not up to 
speed.

Holger


On 14/04/2016 14:22, Karen Coyle wrote:
> One of the differences between the proposals put forth by Holger and 
> Peter is whether there need to be both shapes and constraints 
> (Holger's view) or just shapes (Peter's). This sounds to me like an 
> important difference, but I need an explanation of why 1) Holger 
> thinks just having shapes will not work and 2) why Peter thinks we do 
> not need both.
>
> A simple, clear explanation of each point of view would be very much 
> appreciated.
>
> Thanks,
> kc
>

Received on Thursday, 14 April 2016 17:23:28 UTC