W3C home > Mailing lists > Public > public-shex-dev@w3.org > November 2017

Re: [shex] Constraint weight annotation

From: Eric Prud'hommeaux via GitHub <sysbot+gh@w3.org>
Date: Tue, 14 Nov 2017 01:12:23 +0000
To: public-shex-dev@w3.org
Message-ID: <issue_comment.created-344112777-1510621941-sysbot+gh@w3.org>
In SHACL, severities are treated as annotations, meaning they have no particular hierarchical semantics and are just copied into error reports. One of the drivers for severity levels was [Google's RDF Validation Workshop submission](https://www.w3.org/2001/sw/wiki/images/0/00/SimpleApplication-SpecificConstraintsforRDFModels.pdf). The SHACL severity model doesn't conveniently address schema.org's needs as they need separate severities for something being missing vs. something present but with the wrong datatype.

One solution to this would be to use @jimkont's approach and expand on the Validata header which declared their own severity strings with a global directive. If we supplement that with a standard set of violations, we could attractively address the schema.org use case:
NEED = *:2; # bad both if it's missing or has the wrong type.
WANT = missing:1, *:2; # lower warning if it's missing.
<IssueShape> {
  WANT :description xsd:string ;
  NEED :creator @<PersonShape> ;
             :assignedTo @<PersonShape>? ;
<PersonShape> {
  WANT foaf:name xsd:string ;
  NEED foaf:mbox IRI
One question with either strategy is what happens with a higher severity nested in a lower severity:
<issue1> :description ""; :creator <x> ; :assignedTo <y> .
<x> ...
<y> :foaf:mbox <mailto:emily@example.org> .
`<y>` is missing a WANTed `foaf:name` but is only being validated for a presumably optional (from the cardinality) `:assignedTo`. A strategy would be to say that only the highest error level keeps something from validating so `<issue1>` is fine even though the object of its `:assignedTo` had a warning.

GitHub Notification of comment by ericprud
Please view or discuss this issue at https://github.com/shexSpec/shex/issues/76#issuecomment-344112777 using your GitHub account
Received on Tuesday, 14 November 2017 01:12:26 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 4 June 2019 11:00:16 UTC