Not sure how that could work. You could keep a set of tiples per focus
node validation, add all triples that pass the constraint tests (given
that you somehow are able to reconstruct the triple(s) from the data the
Shacl logic is working on (which is not triples but, in many instances,
sets of nodes - e.g. the result of G.allSP()), and emit the set once
you've established that the complete shape is valid for the focus node.
I would be very sceptical of adding such a special-interest aspect to
code like SHACL that must be relied on and fast as can be.
Having said that, I've wanted to modify the way Jena evaluates SHACL
recently - maybe a way to extend it would be useful (allowing
inheritance or having some kind of callback or somesuch). However, I
found that for my use case, the trick with the graph wrapper that
observes which triples are pulled by SHACL works just fine and is very
simple to implement (the shacl validation algorithm, if you want to
modify it, is not that simple and easy to mess up).
Am 2022-03-09 14:26, schrieb Thomas Francart:
What is VLib.validateShape actually returns the focusNode + Path +
valueNodes that conform to each shape ? or emit them through a listener
?
(
https://github.com/apache/jena/blob/5ce8c141d425655bcaa9d7567117659e502a7ff1/jena-shacl/src/main/java/org/apache/jena/shacl/validation/VLib.java#L89
)
The idea would be to use the Validator as a "filter" that emits the
triples
valid according to shapes, so that they can be aggregated in an output
graph.
