Support of audit report

[griddigit-ci]

Hello,

There is one use case / feature which is good to cover. The is the ability to report on the status of execution of the constraints at NodeShape, PropertyShape, SPARQL, ...
Basically to have information if all SHACL shapes that are defined are processed by the engine. Maybe it could be done as an extension of the validation report or have another report for this purpose.

Now if we run a validation, we are not sure if the data conforms or the shapes are actually not processes.

[JervenBolleman]

Yes, similar, it would be very nice to have report for each shape how many instances were found in the data. To avoid the problem of the shape not being found at all in the data due to some error in missing the key type or property.

[tpluscode]

I think this should be already possible by adding non-violation results for successfully validated properties/nodes.

Related to #192

[afs]

Isn't this the shapes that don't get processed?

Non-violation results helps but there needs to be the set of shapes expected to run, and that isn't all shapes because some shapes are for modularization.

Maybe we need a property to say "expected to run". c.f. sh:closed.

[tpluscode]

Of course, you make a valid point.

I could also be possible to approach from the data graph. Something like coverage implemented by @bergos. An information of which resources and paths were effectively targeted by the shapes.

[VladimirAlexiev]

@afs

some shapes are for modularization.

Won't such shapes be invoked by higher-level shapes?
Can you show an example of a modularization shape that is not invoked?

[afs]

Won't such shapes be invoked by higher-level shapes?

A set of "all shapes" minus "shapes used" will contain all levels of shapes

Can you show an example of a modularization shape that is not invoked?

owl:imports brings in shape libraries. Import does not mean they are all intended to be used.

[VladimirAlexiev]

Thanks Andy, got it.

Maybe we should think about this from the point of view of code profiling.

• How to count invocations when a shape calls another
• how to capture the counts (and other metrics?)
• how to present/ analyze the counts, keeping in mind both coverage of shapes and of data

Relates to

• remove owl:imports sh: from examples #240 that complains that sh shapes are validated unnecessarily
• define SHACL Validation API #214 because this feature should be controllable by the API

[JervenBolleman]

If there would be "count" report, ShACL could take over the usecase of VoID. Which would be quite nice as VoID is not update-able.