Compound Measure Description (CMD)

Introduction back to ToC

This vocabulary enables to describe compound measures, i.e. measures with several metric or item that are organized with serveral dimensions. It is called Compound Measure Description Vocabulary (or CMD, or Complex Measure Definition, or Composite Measure Declaration).
The description of such a measure relies on a Tree-Structure of Requirement (TSoR): a set of requirements structured hierarchicaly with analysis elements. A TSoR consists of structuring requirements, the atomic items to be evaluated, with analysis elements, i.e., concepts that classify requirements. Hence, a TSoR is composed of two kinds of elements and relations. First, the requirements should be thought of as a specification for an implementation and focus on evaluating a single thing. They are structured according to analysis elements, which are a kind of classifier of the requirements (bottom-up vision), or conversely, a refinement of an analysis (top-down vision). These analysis elements are structured with a relation is specified by. It indicates that an analysis element splits into subelements. Requirements are associated with analysis elements by the relation expects. All together they form a rooted tree.
Several information may be added to explicitely indicate how the overall score on the measure should be calculated based on the hierarchy, the relative importance of the nodes of the hierarchy and an aggregation function. The measure can be described completely and unambiguously from the organisation to the requirements and the implementation.

Compound Measure Description: Overview back to ToC

The core component of the CMD vocabulary is illustrated in Figure 1. Hence, a TSoR consists of a set of AnalysisElements and Requirements that form a tree structure. The elements of the tree are linked by the relations isSpecifiedBy and expects. In addition, they are associated with a content (name, description...) through the relation hasContent. The content of an analysis element is of type skos:Concept, and a requirement is intended to measure a specific aspect, therefore its content is of type dqv:Metric. Note that analysis elements and requirements can only structure a single TSoR. However, their contents, concepts or metrics, can appear in multiple TSoRs. The cardinalities, shown in gray in Figure 1, ensure that the TSoR is properly designed.

Additional information can be added to the structure to make it a fully defined measure. Therefore, an Implementation is linked to a requirement to indicate how to evaluate them, with isImplementedBy. Each requirement and analysis element has a weight that represents its relative importance compared to its siblings in the tree. An aggregation function (aggregFunction) is associated with a TSoR and indicates how to compute an overall score based on results obtained on each requirement and on the weights of the structural elements. Other information can be added to enhance the transparency of the TSoR thus defined, such as creators, creation and modification dates, etc.

Figure 1 : CMD-v core concepts and relations

How to use

Figure 2 shows a small example of a TSoR that represents a part of the FAIR-Checker measure: it considers only the "A1.1" sub-principles. Another example representing a measure of accountability, as described here, is available in RDF.

Figure 2 : Example of use of CMD on a sub-part of the FAIR-Checker measure

To go further

SHACL shapes are defined to ensure that the TSoR defined with the vocabulary is well-formed, i.e. it actually forms a tree structure. It also checks that the TSoR satisfies the cardinalities and some other recommendations.

This ontology has the following classes and properties.

Classes

• Analysis Element
• Implementation
• Requirement
• TSoR: Tree-Structure of Requirements

Object Properties

• expects
• has root
• hasContent
• is followed by
• is implemented by
• is specified by

Data Properties

• aggregation function
• weight

Cross-reference for Compound Measure Description classes, object properties and data properties back to ToC

This section provides details for each class and property defined by Compound Measure Description.

Acknowledgments back to ToC

This work is supported by the ANR DeKaloG (Decentralized Knowledge Graphs) project, ANR-19-CE23-0014, CE23 - Intelligence artificielle.
The authors would like to thank Silvio Peroni for developing LODE, a Live OWL Documentation Environment, which is used for representing the Cross Referencing Section of this document and Daniel Garijo for developing Widoco, the program used to create the template used in this documentation.