[
https://issues.apache.org/jira/browse/JENA-2320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17523081#comment-17523081
]
Andy Seaborne commented on JENA-2320:
-------------------------------------
Hi [~fkleedorfer]
I'll look at the PR when I get a moment.
bq. are there any issues regarding parallelization of shape validation that I
should be aware of? Is it planned or done already?
No plans from me. I've done some experimental work on parallelism.
There are two cases:
# Parallelism by executing targets in parallel.
# Parallelism by executing constraints as the data builds up in a change.
Case 2 is more complicated. Some constraints are quite simple and test a single
triple (e.g. datatype, nodeKind, ...) so these can be done ahead-of-time and in
parallel. Some require the complete "entity" (e.g cardinality) which can be
parallel at he point of a commit.
Case 1 is simpler to implement and benefits published data (i.e. not updating
while validating).
"shacl valdiate -v" does print some information but putting that in a general
listener framework would much better.
rdfs:seeAlso: https://github.com/TopQuadrant/shacl/pull/139
> 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]
