[jira] [Created] (JENA-2320) Callback or more detailed report from SHACL validation

["Florian Kleedorfer (Jira)" <ji...@apache.org>]

Florian Kleedorfer created JENA-2320:
----------------------------------------

             Summary: Callback or more detailed report from SHACL validation
                 Key: JENA-2320
                 URL: https://issues.apache.org/jira/browse/JENA-2320
             Project: Apache Jena
          Issue Type: New Feature
          Components: SHACL
            Reporter: Florian Kleedorfer


Summary:
Could we make the ValidationContext constructors protected and use instance methods instead of the current static factory methods (at least for {{create(ValidationContext)}} so that a subclassed ValidationContext can be provided for validation that can also be propagated into the sub-evaluations?

Explanation:

I'm working on code that quite intimately builds on jena's SHACL validation. 
Here's what I'm trying to do: There is a set of nodes V in the data graph G that I am trying to find substitutions for by other RDF nodes. A substitution is valid if no shape has a violation. Now for figuring out which substitutions might be valid, it is not enough to know that shape S is violated on focus node F - I need to know why exactly - i.e. which of my substitutions made the validation fail. I already have a system in place that notices which nodes in V (or their respective substitutes) are looked at during evaluation of S. Also, If the violation is of a simple property shape, I can follow the {{sh:ResultPath}} of the report from F to get to the node; however, if the shape uses an aggregate like {{sh:xOne}}, or a {{sh:node}} the report does not help me find the culprit, I just know it's one of the nodes that were looked at.

I have two ideas how this could be fixed for me:

*More detailed report*
An optional, non-standard report could be generated that always allows me to figure out which of my substitutions for nodes in V (or lack thereof) caused the violation. Maybe it would be enough to pass the validationreport of sub-evaluations through to the main one.

or 

*ValidationCallback*
A callback that I can provide for an evaluation, either as a method param to {{VLib.validateShape()}}, as an optional member in the ValidationContext, or in a ThreadLocal. The latter may be a problem if evaluation is done in multiple threads, so maybe that's not such a great idea. 
The callback would need to be called whenever a reportEntry is added to the context - also in sub-evaluations that use a new context.

One way with minimal impact on the codebase to achieve at least the second of these solutions would be to allow me to extend the {{ValidationContext}} (currently not possible because of the private constructors) and to allow me to return my subclassed {{ValidationContext}} in {{ValidationContext.create(ValidationContext)}} - and maybe also in the other, currently static, factory methods. If that was possible, I could easily intercept {{reportEntry}} methods, which (I hope) is enough.

If that is an option, I'll provide a PR, so that I can make sure the suggested changes really do solve my problem.




--
This message was sent by Atlassian Jira
(v8.20.1#820001)

---------------------------------------------------------------------
To unsubscribe, e-mail: jira-unsubscribe@jena.apache.org
For additional commands, e-mail: jira-help@jena.apache.org