Add automated style checking

[uscholdm]

Whatever style conventions we finally agree to, e.g. case for IRIs and annotations, we can REGEX for capitalization either through SHACL or through query. We can address it between onto_tool and the bundle script.

[uscholdm]

@rjyounes, @sa-bpelakh, @Jamie-SA I think we do a lot of this now, what is the situation?

[rjyounes]

Currently we use SHACL to check:

• Min 1 definition - should really be exactly one with either no language tag or a specific tag
• Exactly one prefLabel - should really be exactly one with either no language tag or a specific tag
• Lowercase labels in properties
• Title case label in classes

Additions to get full coverage of the style guide:

• Add the sentence case check to skos:definition, skos:scopeNote, skos:note, and skos:editorialNote. A sentence case shape is defined but not used; perhaps this wasn't working?
• Check that rdfs:label and rdfs:comment are not used anywhere except in the rdfsAnnotations ontology that is created during the release. We have to make sure the check applies before this file is created.

I also see the need for some refactoring:

• Cardinality 1 is enforced in the Title Case, Lower Case, and Sentence Case shapes. Rather than mixing concerns, these should be 2 distinct shapes (one for prefLabel, one for definition) that can be shared by classes and properties.

[uscholdm]

Min 1 definition - should really be exactly one with either no language tag or a specific tag

Min 1 and exactly 1 are not the same meaning. Not sure what you mean here. We generally avoid min 1 in favor of someValuesFrom

[rjyounes]

I mean: you should have exactly one definition and exactly one prefLabel, unless they have different language tags.

[sa-bpelakh]

We can definitely augment the current checks to support the extra suggestions you made. I have become a bit disillusioned with SHACL with respect to reporting the context of complex validations - i.e. if you have some simple sh:property for a value constraint, the report entry will indicate the erroneous value and the nature of the violation, but for more complex conditions build with sh:or, you will get something like OR constrain violated with no further info.

We should create a small test-suite covering the sort of issues we want to detect, and perhaps convert some of the SHACL shapes into SPARQL queries that would provide better information about the failures.