Mention inferences in validation reports

[robert-david]

When inferencing changes the data graph (because of materializing? or anyways?), the user should somehow be noticed of the changes.
I think this would be important to understand reported violations.

[ajnelson-nist]

This Issue's discussion should be mindful of SHACL 1.0's Section 1.5, and what is allowed to modify the data graph. Or, overlay the data graph?

I think there is other context in #185 , and maybe #183 would help answer data graph expansion/entailment storage questions.

I think it would be helpful to track the provenance of triples added by expansion. Might this need to wait for RDF-1.2 and triple reification?

If tying expansion triples to their generating conditions seems too heavyweight, I'm fine with leaving that out of scope of this Issue. It looks like this Issue has a staring scope of just adding some kind of flag property, e.g., x sh:generated true .. Was this shorter form your objective, @robert-david ?

[afs]

It can get complicated so we probably have to find a building block, not a complete solution for all use cases.

• what is a triple is in the data graph and is inferred?
• what is a triple is in the data graph because it was inferred previously?
• what is a triple is inferred in multiple ways?
• what is rules are "backwards" (calculated on-demand, not inserted into the data graph)

What might be possible is to add to a validation report / have a new kind of report where for a given execution of SHACL shapes, the outcomes are recorded.

One possibility is that inference (as defined in by the SHACL specs) never changes the data graph but instead generates a new graph, leaving it to the application to decide to merge the two to produce a new data graph. This leaves a provenance trail.

[afs]

I think this would be important to understand reported violations.

@robert-david I'm not sure I full understand this.

Could you provide an example, please?

While inference is running, the data graph may have violations which are resolved by later inference steps.

If inference causes violations end-to-end, isn't that, to some extent, a bug in the inference steps?

[robert-david]

@ajnelson-nist @afs
My intention was to indicate if inference was involved in the cause of a violation. Depending on the use case, users might only see the asserted data in the data graph and not the inferred triples. To understand why a violation occurs, it would be helpful to report information if any inferred triples are part of the cause.

[ajnelson-nist]

@robert-david That sounds like an important consideration for node expressions.

[afs]

See the "trace graph" part of the discussion on #325.