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

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

Received on Sunday, 5 February 2017 00:04:24 UTC