W3C home > Mailing lists > Public > public-rdf-shapes@w3.org > February 2017

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

From: Irene Polikoff <irene@topquadrant.com>
Date: Sat, 4 Feb 2017 16:03:47 -0500
Cc: public-rdf-shapes@w3.org
Message-Id: <0CA03784-72E8-40F4-A425-BE9799163D9C@topquadrant.com>
To: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
Peter,

Thank you for your feedback.

Current W3C process treats publishing a CR in a way that is different from the previous practices. Specifically, it is expected that more than one CR spec will be published before a spec proceeds to the FR status. With this, reviewers can continue to submit their comments and the WG will continue to discuss how to address them, even after a CR is published. There is no longer a formal Last Call.

The e-mail that announced the availability of the current WG draft provided a link to the issues page. As you can see from the link, your recent e-mail about pre-binding was recorded as an issue. Thus, indicating to the readers that there is a known issue in this area. All previous feedback was also recorded in a form of issues and resolution of these issues has been documented.

Regards,

Irene Polikoff


> On Feb 3, 2017, at 11:10 PM, Peter F. Patel-Schneider <pfpschneider@gmail.com> wrote:
> 
> I took a quick look at the recent working draft of
> https://www.w3.org/TR/shacl/ dated 02 February 2017.
> 
> The document says that the next version of the document is planned to be a
> Candidate Recommendation but does not provide a schedule for comments for
> this version of the document.  Nor does the document state a schedule for
> responses to comments on previous working drafts of this document that have
> not yet received substantive responses from the working group.
> 
> In this quick look I examined the document to see if some of the major
> problems with the document have been solved.  What I found is that the three
> major problems I first looked at remain unsolved.  Each of them still needs
> significant work.  Each of them prevents reviewers of the document from
> providing fully informed reviews of the definition of SHACL.  Given that
> there are at least these three major, pervasive problems in the document, I
> don't see that detailed comments on the rest of the document will be very
> worthwhile at this time.
> 
> 
> Pre-binding:
> 
> There has never been a definition of pre-binding that meets the needs of
> SHACL.  The definition of pre-binding in this version of the document is no
> different.  Pre-binding is only defined for a solution mapping and a graph
> pattern.  However, all uses of pre-binding in SHACL are for a solution
> mapping and a query so, in effect, there is no definition of pre-binding at
> all in this document.
> 
> As well, there is no demonstration that the current definition of
> pre-binding is well-behaved even where it is defined.
> 
> The document that is stated to be the source of the definition of
> pre-binding for SHACL is a document that has not been accepted by anyone
> other than the author of the document as far as I can tell.  Saying that it
> is the draft of a WG CG report is giving a false impression of its effective
> status.
> 
> The unsuitability of this definition of pre-binding has been already reported
> in https://lists.w3.org/Archives/Public/public-rdf-shapes/2017Jan/0010.html
> but there is no indication in the working draft that there are any problems
> with pre-binding.  The lack of such an indication in the document means that
> reviewers may miss the fact that much of the document has fundamental
> problems.
> 
> As pre-binding is a central part of SPARQL-SHACL and is also used to
> describe much of SHACL Core it is not possible for reviewers to provide
> fully informed comments on large parts of SHACL at this time.  As there is
> as of yet no suitable definition provided for pre-binding even though the
> problems with it have been known since at least June of 2015 it will be
> better at this late stage to simply remove all parts of SHACL and the SHACL
> document that depend on pre-binding.
> 
> 
> 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?
> 
> 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?
> 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."
> 
> 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."
> 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.  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.
> 
> 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.  As sh:Shape is the natural RDF term for the type of shapes,
> users will use it over sh:NodeShape and sh:PropertyShape.
> 
> 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.
> 
> 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.
> 
> 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.  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.
> 
> 
> Validation results and reports:
> 
> A validation report is the result of validation.  It is an RDF graph where
> some nodes are validation results reporting on constraints that were not
> satisifed.  There are serious problems in how validation reports are
> generated and the form of validation reports.
> 
> The first problem is the generation of validation results.  Throughout the
> definitions of SHACL Core constraint components there is wording like "For
> each value node [...], a validation result MUST be produced with the value
> node as sh:value." and "If [...], a validation result MUST be produced."
> This means that each SHACL processor must produce these validation results
> to be a conforming implementation of SHACL.
> 
> The processor must produce these validation results no matter whether they
> are going to show up in the final validation report or not.  The processor
> must produce these validation results even if it not going to return a
> validation report at all.  This mixing of conformance requirements into the
> definition of validation introduces an unnecessary and problematic
> procedural aspect into the underlying definitions of SHACL.
> 
> Although it is mandated that a SHACL processor much produce these validation
> results it is completely unclear how many must be produced.  A SHACL
> processor may end up checking whether a particular node satisfies a
> particular constraint numerous times.  Must it produce a validation result
> for each of these times?  Must it only produce one validation result for all
> of these times?  Or is the number of times it produce a validation result
> undetermined?  This multiplicity problem can show up at top-level due to
> converging sh:property chains.
> 
> The second problem is the form of a validation report.  There is
> insufficient guidance on how multiple validation results are to be
> produced.  For example, can a single validation result have multiple values
> for sh:value, making it a validation report for multiple violations?
> Similarly, if a shape has two sh:ClassConstraintComponent constraints, can
> a single validation report be used for violations from both of them?
> Without better guidance on these issues it will be very difficult to
> determine just violations occured from a validation report.
> 
> The third problem is just what validation results are to be included in a
> validation report and which of these are to be values of sh:result for the
> single node in the graph that is a SHACL instance of sh:ValidationReport.
> There is "Only the validation results that are not object of any sh:details
> triple in the results graph are top-level results." and "The property
> sh:detail may link a (parent) result with one or more other (child) results
> that provide further details about the cause of the (parent) result."
> So a validation process has to produce validation results which then end up
> in the validation report if they are not values for sh:details triples.
> What happens if a validation result comes from violation of a constraint
> that is both directly at top level (e.g., from a property shape that is value of
> sh:property for a shape that has targets) and not at top level (e.g., from
> the same property shape as before that is linked to the shape with targets
> via a combination of sh:node and sh:property triples)?  Can a SHACL
> processor use sh:detail to collect that otherwise might be top-level
> validation results?
> 
> There are also some other minor problems with validation reports.  For
> example, there is the requirement that "A validation report has exactly one
> value for the property sh:conforms that is of datatype xsd:boolean."
> However, the result of validation is an RDF graph and RDF graphs so this
> requirement doesn't make sense.  The definitions underlying validation
> reports need to be carefully examined to eliminate problems like these.
> 
> Much of the description of how validation reports are generated and what
> they contain need to be rewritten to remove any procedural aspects and to
> suitably describe the contents of validation resports.  As this will change
> large portions of the document, reviewers cannot provide fully informed
> commments on it at this time.
> 
Received on Saturday, 4 February 2017 21:04:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:02:48 UTC