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

Hi Dimitris,

please find attached an updated proposal for the result classes. See the 
diagram for an overview. There are basically four result types in the 
system vocabulary that users can instantiate: sh:Info, sh:Warning, 
sh:Error and sh:FatalError. These are instances of the metaclass 
sh:ResultClass (so you could say rdfs:range sh:ResultClass to capture 
severity levels for your aggregated results). The result types are also 
classes and are arranged in a subClassOf hierarchy. I believe this is 
the most flexible approach, and I hope this works for you too.

Thanks
Holger


On 5/22/2015 20:57, Dimitris Kontokostas wrote:
>
>
> On Fri, May 22, 2015 at 11:47 AM, Holger Knublauch 
> <holger@topquadrant.com <mailto:holger@topquadrant.com>> wrote:
>
>
>
>     On 5/22/15 6:10 PM, Dimitris Kontokostas wrote:
>>
>>
>>     On Fri, May 22, 2015 at 9:49 AM, Holger Knublauch
>>     <holger@topquadrant.com <mailto:holger@topquadrant.com>> wrote:
>>
>>         On 5/22/2015 16:41, Dimitris Kontokostas wrote:
>>
>>             I suggest we turn sh:Error, sh:Warn, ... to owl
>>             individuals and connect them to the result with a
>>             property like sh:severity
>>
>>
>>         I have not yet understood why you prefer them to be
>>         instances. Let's try again. I believe classes would be
>>         cleaner because then we can more transparently add different
>>         properties that may only be relevant for that subclass. Why
>>         would it be better to have
>>
>>         [
>>             rdf:type sh:Result ;
>>             sh:severity sh:Error ;
>>         ]
>>
>>
>>     If you can model a clean way of having other types of results
>>     e.g. shx:AggregatedResult (that also need severity) and
>>     sh:ConstraintViolation both as subclasses of sh:Result with
>>     sh:Error, etc as classes I would be happy to accept it.
>
>     Ok, what about severity which points at classes-as-values. This is
>     nothing special - they don't need to be individuals for that. To
>     make it cleaner, we could introduce a metaclass for the various
>     kinds of errors, e.g.
>
>     sh:Error a sh:ResultClass ; rdfs:subClassOf sh:ConstraintViolation .
>
>
> right, I meant owl:NamedIndividual . This is how I define all the 
> choices in the RDFUnit vocabulary [1]
> so sh:Error a sh:ResultClass, owl:NamedIndividual but I guess we are 
> free to skip the last part
>
> With your suggestion I see you can define the severity level for the 
> sh:Constraint violation, by making sh:Error a subclass of 
> sh:Constraint violation.
> How would for example, sh:AggregatedResult define severity levels?
> I got kind of confused with the namings so far so here I go again with 
> my proposal.
>
> sh:AbstractResult a rdfs:Class # the super class of all results
> sh:severity a owl:ObjectProperty ;
>   rdfs:domain sh:AbstractResult;
>   rdfs:range sh:SeverityLevel .
>
> #sh:AbstractResult may additionally contain sh:source or other 
> properties we may choose (not 100% sure about sh:detail)
>
> sh:SeverityLevel a rdfs:Class
> sh:Error a sh:SeverityLevel, owl:NamedIndividual .
> sh:Warn a sh:SeverityLevel, owl:NamedIndividual .
> sh:ContraintViolation a rdfs:Class; # your existing class in the spec
>    rdfs:subClassOf sh:AbstractResult .
> # sh:ConstraintViolation may contain sh:root, sh:subject, ...
>
> #possible official / unofficial extension
> shx:AggregatedViolation a rdfs:Class;
>    rdfs:subClassOf sh:AbstractResult .
> # shx:AggregatedViolation may contain 
> shx:violationCount, shx:violationPrevalence, ...
>
> if this does not work for you, could you make a suggestion that allows 
> the definition of e.g. shx:AggregatedViolation with the ability to 
> define severity levels?
>
> Dimtiris
>
> [1] https://github.com/AKSW/RDFUnit/blob/master/ns/core.ttl#L679-L779
>
>
>     (you are right that we could keep ConstraintViolation as an
>     "abstract" superclass for error and warning and only add sh:Result
>     as its parent class.)
>
>     Holger
>
>
>>
>>         This feels redundant to me - there can only be one value for
>>         severity anyway, so we would save one triple and get the
>>         inheritance relationship for free. Furthermore sh:Error may
>>         have sh:fix while sh:Info may not, and this is best expressed
>>         via classes IMHO.
>>
>>         Thanks,
>>         Holger
>>
>>
>>
>>
>>
>>     -- 
>>     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
>>
>
>
>
>
> -- 
> 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
>