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

Thank you Holger,
It will not be very consistent if we decide to add other types of results
but it's too early to argue about this.
What is definitely needed is a result super class that contains sh:message
and sh:detail.

Dimitris
On May 25, 2015 2:42 AM, "Holger Knublauch" <holger@topquadrant.com> wrote:

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