Validate model data using SKOS-XL constraints

The Knowledge Model Management (KMM) component supports validating models using SKOS-XL constraints. This form of validation provides an out-of-the-box solution to check for invalid and possibly undesirable data in your models. In this topic, we will discuss:

• What are SKOS-XL constraint violations and how does invalid data get into a model
• SKOS-XL validation checks
• Summary of constraint checks
• Table of all constraints

Note that while validating SKOS-XL constraints can detect a number of issues with your data, the guidelines are flexible by design. If your model would benefit from stricter validation, consider validating your data against model-specific constraints. See Validate data using model specific constraints for details.

What are SKOS-XL constraint violations and how does invalid data get into a model

KMM requires specified RDF structures to display and edit a model through its UI. For more information on these requirements, see Overview of Semaphore SKOS-XL Constructs. However, the backend data store of the KMM allows the storage of RDF data outside the range of what is viewable and editable in KMM. This allows interoperability with other RDF applications and systems, but can also hide bad or undesirable data.

Invalid data can be introduced into a model in a number of ways, primarily through:

• Using SPARQL INSERT and/or DELETE queries that do not follow the Semaphore SKOS-XL modelling guidelines
• Importing of RDF generated in other systems

Less common ways include:

• Task conflicts, where the work done in multiple tasks conflict with each other
• Certain conditions occur when importing data through the KMM CSV/Excel importing process

SKOS-XL validation checks

SKOS validation checks occur at the following events during the modeling process:

• Running the “Constraint Violations” report
• Creation and editing of data in the KMM UI
• When Tasks are committed
• When a SPARQL query is run in the SPARQL editor

Constraint violations report

KMM provides a number of out-of-the-box reports that check for either invalid or possibly undesirable data in the model. Often this invalid data is not visible in the KMM UI, but might interfere with the use of the model. Therefore, it is important to find this data and resolve any potential issues by fixing, deleting, or making a deliberate decision to keep the data.

The “Constraint Violations” report is the most comprehensive of these reports and checks you model against all the constraints described in the SKOS-XL constraints table.

To run the “Constraint Violations” report or other validation reports:

1. Open your model; then, click Open Master. Note that, in this procedure, we will use the provided "Space Missions" model in the examples.

2. From the banner menu, select Master > Reporting.

3. Select the Validation tab.

   

4. Configure any report specific options; then, click Run Report.

Editing in the KMM UI

Error constraints are enforced in the KMM UI, and, therefore, cannot be created through the UI. However, some warning-level constraints can be created through the UI. This typically occurs when a warning message is returned, but the user elects to save the data anyway. For example:

Committing Tasks

The SKOS-XL error-level and warning-level constraints are checked when a Task is committed and the Validate before commit checkbox is selected:

If any errors or warnings are returned, the Task cannot be committed. Therefore, you might not want to validate a Task before committing if any of the warning constraints are acceptable in your models. For example, duplicate pref labels is a commonly acceptable condition.

The SPARQL Editor

When using the SPARQL editor, the Run Edit Rules and Check Constraints check boxes are exposed when specifying an INSERT or DELETE query:

If Check Constraints is selected, the SKOS-XL constraints are checked when the query is run. If any constraints are violated, whether Warnings or Errors, an error message is displayed and the query is not be executed.

If Check Constraint is disabled, then invalid data can be inserted or left to persist in the model.

Summary of constraint checks

Generally, the validation checks fall into the following categories:

• Missing labels on:
  • Concept Schemes
  • Classes
  • Relationship Types
  • Alt Label Types
  • Metadata Property Types
  • Pref Labels on Concepts
• Label violations:
  • Only one label per language for objects and Pref Labels
  • Concepts that have the same value in the same language in both the “alternative label” and the “preferred label”
  • Whitespace only labels
• Orphaned concepts: Concepts must have a parent, whether another concept or as the top concept of a concept scheme
• Domain and range violations:
  • Relationships: For example, if concept A is related to concept B, and one or both do not belong to the proper class(es) defined for that relationship type.
  • Metadata properties: For example, a value with a data type of date is not added to a property with a type of Boolean.
• Hierarchical cyclic loops
• Duplicate URIs for different object types
• Checks for untyped subjects: For example, objects without an rdf:type, such as a concept without a class.

SKOS-XL constraints

The following table lists all the constraints that are checked during validation checks (see SKOS-XL validation checks). Typically, the constraint code is included with the message, but not always. Note that each constraint includes an error level in the definition that determines whether the violation is tolerated. For example, constraints that are defined as Warnings return a warning message when violated, but do not prohibit the action. Conversely, when a constraint defined as an Error is violated, an error message is returned, and the offending action is prohibited.