Re: Shapes Constraint Language (SHACL) Working Draft of 2017-02-02

Peter,

This response is only to your comments about shapes. As previously stated, they have resulted in opening of issues 224 and 225 which have now been resolved by the WG and the resolution reflected in the Editor’s draft. See a detailed response in-line below.

The other two topics (pre-binding and validation results) are not covered by this response.

Regards,

Irene

> On Feb 8, 2017, at 10:47 AM, Peter F. Patel-Schneider <pfpschneider@gmail.com> wrote:
> 
> OK, thanks for the interim response.
> 
> peter
> 
> 
> On 02/07/2017 10:51 PM, Holger Knublauch wrote:
>> This is primarily a housekeeping email.
>> 
>> On 4/02/2017 14:10, Peter F. Patel-Schneider wrote:
>>> 
>> 
>>> 
>>> 
>>> Shapes:
>>> 
>>> The way that shapes are formed and used in SHACL remains a severe problem.
>>> 
>>> There are shapes, node shapes, and property shapes.  There are also three
>>> RDF terms that are related to shapes: sh:Shape, sh:NodeShape, and
>>> sh:PropertyShape.
>>> 
>>> There is much confusing wording on how these all work together.
>>> 
>>> First, there is "sh:NodeShape and sh:PropertyShape can be used to represent
>>> node and property shapes".  How do these RDF terms represent anything?
>>> 

The above sentence was changed to "sh:NodeShape and sh:PropertyShape can be used as SHACL type of node and property shapes, respectively."

>>> Second, there are what appear to be the main definitions of node shapes and
>>> property shapes.
>>> "A node shape is a shape in the shapes graph that is not the subject of a
>>> triple with sh:path as its predicate."
>>> "A property shape is a shape in the shapes graph that is the subject of a
>>> triple that has sh:path as its predicate."
>>> What is the role of sh:NodeShape and sh:PropertyShape if the definition
>>> of node shapes and property shapes doesn't even refer to them?

Users should use sh:NodeShape and sh:PropertyShape as rdf:type values of the node and property shapes, but they are not required to do so. 

>>> This is only reinforced by
>>> "However, the presence of any rdf:type triple does not determine whether a
>>> node is treated as a node shape or not."
>>> "However, the presence of any rdf:type triple does not determine whether a
>>> node is treated as a property shape or not.”
>>> 
The above sentences were removed

>>> Third, there are what appear to be alternative definitions of node shapes and
>>> property shapes.
>>> "sh:NodeShape is the class of node shapes and should be declared as a type
>>> for shapes that are IRIs."
>>> "sh:PropertyShape is the class of property shapes and should be declared as a
>>> type for shapes that are IRIs.”

These sentences have been changed to be more clear. As per above, explicit typing is recommended but not required. Examples are also being updated to show that rdf:type may be provided not only for URIs, but also for blank nodes.

>>> There are multiple problems with these alternative definitions.  For
>>> starters, there is no description in SHACL of what it means to be the class
>>> of anything.  Next, there is no description in SHACL of how to declare a
>>> type for anything.  

With the change in text, this is no longer relevant.

>>> Further, there is the strong suggestion here that shapes
>>> that are IRIs should somehow have both sh:NodeShape and sh:PropertyShape
>>> declared as their type, which doesn't make sense at all.

There was never an intent to say that IRIs should have both sh:NodeShape an sh:PropertyShape as their type. On contrary, the spec said they these were disjoint classes. What caused you to come to this conclusion?
>>> 
>>> Fourth, the conditions to be a shape include being a SHACL instance of
>>> sh:NodeShape or sh:PropertyShape, but not sh:Shape.  This contradicts the
>>> normative statements that rdf:type triples are irrelevant for determining
>>> whether a node is a node or property shape.  It is also exceedingly weird as
>>> sh:Shape is previously indicated to be somehow related to shapes, but being
>>> a SHACL instance of sh:Shape in an RDF graph doesn't make a node a shape in
>>> the graph.  

A node that is a SHACL instance of sh:NodeShape or sh:PropertyShape is a SHACL instance of sh:Shape.

>>> As sh:Shape is the natural RDF term for the type of shapes,
>>> users will use it over sh:NodeShape and sh:PropertyShape.
>>> 

The spec recommends that users use more specific typing. If they decide to use sh:Shape as a type, while not recommended, this is not an issue. As long as a node with sh:Shape as a value of rdf:type has some other property values that make it possible to identify it as a shape (e.g., targets and parameters) or is a value of a *shape expecting* property, it will be identified as a shape.

>>> Aside from these problems with node shapes and property shapes, there are
>>> problems with the definitions that shapes depend on.  For example, shapes
>>> graphs are defined too narrowly.  SHACL validation processes don't always
>>> validate a data graph against the shapes in another graph, but shapes graphs
>>> are not defined for these other situations.
>>> 
WG has previously discussed this topic and decided there was no reason to change the current definition. Shapes graph is a “role” - it is a graph to get shapes from, in order to use them for validation of data. Data graph is any graph. This means shapes graph may also be used as a data graph i.e., shapes don’t have to be in another graph. Is this the “situation” you are referring to here or do you have some other situations in mind?

>>> All this ends up with a big mess.  It appears that it is possible to use
>>> sh:NodeShape and sh:PropertyShape in ways counter to what appears to be
>>> their intended meaning.  For example,
>>>   ex:s1 rdf:type sh:NodeShape ;
>>>     sh:targetClass ex:Person ;
>>>     sh:path ex:child ;
>>>     sh:nodeKind sh:IRI .
>>> appears to be form a constraint on the children of people even though the
>>> type of the shape is sh:NodeShape.

Such shape would be an ill-formed shape. The document has been updated to reflect this.

>>> 
>>> What needs to be done is to get rid of sh:NodeShape and sh:PropertyShape.
>>> They serve no useful purpose.  They will only produce confusion.  

The proposal to remove sh:NodeShapes and sh:PropertyShapes was already (prior to this e-mail) recorded as issue-222 and discussed by the WG. You have clearly communicated that, as a mathematician, you value minimalism of definitions above other aspects that impact usability. However, WG decided that sh:NodeShapes and sh:PropertyShapes do serve a useful purpose and improve clarity e.g., by making it possible for the data modelers (the intended primary users of SHACL) to distinguish between shapes that describe constraints on the nodes identified in the target statements of a shape and shapes that describe constraints on the nodes that are related (via paths) to the targets. 

>>> Then the
>>> defintions underlying shapes need to be corrected.  Because of these
>>> significant and pervasive problems with shapes in SHACL, reviewers cannot
>>> provide fully informed commments on the SHACL document at this time.
>> 
>> I have raised ISSUEs 223 and 224 for this topic.
>> 
>>> 
>>>