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: [email protected]
For additional commands, e-mail: [email protected]
