Re: Comments on Draft #2

On 3/18/2015 3:03, Karen Coyle wrote:
> "Local constraints are evaluated against a given focus node 
> (represented by the variable ?this in SPARQL)."
> - Minor change, but for clarity I think this should read "(*as* 
> represented by....)"

I have just taken out that sub-sentence - it dives into details of the 
SPARQL aspect too early.

>
> "Shapes may be arranged in a specialization hierarchy, allowing some 
> shapes to further narrow down the constraints from other shapes. 
> Current proposals for
> such specialization mechanisms include..."
> - It sounds to me like this is an area that needs further development. 
> How confident are we that these proposed methods "work"? Does this 
> need a note in the document?

I believe the fact that this is an open issue is IMHO already 
sufficiently documented in the lower parts of the spec:

http://w3c.github.io/data-shapes/shacl/#shape-specialization

On the rdfs:subClassOf solution I can confirm that we have many years of 
implementation and usage experience (via SPIN). It depends on the 
outcome of the RDFS entailment topic though.

>
> *** Document ***
>
> 2.1
> has note:
> "sh:Info has also been suggested, but this would work best if there 
> was a deterministic mechanism to identify constraints that need to be 
> checked, so that Info constraints can be bypassed. Related to this, 
> Dimitris also suggested we introduce sh:ValidationResult as a 
> superclass of sh:ConstraintViolation."
>
> *** kc ***
>
> I don't understand about by-passing Info constraints. If a constraint 
> is included in a SHACL document, is it not important enough to be 
> checked, regardless of the level of the error? If a condition is not 
> considered important that constraint should not be included in the 
> particular validation application.
>
> Dimitris says: "Users can optionally execute a validation requiring 
> the reporting of a minimum security level (i.e. Error). In that case 
> the execution engine will skip the execution of all shapes or shape 
> properties that have a weaker security level than the one requested at 
> the execution time" [2]
>
> While this sounds like a good idea, it does require there to be an 
> agreed ranking of errors that are included in SHACL, or a way to 
> customize that ranking, and a way to inter-rank any local sub-classes 
> of sh:ValidationResult. Because of how differently people might see 
> the various errors, I'm skeptical that this ranking would work.

I believe the spec has this covered: it defines the two top-level 
validation result classes sh:Warning and sh:Error, and anyone who wants 
to customize this ranking must extend those two classes if they want to 
be in the corresponding categories. Anyone could add Info too, but those 
would be neither warnings nor errors. The question is whether we want to 
include Info level by default, and I have no strong opinion either way. 
Most logging systems from programming languages have such a capability, 
yet I am unclear about use cases in the context of SHACL.

I believe the remainder of your questions was already addressed.

Thanks,
Holger

Received on Wednesday, 18 March 2015 00:06:36 UTC