To track how the validity of a graph changes over time and ensure validation results are reproducible, it would be convenient if Validation Report could be self-contained and could carry full context about how it was produced.
Proposed Changes
1. Replace sh:validationReport with its inverse
sh:usedShapesGraph points outward from the report (ValidationReport -> ShapesGraph), but for data graphs the direction is reversed: sh:validationReport points inward (DataGraph -> ValidationReport).
Remove sh:validationReport (domain: DataGraph, range: ValidationReport) and introduce sh:validatedDataGraph or something similar (domain: ValidationReport, range: DataGraph). This makes the report the subject of both graph references, consistent with sh:usedShapesGraph.
The profiling spec's CONSTRUCT rule deriving sh:conformsTo would be updated to query from the report outward rather than from the data graph inward.
2. Introduce class for validator configuration
The spec notes that reports "MAY contain additional information such as provenance metadata," but defines no structure for it. Without knowing the implementation, its version, entailment regime, or other processor-specific settings, a validation result cannot be reliably reproduced.
Define sh:ValidatorSettings or similar as a class whose properties are intentionally opaque to the SHACL spec. Implementations may hang whatever they need on instances of it, such as implementation name, version, entailment regime, etc., then link to it fromthe report via sh:usedValidatorSettings or similar (domain: ValidationReport, range: sh:ValidatorSettings).
To track how the validity of a graph changes over time and ensure validation results are reproducible, it would be convenient if Validation Report could be self-contained and could carry full context about how it was produced.
Proposed Changes
1. Replace
sh:validationReportwith its inversesh:usedShapesGraphpoints outward from the report (ValidationReport -> ShapesGraph), but for data graphs the direction is reversed:sh:validationReportpoints inward (DataGraph -> ValidationReport).Remove
sh:validationReport(domain:DataGraph, range:ValidationReport) and introducesh:validatedDataGraphor something similar (domain:ValidationReport, range:DataGraph). This makes the report the subject of both graph references, consistent withsh:usedShapesGraph.The profiling spec's CONSTRUCT rule deriving
sh:conformsTowould be updated to query from the report outward rather than from the data graph inward.2. Introduce class for validator configuration
The spec notes that reports "MAY contain additional information such as provenance metadata," but defines no structure for it. Without knowing the implementation, its version, entailment regime, or other processor-specific settings, a validation result cannot be reliably reproduced.
Define
sh:ValidatorSettingsor similar as a class whose properties are intentionally opaque to the SHACL spec. Implementations may hang whatever they need on instances of it, such as implementation name, version, entailment regime, etc., then link to it fromthe report viash:usedValidatorSettingsor similar (domain:ValidationReport, range:sh:ValidatorSettings).