Chapter 2: Preparatory Phase
The business perspective: Why do we build the ontology, and where it is built for?
Last updated
Was this helpful?
The business perspective: Why do we build the ontology, and where it is built for?
Last updated
Was this helpful?
Identical to software applications, in advance of building the ontology it must become clear why the ontology is built and where it is built for. Its purpose and way of use have a major impact on the form and contents of the ontology. Since purpose and use remain invariant over the different parts of the ontology, these aspects need to be clarified only once. Questions that we answer in this stage are, amongst others:
What will the ontology be used for?
Will it be used stand-alone by humans or integrated into a software application?
Will it provide something that is not available yet, or will it replace something?
The REPRO approach marks answering these questions at the start of the project and assures that they remain clear throughout the life-cycle of the ontology, or allows for their controlled evolution when such is deemed necessary by business demands throughout its life-cycle.
Moreover, already in this preliminary stage it is highly relevant to establish the benefits of the ontology and their related costs for implementation. Without these insights it is not possible to prioritise the development process according to a declining benefit/cost ratio or to make strategic decisions towards market deployment. To assure that the most beneficial demands will be realised first, the REPRO approach seeks to identify various motivating (business) scenarios. These are then prioritised and applied as backlog to the incremental development process. For that, textual descriptions of the business, their processes or collaborations, or use cases that are geared towards "doing business", are very valuable since they provide a "vocabulary in action", e.g.:
The product line can be configured for punching product A or B; although their molds are switched automatically, the feeder and feeder line must be adjusted manually to support either material X or Y.
The domain experts play an important role in identifying and documenting the business processes and use cases. Sometimes these processes and use case are already documented, but in most cases also knowledge should be extracted from the domain experts' mind(s). Writing down scenarios can be done in several forms: with colleagues or individually, in advance of a session or in limited time during a session, using existing process documentation or entirely by heart, on paper or in a text editor, documenting only common use cases or also indicating more uncommon ones, etc. A list of important domain terms can be used as an inspiration for writing scenarios.
The focus in the step of sketching scenarios is on gathering domain knowledge and not on deciding whether the knowledge is in or out of scope. In the end, multiple scenarios have been documented by one or more domain experts and can be used as input for further steps in the ontology engineering process.
Terms that are being used by these scenarios are considered essential to the business and application, otherwise these terms would not have been used here. So we will gather these with their description of their meaning in a Glossary of Terms. This glossary will remain a living document throughout the project and a growing index into the ontology.
The scenarios as defined in the previous step can be used to derive (important) terms used in the domain. A distinction can be made between events and objects by making difference between verbs and nouns. For example, highlight all verbs with pink and highlight all nouns with blue. Now you have made a first distinction between objects (nouns) and events (verbs). In the ontology, the objects will end up as classes and events might end up as relations/properties. (This approach has been used in the FIT with Ontologies project. The identified objects turned out to be useful in defining classes, but the events were not directly used to create relations.)
When doing this exercise together physically, then it is recommended to write the verbs and nouns on post-its of different colours. Put the post-its on a wall so three additional steps can be performed:
Discover the most important concepts. These are concepts that were covered in almost every scenario. This is also a good moment identify whether synonyms exist of certain concepts. If synonyms exist, the domain experts should (later on) agree on the preferred name.
Agree on the definition of the concept. It often happens that domain experts mean something different when referring to the same concept. These differences should be identified and discussed to agree upon the definition of the concept.
Identify domain clusters. Can we cluster certain concepts in subdomains? Do this by clustering post-its on the wall. This is a good starting point for selecting the first subdomain to be modelled in the first iteration.
Once a few business scenarios have been drafted, they will show the actual processes, their actors, and many concepts of importance to the domain being modelled. Now we can start looking at the application requirements that follow from these. Indeed, the use of the ontology may prescribe a human-centered application only; still, these human applications, like software applications, need to commit to requirements about their quality of use, e.g., the level of abstraction or details that these must show, their completeness in a certain scope, and more. For software-centered applications, it is not the intention to design the applications here, but to specify the computational requirements that the ontology must commit to.
By already thinking in this stage about the test cases that the application needs to accept, not only can we define what we consider a successful application, but also see the extend in which the requirements are sufficiently described to have the application pass these tests. When done well, test cases will identify requirements that need a further elaboration into, e.g., criteria, or show areas that lack sufficient requirements to formulate test cases about.
REPRO does not enforce to generate all motivating business scenarios in one pass. Instead, since the conceptual and computational phases require the business scenarios as input, one can decide to elaborate the most relevant ones first. This allows for a decision moment about whether to proceed into the conceptual phase or into the computational phase. Such decision may depend on many considerations, e.g., context of use, maturity of the ontology, the urge to verify preliminary ideas, the need to push a particular release, commercial demands, even a Kanban Work in Progress overflow. Regardless of the consideration and reason, this ability of REPRO allows for a more agile ontology engineering process.
In conclusion, these preparatory activities produce a well-defined foundation that is required to start developing the ontology:
A clear idea of the kind of ontology that is required: human- or software-oriented and how to make use of it;
One or more motivating scenarios that the ontology must support, including a provisionary glossary of terms;
For each motivating scenario a set of related application requirements with their test cases.
By the authors of Falbo14 this stage is included in what they call Purpose identification and Requirements elicitation. We, however, have isolated the part that is done only once, viz. Purpose & Intended Use, and added the part that we consider necessary to achieve the start condition for the conceptual phase, viz. Motivating Business Scenarios, or additionally the Application Requirements for the computational phase.