Persisting validation results

[nicholascar]

• removed duplicated content about profiling background which is now in PROF
• added a new Packaging SHACL motivation and subsection to do PROV-O-style provenance of validation

See this rendered at https://raw.githack.com/w3c/data-shapes/refs/heads/profiling-multi-issue/shacl12-profiling/index.html

[mgberg]

Section 5 of the document still needs to be updated, e.g., to account for the new classes and the removal of ProcessorConfiguration.

[nicholascar]

Section 5 of the document still needs to be updated, e.g., to account for the new classes and the removal of ProcessorConfiguration.

I've done this Matt. Next on to Sect 4

[ajnelson-nist]

After discussion on the figure heading Section 5, I had a question on cardinalities: Say I have a data graph that uses two shapes graphs:

ex:DG sh:shapesGraph ex:SG1, ex:SG2 .

How many sh:ValidationReports should there be? 1 or 2?

On the call this morning, we confirmed just 1. Suppose SG2 just contains sh:deactivated for some shapes in SG1. This is also consistent with @mgberg 's separation of the various meanings of "shapes graph" - the shapes graph used for validation being built from all shapes graphs referenced by linking sh:shapesGraph. The 1 ValidationReport should link both shapes graphs with sh:usedShapesGraph.

It could be helpful to list cardinalities in the edges of Figure 3.

[mgberg]

It could be helpful to list cardinalities in the edges of Figure 3.

And if there are cardinalities, add them into the shapes.

[mgberg]

We may want to provide more guidance/clarity around the usage of sh:usedShapesGraph, i.e., would it be used to reference:

• The provided shapes graph (and any graphs that are referenced by sh:shapesGraph), i.e. the root(s) of import closure
• The set of all graphs in the shapes graph after import closure starting at the above root(s)
• Dealer's choice

[nicholascar]

I had badly copied and pasted material there. Fixed with Commit 98a2e36.

I don't think we should mention anything to do with the import closures here as the advice should be given in Core as this document proposes to just follow the Core mechanism for validation.

[nicholascar]

After discussion on the figure heading Section 5, I had a question on cardinalities: Say I have a data graph that uses two shapes graphs:

ex:DG sh:shapesGraph ex:SG1, ex:SG2 .

How many sh:ValidationReports should there be? 1 or 2?

On the call this morning, we confirmed just 1. Suppose SG2 just contains sh:deactivated for some shapes in SG1. This is also consistent with @mgberg 's separation of the various meanings of "shapes graph" - the shapes graph used for validation being built from all shapes graphs referenced by linking sh:shapesGraph. The 1 ValidationReport should link both shapes graphs with sh:usedShapesGraph.

It could be helpful to list cardinalities in the edges of Figure 3.

As per my comment to @mgberg's point above: we should defer to Core for all these kinds of things and only offer advice beyond what Core is doing. Core contains the information about performing validation, assembling inputs etc. so we shouldn't touch those.

[mgberg]

we should defer to Core for all these kinds of things and only offer advice beyond what Core is doing. Core contains the information about performing validation, assembling inputs etc. so we shouldn't touch those.

Hmm. Where would that go in Core? This provenance feature is not discussed in Core, and I don't really think there's any language around tracking the graphs that were imported or not in Core, just the procedure used to collect them and that they get merged into one union graph. Unless that changes, I don't really see how sh:usedShapesGraph could be used for anything other than the root(s) of imports.

Actually, it may be worse than that- if you provide a graph of shapes to a validator (i.e. not via sh:shapesGraph), then would there even be a URI associated with the shapes graph based on the current language in Core? Similarly, would there be a URI for the data graph based on the language in Core (as it currently assumes that the data graph is complete and does no closure of its own, meaning you would have to do any merging necessary in advance)?