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