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

On 02/08/2017 05:31 PM, Irene Polikoff wrote:
> 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."

Aside from the grammatical issue, this is better.

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

But what good is this?  If there is no utility of something in a
specification, then it doesn't belong in the specification.

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

This removal doesn't introduce any utility.

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

Where are the replacements?   The paragraphs where they used to be are no
longer part of the document.

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

See above.

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

As mentioned earlier, there was a strong suggestion to have shapes that are
IRIs to have both type sh:NodeShape and sh:PropertyShape.

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

This is not responsive to my comment.  Typing was stated to be irrelevant
but then typing was used to determine whether something was a shape.
Separately, typing to sh:Shape didn't make something a 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.

This is not correct.  The sole presence of the non-type triples were
sufficient to recognize a node as a node shape or a property shape.  There
was no need at all for any typing and certainly no need for specific typing.

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

You are missing the point here.  A shapes graph is only defined for certain
SHACL operations not all.  What happens for these other oeprations.

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

No.  Such a shape would not have been an ill-formed shape.  If the document
has been updated to reflect this, then a very significant change has been
made to SHACL.

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

First, I am not mathematician.  Please do not incorrectly place labels that
have been used derogatorily in the working group on commenters.

Second, I do not value minimalism of definitions above all other aspects that
impact usability.  Please do not make misleading statements about commenters.

I don't think that data modelers are incapable of distinguishing shapes that
have a value for sh:path and those that don't.  This distinction was
sufficient for distinguishing between node shapes and property shapes.  As
this distinction was also necessary for distinguishing between node shapes
and property shapes there was no actual effect of typing shapes to either
sh:NodeShape or sh:PropertyShape.  So the only effect of sh:NodeShape and
sh:PropertyShape was to confuse the distinction, making it harder for anyone
including data modelers.

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

I await resolution of these issues.

Peter F. Patel-Schneider

Received on Thursday, 9 February 2017 17:39:13 UTC