[
https://issues.apache.org/jira/browse/JENA-2320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17519481#comment-17519481
]
Florian Kleedorfer commented on JENA-2320:
------------------------------------------
bq. 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.
I interpret this as: the two approaches do not negatively impact ususal
validation usage. (right?)
I was going for minimal impact on existing jena code, that's why I came up with
subclassing the ValidationContext. Good to know you like the idea of a callback
during the validation lifecycle. That would be my preferred approach.
I don't really want the changes in the summary - ideally, I don't even compile
the validation report.
My current approach for tracking the nodes being looked at during validation is
to use a Graph subclass that records certain nodes as they are
requested/reported back. It might not work perfectly for SPARQL Constraints
under some conditions, but otherwise like a charm. Especially for property
paths of length > 1 this is a good solution. Introducing a callback - a really
new perspective for me - might allow me to drop that approach.
However, for that callback, I suggest that I define the callback methods I need
(e.g. something along the lines of {{validationFailed(Shape shape, Node
focusNode, Constraint constraint}} ), other methods can be added
at later point in time - or would you prefer to design a whole
ValidationCallback API for the complete validation process at this point?
Also, are there any issues regarding parallelization of shape validation that I
should be aware of? Is it planned or done already?
> 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]
