Re: proposal to close ISSUE-75 with a result vocabulary extension

On Mon, Aug 3, 2015 at 4:07 AM, Holger Knublauch <holger@topquadrant.com>
wrote:

> On 8/1/2015 23:39, Dimitris Kontokostas wrote:
>
> Issue 75 needs a way to distinguish violations from errors
>
> The reason the current result vocabulary cannot handle such cases is
> because it is centered around the actual violation instances and thus, when
> an error that cannot produce a violation instance occurs the current
> modeling cannot capture it.
> I do not suggest to change the current design which I find helpful in many
> use cases but we can provide an alternative representation that captures
> the result executions. This is also related to my proposed resolution of
> ISSUE-51.
>
> I suggest we create a new class sh:StatusResult rdfs:subClassOf
> sh:AbstractResult
> that inherits the sh:source from sh:AbstractResult (based on my proposal
> in issue-51)
> and additionally has a property sh:status that represents the status of a
> shape/facet execution:
>
> The values it can take can be:
> sh:Success # no errors found
> sh:Fail # one or more errors found
> sh:Error # an error during execution occurred
> sh:timeout # a timeout occurred
>
> The user can request the preferred result type at execution time. or maybe
> there is a default format (e.g. the current) if no input is given.
>
> This suggestion is based on the following diagram
> https://github.com/AKSW/RDFUnit/blob/master/ns/rdfunit_ontology_diagram.png
>
> In RDFUnit this result type is also extended with a second class (e.g.
> sh:AggregatedResult) to provide the number of errors found and the error
> prevalence. This is open to the WG to accept or not.
>
>
> In a parallel email [1] I have just proposed to add sh:FailureResult and
> the sh:Failure types, to implement your suggestion. I don't think we need
> to return anything on Success, and it would make our lives easier if the
> result graph simply remains empty if everything went alright. (Happy to be
> convinced otherwise, as usual).
>

Reporting on success is needed when one wants to store results and later
produce result statistics such as time to close an "issue", "issue"
re-appearing etc.
if we don't store success we do no have the information on when this test
was run first time and when it re-run (and succeeded) during the lifespan
of a project.
https://www.w3.org/2014/data-shapes/wiki/User_Stories#S46:_Software_regression_testing_with_SHACL

I believe reporting success is quite useful but maybe we can decide on this
during the next call.

Best,
Dimitris


>
> Holger
>
> [1]
> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Aug/0002.html
>
>
>
> Best,
> Dimitris
>
> --
> Dimitris Kontokostas
> Department of Computer Science, University of Leipzig & DBpedia
> Association
> Projects: <http://dbpedia.org>http://dbpedia.org, http://
> <http://aligned-project.eu>http://aligned-project.eu,
> http://rdfunit.aksw.org
> Homepage: <http://aksw.org/DimitrisKontokostas>
> http://aksw.org/DimitrisKontokostas
> Research Group: <http://aksw.org>http://aksw.org
>
>
>


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