Re: my proposal for ISSUE-51

Hi Peter,

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.


If failure and success results are that problematic and cause so much
discussion I am open to drop them completely. (but if possible leave the
current super-class hierarchy for community extensions)

(It may be possible to invoke SHACL in a mode where only summary information
> about violations is produced.)


This comment indicates that you propose to get them with a different SHACL
mode that reports summary results. Any more details on this? Are these
results in RDF too?

Validation is sucessful if no error is encountered and *no **validation
> result with error severity* is produced


I underlined the problematic part in the proposal. This may cause problems
when nesting constraints with different severity levels.
In Holger's proposal as well as my original suggestion [1] the user
specifies the desired severity level and the engine skips all constraints
with a lower level.
For example, if the user specifies sh:Information level reporting and we
get a violation result with sh:Information then the results of the
validation should be false, not true.
This approach, imho simplifies the handling or errors

[1] (s/security/severity/g)
https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Mar/0011.html


On Fri, Sep 4, 2015 at 4:43 AM, Peter F. Patel-Schneider <
pfpschneider@gmail.com> wrote:

> 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.
> >>
> >>
> >
> >
>
>


-- 
Dimitris Kontokostas
Department of Computer Science, University of Leipzig & DBpedia Association
Projects: http://dbpedia.org, http://http://aligned-project.eu,
http://rdfunit.aksw.org
Homepage:http://aksw.org/DimitrisKontokostas
Research Group: http://aksw.org