Re: my proposal for ISSUE-51

To me this proposal sounds similar to what is currently in the spec. 
However, the updated proposal supported by myself and (AFAIK) Dimitris 
also allows to represent success and failures. I believe this is useful 
to store and share all possible results, and to display them uniformly.

Your suggestion also reuses the term "Error" in two places. I believe it 
should be either "Failure" or (maybe) "Exception" for what you call 
errors. You state the engine may simply continue if such a failure 
happens, without providing a proper mechanism to communicate such outcomes.

So I don't think this proposal is improving the situation.

Holger


On 9/4/15 10:39 AM, Peter F. Patel-Schneider wrote:
> 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 01:29:11 UTC