SHACL validation

[mmccool]

• when and how SHACL validation should be done?
• error report
• extension validation

[AndreaCimminoArriaga]

SHACL should be used after registering a TD. The TD must be translated into any RDF representation, and then, the SHACL applied. Consider that SHACL shape must contain restrictions for all the ontologies used in the document, not only the TD. As I mentioned in a previous issue, the service Astrea allows to generate quite rich SHACL shapes automatically from a given ontology. It could be used for generating a first version of the TD shape, however, consider that if someone uses the TD with SAREF that shape will not be enough (although it will still validate the TD part).

[vcharpenay]

for generating a first version of the TD shape

There already is a SHACL shape for TD documents. It is in fact the main source for rendering the TD spec (see templates.sparql).

An SHACL definition that would be automatically generated from Astrea coulnd't be complete, by the way. It would miss e.g. default values and a higher-level constraint that at least one security configuration must be provided.

[AndreaCimminoArriaga]

There already is a SHACL shape for TD documents. It is in fact the main source for rendering the TD spec (see templates.sparql).

That is great I will start using it in my library for translating TDs from JSON-LD 1.1 framed to RDF and back.

An SHACL definition that would be automatically generated from Astrea couldn't be complete, by the way. It would miss e.g. default values and a higher-level constraint that at least one security configuration must be provided.

That is true, but in the assumption there was no shape the one generated by Astrea could be a good start. Even if the shape may not include default values, all the structural restrictions defined in the ontology would be included (like the security configuration). Anyway having already a shape is a very good new.

[mmccool]

I am trying to add a formal definition of validation for inclusion in the TD spec. Please see https://github.com/w3c/wot-thing-description/pull/1085 Note that my definition of "Intermediate" validation includes SHACL validation and would be appropriate for directories.

[mmccool]

• SHACL can be expensive (needs RDF processing...), few implementations
• Does catch more things than JSON Schema Conclusion:
• MUST: Minimal validation (JSON Schema). Validation of directory and enrichment extensions is mandatory (MUST). Validation of other extensions (iot, qudt, etc). is optional (MAY).
• MAY: Do Basic (SHACL) validation. MUST do Basic validation if directory supports SPARQL. Validation of extensions is optional (if do so... SHOULD validate built-in extensions like discovery and enrichment, MAY validate other extensions)

[AndreaCimminoArriaga]

I have one question regarding SHACL. Why is it MAY? it seems that SHACL is somehow linked to SPARQL in the previous comment and that is the reason of the MAY. Nevertheless, TDs are JSON-LD framed documents, i.e., RDF, regardless if the directory implements or not SPARQL. Therefore, regardless the SPARQL since TDs are a form (or kind of) RDF they MUST be validated as well using SHACL right?

Maybe, could we say that TDs MUST be validated with one of these two JSON Schema or SHACL, and optionally both?

[egekorkan]

One comment regarding validation would be that JSON Schema is not standardized and SHACL is so we can impose SHACL validation with less problems. Also, a reason for MAY would be that validation can be in different ways

[mmccool]

@egekorkan makes a good point about SHACL being standard and JSON Schema not, but at this point we are basing validation on JSON Schema. We should revisit in Discovery (and TD) 2.0, though.