Skip to main content

Validation of SKOS data

Core constraints​

To render a form, Hanami uses SHACL Core Constraints which are also used to validate the data. The most common validations performed this way are

  • nodeKind: checks if the value is a literal (number, string...) or a URI
  • datatype: used for literals to indicate which type of literal it should be (number, string, ...)
  • class: used for URIs to check if the target is of the correct type.
  • minCount/maxCount: checks the number of occurrences of the property. These validations impose respectively a lower and upper limit on the number of occurrences.
  • disjoint: checks if two properties that are semantically disjoint do not share the same value.

Validating strings​

Strings can have a language tag or not for internationalization. Usually, string fields offer both options, allowing you to add strings with or without a language tag (resp. multilingual or monolingual). For strings with a language tag, there is an extensive list of 43 languages. Uploading a file that has a string with a language tag that is not in the list, will result in a violation. The UI will not allow you to add a language tag that is different from the ones in the list.

Future versions will allow you to add any language.

SPARQL-based Constraints​

Apart from the Core constraints that are needed to render the UI, some SPARQL-based constraints were added to ensure even better data quality. These constraints check the whole dataset, rather than focussing on one particular URI in the dataset.

These contraints can either result in a violation or a warning. Violations will impact the health score, where warnings will not. Both are reported in the validation report of the item.

Following checks are performed by the SPARQL-based constraints that lead to a violation:

  • URIs that have either broader, narrower or related should be of type skos:Concept
  • Two concepts in the same scheme should not have the same label (modeled as skos:prefLabel)
  • Two concepts in the same scheme should not have the same notation

Following check is performed by the SPARQL-based constraints that lead to a warning:

  • Concepts and Collections should have one of following properties in order to be well documented: definition, note, example, historyNote or scopeNote