search

HW-SWeL / Validata

Online frontend for ShEx-validator for restricted deployment environments
http://hw-swel.github.io/Validata/
MIT License
11 stars 2 forks source link

ShEx and requirement levels #33

Open AlasdairGray opened 9 years ago

AlasdairGray commented 9 years ago

I wonder if the rules are too strict for SHOULD and MAY properties. In the past I've always had these at the '?' or '*' level rather than requiring that they are there. I feel that this better matches the semantics that if they are present then they should match but there is no requirement for them to be present, even when validating at the SHOULD or MAY level.

AlasdairGray commented 8 years ago

Validation errors are not being reported as expected. Regardless of the requirement level, if a rule is broken, e.g. I provide multiple entries for a property but only one is permitted, then an error must be reported not a warning.

Warnings should be used when there is a rule at the SHOULD or MAY level that is not present. The idea is to inform the user that there is potentially more information that could be provided.

Consider the following ShEx

<DistributionLevelShape> {
  `SHOULD` void:vocabulary IRI,
  `SHOULD` dct:created .
}

being validated agains the following RDF

chembl17rdf void:vocabulary ex:vocab1, ex:vocab2.

The first ShEx rule should generate an error as the constraint of only a single vocabulary declaration has been violated, even though it is only a SHOULD level constraint. The second ShEx rule should generate a warning since it has not been matched but it is not violated.

AlasdairGray commented 8 years ago

The distinction is between a rule that is matched and found to be wrong in the RDF that is being validated and a rule that is not matched but marked with a 'SHOULD' or 'MAY' level.

@andrewthecoder how easy is this to change in the code? Is it a UI only fix or something that requires the ShEx validator to change as well?