Chapter 1: Overview of the REPRO method

A short introduction of its main phases and steps therein.

Introduction

The REPRO method that we propose is a combination from current approaches in literature (Noy01, Falbo14 and Peroni17). We've also included experiences that TNO's Data Science group has gained over the last decade in semantic standardisation, based on our current standardisation methods BOMOS and MOSES. Furthermore, we added a touch of the current best practices in software architecture and engineering (Test Driven Development and the SCRUM framework). In a nutshell, the following overall picture of REPRO then emerges as follows:

The core characteristic of REPRO is that it consists of two phases (Falbo14), the Conceptual phase (no.2 in Figure 1 above) and the Computational phase (no.3) that are addressed in an iterative approach (Peroni17). It is not necessary (but also not forbidden) to finalize the first phase before addressing the second phase; hence the overall approach can also be executed incrementally.

The conceptual phase focuses on the ontological analysis of the domain of application in order to achieve an abstraction and representation that is as faithful to reality as possible. Its objective is to achieve a human-oriented shared understanding of the conceptualization of the domain of application (DoA): "Is the right system built?". The computational phase explicitly takes the technological context into account in order to assure that other qualities than domain faithfulness are consolidated as well. Its objective is to achieve a computational efficient implementation that meets the (extra-functional) quality requirements: "is the system built right?". We don't demand that the conceptual phase delivers a paper model only; where possible, a computational model is preferred also in the conceptual phase, particularly due to the verification potential of a computational model. Still, particularly the first stages of the conceptual phase will be characterized by paper, post-its and cards.

Another characteristic of REPRO is its foundation on the test-driven development principle (TDD), indicated as no.4 in the figure above. This means that building a test environment precedes the actual development of the results. Such approach, closely related to SAMOD's bag of test cases, does not only improve the understanding of the ontology that is to be constructed, but also implies that a test environment is available that consolidates the correctness and applicability of the ontology throughout its life-cycle.

Investigating both SAMOD, SABiO and Ontology 101, we observe that several artefacts are used as starting point to the ontology engineering process. This specifically relates to purpose and context, motivating scenarios, initial concepts, and the availability of a test environment. We therefore introduce a preparation phase (no.1 above) that consolidates a managed start of the ontology evolution process by specifying a sound baseline for engineering, verification (conceptual phase) and validation (computational phase).

In the following sections we first summarise the preparation phase and then provide for an overview on the conceptual and computational phases, respectively. We underline several important observations about these three phases:

Phases are not necessarily following each other subsequently, but their order does matter. It is up to the OE project to consider the need for particular results. In larger projects one may even consider a Kanban approach to assure reduction of waste of resources and to optimise material flow. In any case, ending one phase demands a decision to be made about what to do next: another iteration of the previous phase or a new iteration of the next phase with the results of the previous phase;
Phases are iterative but there is no preferred order in their activities. Each activity is necessary to engineer a proper ontology but unlike phases their order is less important. It might even be the case that activities are performed in parallel and in close connection with each other.

PreviousHow to become an ontology expert?NextChapter 2: Preparatory Phase

Last updated 3 years ago

Introduction

Phases are not necessarily following each other subsequently, but their order does matter. It is up to the OE project to consider the need for particular results. In larger projects one may even consider a Kanban approach to assure reduction of waste of resources and to optimise material flow. In any case, ending one phase demands a decision to be made about what to do next: another iteration of the previous phase or a new iteration of the next phase with the results of the previous phase;

Phases are iterative but there is no preferred order in their activities. Each activity is necessary to engineer a proper ontology but unlike phases their order is less important. It might even be the case that activities are performed in parallel and in close connection with each other.