shapes-ISSUE-96 (Violation IDs): Should the validation results contain stable IDs to indicate the type of violation [SHACL Spec]

shapes-ISSUE-96 (Violation IDs): Should the validation results contain stable IDs to indicate the type of violation [SHACL Spec]

http://www.w3.org/2014/data-shapes/track/issues/96

Raised by: Holger Knublauch
On product: SHACL Spec

In a recent call Harold mentioned that some systems define stable error codes (e.g. numeric codes) to communicate the type of error that has happened. Tools can then display and analyze codes produced by different systems uniformly. I believe SHACL should provide similar capabilities. Without such unique Ids, we would not even be able to check compliance, because validation results that only contain something

[
    sh:message "MinCount validation" ;
    sh:focusNode ex:Instance1 ;
    sh:predicate ex:property ;
]

cannot be reliably tracked or compared. For example they could also be produced as result of a sh:hasValue restriction, which is a very different case. Or there could be multiple identically looking instances that only differ in their message. Messages are a poor way of encoding IDs.

In the current results vocabulary, we are ambiguous about this aspect. We do have the ability to store additional metadata in each validation result, and there are pointers to the sh:sourceShape, sh:sourceConstraint and sh:sourceTemplate that may be used, but we probably should make this a stronger contract so that there is always one Id field present.

PROPOSAL: Validation results should include an ID for each constraint type. These should align with the URIs of the templates and node validation functions in the SHACL system vocabulary.

For example, we could add sh:constraintType sh:hasMinCount which is the function that does the actual test. Of course this does not mean that an implementation actually must use that function, but it provides a very natural and evolutionary design.

Received on Tuesday, 29 September 2015 01:13:29 UTC