[
https://issues.apache.org/jira/browse/JENA-2320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17520353#comment-17520353
]
Florian Kleedorfer edited comment on JENA-2320 at 4/11/22 7:36 AM:
-------------------------------------------------------------------
I made a work-in-progress PR, would appreciate feedback on the general approach
https://github.com/apache/jena/pull/1256
Overview of currently implemented design decisions and open issues:
* The {{ValidationListener}} is a private member of the {{ValidationContext}}
* The {{ValidationListener}} can only be added in the {{VLib}}'s methods, not
in the {{ShaclPlainValidator}}
* If no {{ValidationListener}} is provided, the empty implementation
{{NopValidationListener}} is used. One might argue we should just set it null
and make the check at each call (avoiding the overhead of the method call), but
one might also argue that the code is more robust like this. Not sure.
* Maybe I need more callbacks for constraint evaluation. Currently there is one
callback at the beginning of the constraint evaluation and one in the case of a
violation. I might want an extra callback once before each value
node/constraint evaluation for constraints that are evaluated per value node -
and once before the summary value nodes/constraint evaluation (like minCount)
The implementation of the ValidationListener that I'm working on is in a
different project, and it is problem-specific. Do you see the need for a
concrete implementation in jena? As a side note, using the listener for
debugging your shapes seems very useful - you can output an evaluation tree and
show exactly which constraints are satisfied and which fail on which value node
etc, maybe that would be a good thing to have, say, as optional output in the
shacl CLI. I don't want to bloat jena, but if you think it's useful, I could
contribute the listener as well. The current state is here:
https://github.com/fkleedorfer/webofneeds/blob/217d8356a33db3b20d979dbe8cc0b1aea0cd465b/webofneeds/won-utils/won-utils-blend/src/main/java/won/utils/blend/support/shacl/validationlistener/VariableAwareValidationListener.java
was (Author: fkleedorfer):
I made a work-in-progress PR, would appreciate feedback on the general
approach.
Overview of currently implemented design decisions and open issues:
* The {{ValidationListener}} is a private member of the {{ValidationContext}}
* The {{ValidationListener}} can only be added in the {{VLib}}'s methods, not
in the {{ShaclPlainValidator}}
* If no {{ValidationListener}} is provided, the empty implementation
{{NopValidationListener}} is used. One might argue we should just set it null
and make the check at each call (avoiding the overhead of the method call), but
one might also argue that the code is more robust like this. Not sure.
* Maybe I need more callbacks for constraint evaluation. Currently there is one
callback at the beginning of the constraint evaluation and one in the case of a
violation. I might want an extra callback once before each value
node/constraint evaluation for constraints that are evaluated per value node -
and once before the summary value nodes/constraint evaluation (like minCount)
The implementation of the ValidationListener that I'm working on is in a
different project, and it is problem-specific. Do you see the need for a
concrete implementation in jena? As a side note, using the listener for
debugging your shapes seems very useful - you can output an evaluation tree and
show exactly which constraints are satisfied and which fail on which value node
etc, maybe that would be a good thing to have, say, as optional output in the
shacl CLI. I don't want to bloat jena, but if you think it's useful, I could
contribute the listener as well. The current state is here:
https://github.com/fkleedorfer/webofneeds/blob/217d8356a33db3b20d979dbe8cc0b1aea0cd465b/webofneeds/won-utils/won-utils-blend/src/main/java/won/utils/blend/support/shacl/validationlistener/VariableAwareValidationListener.java
> 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: [email protected]
For additional commands, e-mail: [email protected]
