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

["ASF subversion and git services (Jira)" <ji...@apache.org>]

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

ASF subversion and git services commented on JENA-2320:
-------------------------------------------------------

Commit 47929688b43ee2e75d817e1eaad4c999191570c3 in jena's branch refs/heads/main from Andy Seaborne
[ https://gitbox.apache.org/repos/asf?p=jena.git;h=47929688b4 ]

Merge pull request #1256 from fkleedorfer/JENA-2320

Add SHACL ValidationListener

> 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.10#820010)

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