ISSUE-229: Draft response

Here is a possible response to the third part of Peter's issue on 
validation reports, see

https://lists.w3.org/Archives/Public/public-rdf-shapes/2017Feb/0001.html


Hi Peter,

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

Not exactly: only those results that are not values of sh:detail are 
*top-level* result. Yet nested results may also become part of the 
result graph.

 > 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)?

In this case it will produce two results, once for the direct invocation 
of the property shape via its target and once for the indirect 
invocation. However, I don't expect this case to ever happen in practice 
because there is no need to assign a target to a property shape that is 
already linked from another shape that also has a target.

 > Can a SHACL processor use sh:detail to collect that otherwise might 
be top-level
 > validation results?

(There is a word missing above, I guess you mean "...to collect results 
that..."?)

No, they would be distinct result nodes.

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

I have clarified the wording so that it now refers to "Each SHACL 
instance of sh:ValidationReport in the result graph", both for 
sh:conforms and sh:result. I also reviewed the rest of section 3.6. If 
anyone finds other specific cases of imprecision, please let us know.


Please let me know where this response could be improved.

Thanks,
Holger

Received on Monday, 20 February 2017 02:38:05 UTC