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

On Fri, May 22, 2015 at 11:47 AM, Holger Knublauch <>

> On 5/22/15 6:10 PM, Dimitris Kontokostas wrote:
> On Fri, May 22, 2015 at 9:49 AM, Holger Knublauch <>
> 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
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

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?



> (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://
> Homepage:
>  Research Group:

Dimitris Kontokostas
Department of Computer Science, University of Leipzig & DBpedia Association
Projects:, http://
Research Group:

Received on Friday, 22 May 2015 10:58:09 UTC