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

Peter,

This e-mail https://lists.w3.org/Archives/Public/public-rdf-shapes/2016Aug/0011.html <https://lists.w3.org/Archives/Public/public-rdf-shapes/2016Aug/0011.html> is entirely about issues with and the “negative utility” of the abstract syntax document.

WG has decided not to proceed with this document. It is not on the recommendation track. 

I see that the document still says the following which is no longer correct as the decision was made:

"This is currently a Working Draft. It is not decided whether this will be a Working Group Note, a Working Group Recommendation, or an appendix to the SHACL specification."

The WG will update this statement to clarify the status of the document.

Regards,

Irene Polikoff

> On Feb 5, 2017, at 11:39 AM, Peter F. Patel-Schneider <pfpschneider@gmail.com> wrote:
> 
> It is likely that some time in the future the working group will be asking to
> advance this document along the recommendation track.  One of the requirements
> for such advancement is that comments on the document have received a public
> substantive response from the working group.
> 
> It is not the responsibility of commenters to keep track of whether the
> working group has provided a substantive response, or indeed any response at
> all to their comments, although they can, of course, mention that they have
> not received what they consider to be an appropriate response to one or more
> of their comments.
> 
> If you want to see comments that have not yet received complete substantive
> responses, you can look at
> https://lists.w3.org/Archives/Public/public-rdf-shapes/2016Aug/0005.html and
> https://lists.w3.org/Archives/Public/public-rdf-shapes/2016Aug/0011.html
> 
> Peter F. Patel-Schneider
> Nuance Communications
> 
> On 02/04/2017 04:03 PM, Irene Polikoff wrote:
>> Peter,
>> 
>> My guess is that 80+% of comments submitted to the WG to date came from you. I believe the WG feels it has been diligently recording all comments and documenting discussions about them and their resolution in the WG meeting minutes, issues list and on its wiki. 
>> 
>> Having said this,  if you feel that some of your comments have not received a response and that these comments are still valid given the current draft, I suggest you resubmit them.
>> 
>> Regards,
>> 
>> Irene Polikoff
>> 
>>> On Feb 4, 2017, at 6:34 PM, Peter F. Patel-Schneider <pfpschneider@gmail.com> wrote:
>>> 
>>> I will discuss the apparent disconnect between the W3C process document and
>>> what you have said that you have heard with W3C management.
>>> 
>>> It is indeed not the case that all comments need to be resolved to the
>>> satisfaction of the commenter.  I was not implying that such satisfaction is
>>> necessary, just contrasting what is the case with your statements that all
>>> comments have given rise to issues that have been resolved by the working
>>> group.  However, it is part of W3C process that all comments need a
>>> substantive response from the working group and several comments have not had
>>> a substantive response and a few have not had a response at all.
>>> 
>>> Peter F. Patel-Schneider
>>> Nuance Communications
>>> 
>>> 
>>> On 02/04/2017 02:24 PM, Irene Polikoff wrote:
>>>> Peter,
>>>> 
>>>> The expectation of multiple CR publications as part of the new process was verbally communicated by the W3 management to myself and Ted Thibodeau in a phone call. I can not provide a link to a document that describes the process of multiple CRs (e.g., CR-1, CR-2, etc.). Please feel free to contact W3M with this request.
>>>> 
>>>> They have also explained that while the WG must discuss all comments and make a decision on how and whether to address them, having an explicit expression of satisfaction from a commenter was not a requirement for proceeding to CR or TR.
>>>> 
>>>> I agree that annotating the document with the information about substantive open issues is a good practice to follow.
>>>> 
>>>> Regards,
>>>> 
>>>> Irene Polikoff
>>>> 
>>>>> On Feb 4, 2017, at 4:50 PM, Peter F. Patel-Schneider <pfpschneider@gmail.com> wrote:
>>>>> 
>>>>> I don't see anywhere that the expectation is that more that one Candidate
>>>>> Recommendation will be published before a W3C technical report proceeds to
>>>>> Proposed Recommendation or Recommendation status.  The W3C process document of
>>>>> 1 September 2015 states that the expected next step of after Candidate
>>>>> Recommendation publication is Proposed Recommendation.  Please provide support
>>>>> for your claim.
>>>>> 
>>>>> Having a link to an issues pages from an email announcement is not a
>>>>> substitute for having a note in the document.  It is particularly not an
>>>>> effective replacement when the problem is substantial, technical, and
>>>>> long-running.
>>>>> 
>>>>> Most of the comments on previous versions of the document did not give rise to
>>>>> tracked working group issues.  Many of these comments have not had an explicit
>>>>> expression of satisfaction from the commenter.  Some of these comments have
>>>>> not received any response from the working group at all.
>>>>> 
>>>>> Peter F. Patel-Schneider
>>>>> Nuance Communications
>>>>> 
>>>>> 
>>>>> 
>>>>> On 02/04/2017 01:03 PM, Irene Polikoff wrote:
>>>>>> 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.
>>>>>>> 
>>>>>> 
>>>> 
>>