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

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

Received on Monday, 6 February 2017 07:07:10 UTC