Re: shapes-ISSUE-51 (Results Vocabulary): What types of validation results should be returned [SHACL Spec]

I would prefer to have a different kind of flexibility beyond just the
severity level since R2.10.4 is now under consideration
https://www.w3.org/2014/data-shapes/wiki/Requirements#Constraint_Violations_Reporting_Details

I suggest we turn sh:Error, sh:Warn, ... to owl individuals and connect
them to the result with a property like sh:severity
I agree on the need for a superclass like Holger suggests i.e. sh:Result
but this class will contain the most basic needed information like
severity, message and provenance (shapes, details, ...) that is not related
directly to a violation instance

sh:sh:ConstraintViolation will subClass sh:Result and add the existing
extra properties in Holger's draft
This gives way to add other types of results in the future for example
sh:AggregatedViolations as defined in [1] which will report violation counts
Aggregated violations are very useful in big datasets where the error
number can be too high and one needs to have only an overview.
In RDFUnit I additionally define two more restrictive versions of these
result types.

Maybe we don't decide to add other formats in shacl 1.0 but with this
change it will be easy to add them in the future

Best,
Dimitris

[1]
https://github.com/AKSW/RDFUnit/blob/master/ns/rdfunit_ontology_diagram.png



On Fri, May 22, 2015 at 7:59 AM, RDF Data Shapes Working Group Issue
Tracker <sysbot+tracker@w3.org> wrote:

> shapes-ISSUE-51 (Results Vocabulary): What types of validation results
> should be returned [SHACL Spec]
>
> http://www.w3.org/2014/data-shapes/track/issues/51
>
> Raised by: Holger Knublauch
> On product: SHACL Spec
>
> The current draft has vocabulary terms to create Warnings, Errors and
> FatalErrors and a base class sh:ConstraintViolation. I would like to
> generalize this so that we are more flexible.  Specific suggestions:
>
> - Rename sh:ConstraintViolation to sh:Result (or sh:ValidationResult)?
> - Add sh:Info rdfs:subClassOf sh:Result
>
> This would allow users to invoke the engine for non-error/warning checks,
> e.g. to collect general information about the state of the data. Some
> people may introduce ex:Debug rdfs:subClassOf sh:Info, but I don't see that
> as a requirement for the core - as long as the data structure is open,
> anyone can add such subclasses themselves.
>
>
>
>


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