"Constraint

Introduction

KMM (Knowledge Model Management) can check for invalid and possibly undesirable data in each model in KMM. These checks occur at various points in the modelling process:

• Running the “Constraints 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

This article will describe the nearly 50 different constraints that KMM checks for at these various points in the modelling process. Note that each constraint is of type Warning or Error, which can impact whether the violation will be allowed (e.g. just a warning is thrown) or disallowed (e.g. an error is thrown).

What Are 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. These requirements can be found here: Overview of Semaphore SKOS-XL Constructs. But the backend data store of KMM will allow the storage of RDF data outside the range of what’s 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 the model in different ways, primarily through:

• Using SPARQL insert and/or delete queries that don’t follow the Semaphore SKOS modelling guidelines
• Importing of RDF generated in other systems

Less common ways include:

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

Constraints Violations Report

KMM contains a number of OOB (out of the box) reports in the Reporting section of KMM. These reports are grouped onto 3 tabs, one of which is the Validation tab:

On the Validation tab, there are a number of 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 may interfere with the use of the model, so it’s important to be able to find and address this data by either fixing, deleting, or making a deliberate decision to keep it.

The “Constraint Violations” report is the most comprehensive of these reports, and checks for all the violations described in the table below.

Editing in the KMM UI

Error constraints are enforced in the KMM UI, and therefore cannot be created through the UI. However, some (but not all) of the Warning constraints can be created through the UI, usually when the user is shown the warning and they elect to save the data anyway, for example:

Committing Tasks

These same Error and Warning 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. Validating before commit might not be something you want to do if any of the Warning constraints are deemed to be acceptable in your models – for example, duplicate pref labels may be the most commonly acceptable condition.

The SPARQL Editor

When using the SPARQL editor, when an INSERT or DELETE query is put into the editor, the “Run Edit Rules” and “Check Constraints” checkboxes are included:

If “Check Constraints” is selected, then the same constraints are checked when the query is run. If any constraints are violated, whether Warnings or Errors, an error message will be displayed and the query will not be executed.

If “Check Constraints” is de-selected, then invalid data can be inserted or left 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 – given 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 – e.g. 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 (i.e. objects without an rdf:type, such as a concept without a class)

Table of All Constraints

This table lists all the constraints that are checked for. Most of the time, the constraint code is included with the message, but not always.
^ Constraint ID ^ Error Level ^ Message ^ Description/Example ^