Re: Proposal to close ISSUE-51 as specified in shacl-ref

Hi Dimitris,

On 7/31/2015 23:38, Dimitris Kontokostas wrote:
> Coming back at this after yesterdays call.
> The most common use case that the current approach cannot easily answer is
> "get me all violations results"
> in order to do this we would have to enumerate explicitly all severity 
> levels in the SHACL hierarchy (and possibly the user's extensions), 
> use rdfs reasoning or merge the results in the same dataset with the 
> shacl + user ontology in order to use property paths in the sparql query.

The way that this was designed to work in my draft is that the engine is 
invoked with a minimum severity (see ?minSeverity in The 
engine does always have full access to the shapes graph, and the shapes 
graph may include user-defined extensions, e.g. subclasses of sh:Info. 
RDFS reasoning is not needed here - similar to our handling of 
subclasses elsewhere it is sufficient to just walk the rdfs:subClassOf 
triples. So I cannot follow your line of reasoning above, as the 
question can be answered already. The SPARQL queries do not need access 
to the result classes - they just return SELECT variable bindings and 
the engine turns them into actual results.

Having said this, my draft is too vague right now and implicitly assumes 
that there is a natural ordering of result classes. In response to this, 
I have added a numeric severity index to each severity level, which can 
be used to determine the ordering. Once this number exists, the 
subClassOf hierarchy becomes less relevant, and rather a mechanism to 
communicate the shape of supported properties.

I have created a branch where we can hopefully finalize the revised 
design before making it a submission:

(Only the turtle file is updated - I didn't want to go too far ahead on 
speculative grounds)

See the rest of this email, I believe I have captured the spirit of your 
proposal, albeit with some minor and syntactical differences (see 
below). Please correct me if I have missed the point.

> On the other hand, Hoger's use case about attaching different 
> properties based on the severity level could be possibly handled with 
> shapes, using sh:ConstraintViolation as scope and filtering based on 
> the severity level with sh:hasValue

While I would not object to using shapes here, I think classes already 
provide a very natural way of modeling this. However, now reading about 
your email on ISSUE-75 and the list of SQL error enumerated by Ted in 
the previous call, I can see better why having severity level as a 
separate entity can also have its advantages - especially to better 
distinguish error handling from proper results. Furthermore, although 
the subclasses may in theory add new properties, there is no such 
example in the spec, so the issue is probably not as important as I thought.

> I re-propose my suggestion from 
> with renaming based on the current draft
> ========================
> #remove sh:ResultClass

sh:ResultClass is now replaced by sh:Severity in my branch.

> sh:Result a rdfs:Class # the super class of all results (abstract)
> sh:severity a owl:ObjectProperty ; rdfs:domain sh:Result;
> rdfs:range sh:SeverityLevel .
> #sh:Result also contains sh:source (maybe sh:detail too)
> #Severity definitions
> sh:SeverityLevel a rdfs:Class
> sh:Error a sh:SeverityLevel, owl:NamedIndividual .
> sh:Warn a sh:SeverityLevel, owl:NamedIndividual .

I am very much opposed to adding an (unnecessary) dependency on the OWL 
namespace here. If someone wants to treat the error objects as 
owl:NamedIndividual, then they can add this triple themselves in their 
local copies. But nothing in SHACL requires them to be named OWL 

Likewise I don't see why we should use rdfs:domain and rdfs:range here. 
Either we believe SHACL is suitable to communicate a data structure or 
we don't. rdfs:domain and ranges open up implications about inferencing 
that are unnecessary red herrings here. All we want to communicate is 
"sh:Results can have a sh:severity". SHACL is perfectly capable of doing 
this via sh:property. Again, if anyone wants to use this with RDFS 
tools, they can add these domain triples themselves. Or maybe the WG 
wants to produce an alternative version of the SHACL namespace 
especially for backward compatibility with pure RDFS/OWL tools - this 
would be quite easy to produce based on the shape definitions.

> #We could attach an integer/float property in sh:SeverityLevel, e.g. 
> sh:severityFactor that could be used for ordering severity levels

The term "severity factor" is used for different purposes elsewhere 
( and I guess "factor" 
implies some kind of multiplication. In my draft I am using 
sh:severityIndex for now:

sh:Info  0.0
sh:Warning  1.0
sh:Error 2.0

(all xsd:decimal so that people can place new values in between)

> sh:ConstraintViolation a rdfs:Class; # the existing class in the spec
>    rdfs:subClassOf sh:Result .
> # sh:ConstraintViolation contains sh:root, sh:subject, sh:object, ...
> =============================
> Notes:
> I would also propose a minor renaming that would result in more 
> accurate meaning
> sh:Result -> sh:AbstractResult

Yes renaming to sh:AbstractResult makes sense here.

> sh:ConstraintViolation -> sh:ViolationInstance

For now I picked sh:ValidationResult rdfs:subClassOf sh:AbstractResult. 
I believe the term violation no longer fits the bill because results may 
also include INFO or DEBUG messages. And everything is an "instance"...

Then I added a class sh:Failure to enumerate the various reasons for 
"unexpected" situations such as timeouts:
- sh:IOFailure
- sh:UnsupportedRecursionFailure
- Are there any other identifiable causes?

They are used via sh:failure by the class sh:FailureResult 
rdfs:subClassOf sh:AbstractResult.

Other people may add other result classes such as your accumulated results.

> sh:Result / sh:AbstractResult
> This can be used in case someone wants to provide alternative results 
> for SHACL and means that the minimum information one should have is a 
> severity level and a link to the source (shape/facet/...) this result 
> came from

Another small change I did was to rename sh:source to 
sh:sourceConstraint and to add sh:sourceShape. The reason for this is 
that multiple shapes may share the same sh:Constraint, so we want to 
remember the context (if we can).


> Best,
> Dimitris
> On Thu, Jul 30, 2015 at 4:54 PM, Dimitris Kontokostas 
> < 
> <>> wrote:
>     I have the following comments on the result vocabulary
>     - I would still argue that sh:Error, sh:Warn, etc should be
>     separate property (i.e. sh:level) and not mixed with the result type.
>     - I would also like to have a result superclass so that people can
>     extend the results to other formats.
>     Besides these comments, I am fine with the current design.
>     Best,
>     Dimitris
>     On Tue, Jul 28, 2015 at 2:57 AM, Holger Knublauch
>     < <>> wrote:
>         The current SHACL Reference draft defines a results vocabulary:
>         My proposal is to close ISSUE-51 [1] adopting this design (for
>         now). It's easy to modify at a later stage based on experience.
>         Holger
>         [1]
>     -- 
>     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://, 
> Homepage:
> Research Group:

Received on Monday, 3 August 2015 01:05:50 UTC