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

["Andy Seaborne (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/JENA-2320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17519447#comment-17519447 ] 

Andy Seaborne commented on JENA-2320:
-------------------------------------

Both "more detailed report" and "validation callback" look viable. 

The general issue from my point-of-view is keeping the system general, allow extensions if they do not negatively impact the usual validation usage. These two approach don't seem to do that.

Seeing a PR would be great.

Avoiding ThreadLocal is a good idea. They are tricky and if not needed should be avoided! Callbacks in the validation lifecycle would be good, not just at reportEntry. (ifs that how you are tracking the nodes being looked at during evaluation of a shape?).

If you want to do have the changes in the summary now (ValidationContext constructors protected etc), which looks least impact, so as to make progress,  consider them "experimental" as they have no external change to other users, they can be subject to change/removal if a better way to do comes along when later callbacks are added that's is workable. We have to balance improvement and stability.


> 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
>            Priority: Minor
>
> 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