Re: Proposal to close ISSUE-51 as specified in shacl-ref

Coming back at this after yesterdays call.

The most common use case that the current approach cannot easily answer is
"get me all violations results"
in order to do this we would have to enumerate explicitly all severity
levels in the SHACL hierarchy (and possibly the user's extensions), use
rdfs reasoning or merge the results in the same dataset with the shacl +
user ontology in order to use property paths in the sparql query.

On the other hand, Hoger's use case about attaching different properties
based on the severity level could be possibly handled with shapes,
using sh:ConstraintViolation as scope and filtering based on the severity
level with sh:hasValue

I re-propose my suggestion from
https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015May/0145.html
with renaming based on the current draft

========================
#remove sh:ResultClass

sh:Result a rdfs:Class # the super class of all results (abstract)

sh:severity a owl:ObjectProperty ; rdfs:domain sh:Result;
rdfs:range sh:SeverityLevel .

#sh:Result also contains sh:source (maybe sh:detail too)

#Severity definitions
sh:SeverityLevel a rdfs:Class
sh:Error a sh:SeverityLevel, owl:NamedIndividual .
sh:Warn a sh:SeverityLevel, owl:NamedIndividual .

#We could attach an integer/float property in sh:SeverityLevel, e.g.
sh:severityFactor that could be used for ordering severity levels

sh:ConstraintViolation a rdfs:Class; # the existing class in the spec
   rdfs:subClassOf sh:Result .
# sh:ConstraintViolation contains sh:root, sh:subject, sh:object, ...
=============================

Notes:

I would also propose a minor renaming that would result in more accurate
meaning
sh:Result -> sh:AbstractResult
sh:ConstraintViolation -> sh:ViolationInstance

sh:Result / sh:AbstractResult
This can be used in case someone wants to provide alternative results for
SHACL and means that the minimum information one should have is a severity
level and a link to the source (shape/facet/...) this result came from

Best,
Dimitris

On Thu, Jul 30, 2015 at 4:54 PM, Dimitris Kontokostas <
kontokostas@informatik.uni-leipzig.de> wrote:

> I have the following comments on the result vocabulary
> - I would still argue that sh:Error, sh:Warn, etc should be separate
> property (i.e. sh:level) and not mixed with the result type.
> - I would also like to have a result superclass so that people can extend
> the results to other formats.
>
> Besides these comments, I am fine with the current design.
>
> Best,
> Dimitris
>
> On Tue, Jul 28, 2015 at 2:57 AM, Holger Knublauch <holger@topquadrant.com>
> wrote:
>
>> The current SHACL Reference draft defines a results vocabulary:
>>
>> http://w3c.github.io/data-shapes/shacl-ref/#results-vocabulary
>>
>> My proposal is to close ISSUE-51 [1] adopting this design (for now). It's
>> easy to modify at a later stage based on experience.
>>
>> Holger
>>
>> [1] http://www.w3.org/2014/data-shapes/track/issues/51
>>
>>
>
>
> --
> 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
>
>


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