Re: [pfpschneider@gmail.com: [Moderator Action] Re: Shapes Constraint Language (SHACL) Working Draft of 2017-02-02]

Thanks Eric.

As my summary below reflects the current state of affairs, I think a response to Peter should be “Yes, these message overrides previous messages on these comments”.

Anyone sees an issue with this?

Eric, could you advise what needs to be done about this document https://www.w3.org/TR/shacl-abstract-syntax/ <https://www.w3.org/TR/shacl-abstract-syntax/> to reflect the WG decision not to continue with it and remove it from the recommendation track? 
The wiki documents this https://www.w3.org/2014/data-shapes/wiki/Main_Page <https://www.w3.org/2014/data-shapes/wiki/Main_Page>, but the document itself (the published draft and the editors draft) does not, so it may be misleading. Peter just requested a response to this email https://lists.w3.org/Archives/Public/public-rdf-shapes/2016Aug/0011.html <https://lists.w3.org/Archives/Public/public-rdf-shapes/2016Aug/0011.html> which is entirely about the abstract syntax document.

Regards,

Irene

> On Feb 6, 2017, at 9:36 AM, Eric Prud'hommeaux <eric@w3.org> wrote:
> 
> The attached email was in response to email to both of:
>  public-rdf-shapes
>  public-data-shapes-wg.
> Peter is not a WG member so I'm forwarding his reply to the WG list.
> Please try not to cross-post to both lists as this problem will occur
> every time a non-WG-member responds to such a message.
> 
> -- 
> -ericP
> 
> office: +1.617.599.3509
> mobile: +33.6.80.80.35.59
> 
> (eric@w3.org)
> Feel free to forward this message to any list for any purpose other than
> email address distribution.
> 
> There are subtle nuances encoded in font variation and clever layout
> which can only be seen by printing this message on high-clay paper.
> From: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
> Subject: [Moderator Action] Re: Shapes Constraint Language (SHACL) Working Draft of 2017-02-02
> Date: February 6, 2017 at 2:07:11 AM EST
> To: Irene Polikoff <irene@topquadrant.com>
> Cc: "<public-rdf-shapes@w3.org>" <public-rdf-shapes@w3.org>, public-data-shapes-wg <public-data-shapes-wg@w3.org>
> 
> 
> Does this message override the previous messages from working group members
> related to this comment?
> 
> Peter F. Patel-Schneider
> 
> On 02/05/2017 06:58 PM, Irene Polikoff wrote:
>> Peter,
>> 
>> I believe most of the comments from
>> https://lists.w3.org/Archives/Public/public-rdf-shapes/2016Aug/0005.html e-mail have
>> been resolved and responded to in some of the previous communications. Many
>> have been recorded as issues, but a couple of the comments may not have been
>> responded to yet. Since this e-mail contained many different comments which
>> were discussed and addressed individually and in different communication
>> threads over the last 6 months, I think it would be a complex undertaking for
>> an interested third party to comb through and track each one.  For this
>> reason, I went through the text of the original e-mail and, for each
>> individual comment, provided below an in-line response that corresponds to the
>> current status of the document.
>> 
>> In four cases, it was not clear to me what issue was being hinted at and
>> whether it was still relevant. I have indicated this in the response to them
>> with “please clarify”.
>> 
>> To facilitate better clarity and transparency in tracking individual comments
>> to their resolution, it would be appreciated if you responded to each
>> clarification request (assuming the original comment is still relevant) in a
>> separate e-mail titled with the topic of the comment e.g., "status of
>> $shapesGraph is unclear”.
>> 
>> Thanks,
>> 
>> Irene Polikoff
>>> 
>>> Here are a few of the problems with the current public working draft I found
>>> during a quick scan of it.
>>> 
>>> * pre-binding
>>> 
>>> SPARQL does not evaluate variables that occur in basic graph patterns.  This
>>> means that the definition of pre-binding has unusual behaviour.  For
>>> example, the normative SPARQL definition of sh:class will return validation
>>> results for every pair of nodes in the graph such that there is an
>>> rdf:type/rdfs:subClass* path from the first to the second.
>>> 
>>> This problem affects many parts of the definition of SHACL.  It means that
>>> the normative definition of many SHACL constructs is counter to intuitions.
>>> This problem is not ameliorated by the caution box in Appendix B.
>> RESPONSE: The definition of pre-binding has been significantly changed since
>> the question was asked. ISSUE-222 has been opened to track your more recent
>> comments on this topic. Note that the normative definitions of SHACL Core no
>> longer rely on SPARQL.
>>> * syntax of SPARQL variables
>>> 
>>> SPARQL treats $ and ? as equivalent so $PATH and ?PATH both refer to the
>>> PATH variable.  SHACL uses $ as a special marker and includes $ and ? as
>>> part of the variable.
>>> 
>>> Would ?PATH be substituted as $PATH is?  If a SPARQL query for a SHACL
>>> constraint only used ?this would the variable this be pre-bound?
>> RESPONSE: Yes both are treated uniformly, and in 6.2.3.1 the spec only refers
>> to <code>PATH</code> by its variable name.
>>> * pre-binding optional?
>>> 
>>> "SPARQL variables using the $ marker represent external values that must be
>>> pre-bound or substituted in the SPARQL query before execution."
>>> "When SPARQL constraints are executed, the validation engine should pre-bind
>>> values for these variables."
>>> Are some $-marked variables not necessarily pre-bound, counter to the
>>> earlier requirement?
>> RESPONSE: All $-marked variables must be prebound with the exception of $PATH
>> which is substituted - as explicitly stated in section 1.6 (see response below).
>>> * $PATH vs other $-prefixed variables
>>> 
>>> The variable PATH is treated specially in SHACL.  However, the general
>>> description of $ does not specially call out PATH:
>>> "SPARQL variables using the $ marker represent external values that must be
>>> pre-bound or substituted in the SPARQL query before execution.”
>> RESPONSE: Section 1.6 now states:
>> 
>> SPARQL variables using the |$| marker represent external bindings
>> <https://www.w3.org/TR/shacl/#dfn-binding> that are pre-bound
>> <https://www.w3.org/TR/shacl/#dfn-pre-binding-of-variables> or, in the case
>> of |$PATH|, substituted in the SPARQL query before execution. Also note that
>> section 1.6 is not normative.
>>> * $value
>>> 
>>> $value is used in many ASK queries.  However the definition of ASK
>>> validators does not appear to pre-bind value.
>> RESPONSE: Section 6.3 has just been updated to clarify that $value is
>> pre-bound to the value node.
>>> * aggregation
>>> 
>>> The prohibition "Furthermore, any query that uses the variable $this in an
>>> aggregation is invalid." is vague.  It appears to disallow the use of $this
>>> in any part of the SPARQL 1.1 aggregation machinery, as the pointer in the
>>> sentence is to Section 11 of the SPARQL specification.  This would rule out
>>> all of the examples of aggregation in the SHACL document.
>> RESPONSE: Aggregation is no longer mentioned anywhere in the SHACL document
>>> * ASK validators syntax
>>> 
>>> The syntax for ASK queries in SPARQL 1.1 is
>>>  "ASK" DatasetClause* WhereClause SolutionModifier
>>> The syntax for WhereClause is
>>>  'WHERE'? GroupGraphPattern
>>> The syntax for EXISTS constructs SPARQL 1.1 is
>>>  'EXISTS' GroupGraphPattern
>>> Stripping the ASK from the beginning of an ASK query does not generally end
>>> up with a GroupGraphPattern that can be used as the argument for EXISTS.
>>> 
>>> It appears that the values of sh:ask are never used as ASK queries by SHACL
>>> processors.  Why then are these of the form of ASK queries?
>> RESPONSE: This section has been completely changed since you wrote your
>> comment. Please revisit if your concern still applies.
>>> * different levels of SHACL implementation
>>> 
>>> There are several different kinds of SHACL implementations that are hinted
>>> at in the document.
>>> 
>>> "SHACL implementations may, but are not required to, support entailment
>>> regimes."
>>> "Access to the shapes graph is not a requirement for supporting the SHACL
>>> Core language."
>>> "This sections [sic] defines the built-in SHACL constraint components that
>>> MUST be supported by all SHACL validation engines."
>>> "Not all SHACL validation engines need to support this variable."
>>> "The same support policies as for $shapesGraph apply for this variable."
>>> "SPARQL engines with full SHACL support can install a new SPARQL function
>>> based on the SPARQL 1.1 Extensible Value Testing mechanism."
>>> "SHACL validation engines are not required to support any entailment regimes."
>>> "SHACL implementations with full support of the SHACL SPARQL extension
>>> mechanism must implement a function sh:hasShape, ...."
>>> "A SHACL validation engine MUST implement all constructs in the Core of SHACL
>>> (Sections 2, 3, 4). A SHACL engine MAY not implement the other parts of
>>> SHACL."
>>> "Implementations that cover only the the SHACL Core features are not
>>> required to implement these mechanisms or the sh:hasShape function."
>>> "SHACL validation engines MAY pre-bind the variable $shapesGraph to provide
>>> access to the shapes graph."
>>> "A SHACL validation engine MAY use such suggestions to determine which shapes
>>> graph to use for validating a data graph."
>>> "A SHACL validation engine MAY take this information into account to
>>> determine which shapes graph to use for validating a data graph that uses
>>> that ontology or vocabulary."
>>>  
>>> There needs to be a section that explicitly defines the different levels of
>>> implementation.
>> RESPONSE: Majority of the quoted sentences are no longer present in the
>> document. The document explicitly talks about two types of processors (SHACL
>> CORE and SHACL SPARQL) and describes criteria for their conformance.
>>> * order of processing for filters
>>> 
>>> The discussion of how filters are processed appears to be contradictory.
>>> First there is:
>>> "SHACL validation engines MAY alter the order of the depicted steps as long
>>> as the returned validation results are correct."
>>> Later there is:
>>> "Filter shapes MUST be evaluated before validating the associated shapes or
>>> constraints.”
>> RESPONSE: Filter shapes are no longer supported
>>> 
>>> * $shapesGraph
>>> 
>>> The status of $shapesGraph is unclear:
>>> "SPARQL variables using the $ marker represent external values that must be
>>> pre-bound or substituted in the SPARQL query before execution."
>>> "SHACL validation engines MAY pre-bind the variable $shapesGraph to provide
>>> access to the shapes graph.”
>> RESPONSE: Please clarify the issue. What is unclear?
>>> * circular filters
>>> 
>>> What happens if a shape is one of its own filters?
>> RESPONSE: Filter shapes are no longer supported
>>> 
>>> * EXISTS and blank nodes
>>> 
>>> The definition of ASK binds the value variable and then uses it inside an
>>> EXISTS.  The definition of SPARQL provides a counter-intuitive result if
>>> this variable is bound to a blank node, resulting in, for example, a
>>> sh:class constraint with class ex:C returning no violation for _:d in any
>>> data graph containing the triple
>>>  ex:c rdf:type ex:C .
>>> 
>> RESPONSE: The spec no longer relies on SPARQL EXISTS.
>>> * union operations on data graphs and shapes graphs
>>> 
>>> It is unclear just what the data graph and the shapes graph are.  There is
>>> wording that both of these cannot be changed.  However, there is also
>>> wording that various kinds of union operations are to be performed on shapes
>>> and data graphs.
>> RESPONSE: Please clarify the issue.
>>> 
>>> * It is unclear what is meant by:  "The variable $targetNode is assumed to
>>>  be pre-bound to the given value of sh:targetNode."  Is this something that
>>>  SHACL implementations have to do?  There are several occurences of this
>>>  kind of wording.
>> RESPONSE: Please clarify the issue. What is unclear?
>>> * MAY is used in 1.5 but defined in 1.6
>> RESPONSE: May is defined in section 1.3 as follows:
>> 
>> The key words may, must, must not, and should are to be interpreted as
>> described in [RFC2119 <https://www.w3.org/TR/shacl/#bib-RFC2119>].
>>> * "A SHACL engine MAY not implement the other parts of SHACL." reads as if
>>>  no SHACL engine is allowed to implement any non-core part of SHACL.
>> RESPONSE: Quoted text is not in the document
>>> * "The data graph SHOULD include all the ontology axioms related to the data
>>>  and especially all the rdfs:subClassOf triples in order for SHACL to
>>>  correctly identify class targets and validate Core SHACL constraints."
>>>  Data graphs are just graphs.  How thus can SHOULD be applied to them?
>>> 
>>> * "A SHACL validation engine MAY use such suggestions to determine which
>>>  shapes graph to use for validating a data graph."  Can this be done even
>>>  when an explicit shapes graph is provided to the engine?
>> RESPONSE: Quoted text is not in the document
>>> * "The same mechanism applies for ontologies or vocabularies included in the
>>>  shapes graph. The ontology or the vocabulary IRI can point to one or more
>>>  shapes graphs with the predicate sh:shapesGraph. A SHACL validation engine
>>>  MAY take this information into account to determine which shapes graph to
>>>  use for validating a data graph that uses that ontology or vocabulary."
>>>  If there already is a shapes graph in play, why is there any need for a
>>>  different shapes graph to be used?
>> RESPONSE: Quoted text is not the document
>>> * "a deep copy of sh:path as its sh:path"  What is "deep copy" in this
>>>  context?
>> RESPONSE: ‘deep copy’ is not mentioned in the document
>>> * "A filter is a shape in a shapes graph that can be used to limit the nodes
>>>  that are validated against a given constraint or shape."   Are there some
>>>  filters that cannot be used in this way?  Which ones?
>> RESPONSE: Filter shapes are no longer supported
>>> * "The following table enumerates variables that have special meaning in
>>>  SPARQL constraints. When SPARQL constraints are executed, the validation
>>>  engine should pre-bind values for these variables."  However, many other
>>>  variables also need to be pre-bound, such as the variables corresponding
>>>  to parameters.
>> RESPONSE: Please clarify the issue.
>> 
>>> On Feb 5, 2017, at 11:39 AM, Peter F. Patel-Schneider
>>> <pfpschneider@gmail.com <mailto: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.
>>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>> 
>> 
> 
> 
>