Re: my proposal for ISSUE-51

Yeah, there are two uses of error here.  I would prefer calling error-level
validation results violations but wanted to retain as much of the current
terminology as possible.

In my view, putting violation results together with success and errors is a
bad move.   These are fundamentally different kinds of things.  They need very
different treatments.

peter


On 09/03/2015 06:28 PM, Holger Knublauch wrote:
> 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:44:08 UTC