my proposal for ISSUE-51

This proposal for SHACL results divides them into violations, which are
encoded into an RDF graph, and other kinds of results, which are not.

Description:

Validation normally produces validation results that provide information on
the status of the validation, i.e., how the top-level constraints are
violated.  (It may be possible to invoke SHACL in a mode where only summary
information about violations is produced.)  These results are encoded in an
RDF graph that can be examined when validation finishes.

Validations results include information about how severe the violation was,
which can be either informational, a warning, or an error.  Validation
results also include information about which shape was violated and which
data contributed to the violation.

A validation result is an RDF node with type sh:ValidationResult.  The
severity of the violation is its value for sh:severity, which
can be either sh:Information, sh:Warning, or sh:Error.  The shape that was
violated is its value for sh:sourceShape.  [... other information in
violation results ...]

As well, many SHACL API calls return a boolean value that indicates whether
validation was successful.  SHACL API calls also signal errors that were
encountered.  Validation is sucessful if no error is encountered and no
validation result with error severity is produced.  Errors are things like
the implementation consuming too many resources or encountering malformed
SHACL constructs.  When a SHACL error is encountered SHACL implementations
MUST signal the error and MUST either terminate immediately or continue.  If
a SHACL implementation terminates prematurely due to an error it SHOULD make
a validation results RDF graph available containing the violations
encountered up to the point of the error.

Received on Friday, 4 September 2015 00:40:28 UTC