Re: shapes-ISSUE-150 (nested severities): Treatment of nested severities [SHACL Spec]

The situation is even worse for components that actually depend on the
severity of their embedded shapes.   One might think that a bunch of related
shapes that all have severity sh:Info would work correctly together, but if
one of these shapes has a sh:not construct that uses another of the shapes the
sh:not will not produce any results because it requires that the embedded
shape produces violations with severity sh:Violation.

Proposal 4:  Do away with severities.

peter

On 04/18/2016 03:50 AM, RDF Data Shapes Working Group Issue Tracker wrote:
> shapes-ISSUE-150 (nested severities): Treatment of nested severities [SHACL Spec]
> 
> http://www.w3.org/2014/data-shapes/track/issues/150
> 
> Raised by: Dimitris Kontokostas
> On product: SHACL Spec
> 
> It is currently not defined (nor there is a WG decision) how nested severities work in SHACL
> 
> for example which severity will be returned if ex:p1 fails due to ex:p2 or due to ex:p3 
> 
> ex:TopShape a sh:Shape
> sh:property [
>   sh:predicate ex:p1
>   sh:severity sh:Warning ;
>   sh:valueShape [
>     a sh:Shape
>     sh:property [
>       sh:predicate ex:p2
>       sh:severity sh:Info ;
>       #.. constraints
>     ]
>     sh:property [
>       sh:predicate ex:p3
>       sh:severity sh:Violation ;
>       #.. constraints
>     ]
>   ]
> ]
> 
> Options:
> proposal 1: take into account only the top severity and ignore all nested severities even if top severity is not defined (default to sh:Violation)
> 
> proposal 2:take into account only the child severities and ignore the top one
> 
> proposal 3: take into account only the top severity only if the child severity is lower, otherwise use the child severity.
> 
> 
>

Received on Monday, 18 April 2016 11:48:35 UTC