Chapter 3: Conceptual Phase
Is the right system built?
Last updated
Is the right system built?
Last updated
Similar to software requirements, ontology requirements are pursued in the first stages of the conceptual phase. These ontology requirements collectively describe what we demand from the ontology, but since this demand is not about functionality but about knowledge, the term “competency” is used instead. Competency questions (CQs) are for an ontology what requirements are for software.
The answer to "Is the right system build?" should be sought primarily in the CQ's which ask for facts and figures about the who, what, when, what for, where, whence and alike that are required in order to generate the business value as described by the motivating scenario. The correctness of the answers is very much dependent on their applicability to the purpose that the ontology is to achieve in its context of use. For instance, the same heart beat value of 128 BPM can refer to very different health conditions in the context of elderly or new-borns, or even refer to a completely different situation as an indication of performance potential in a sports application. These variations in correctness of the answer are collected as different test cases that include exemplar data to reflect those contextual cues.
Ontology Modularisation reflects the best practice to decompose a potential monolith into separete modules that show maximal internal cohesion and minimal connection with the other modules. This serves a very specific goal: reusability. It is often the case that particular patterns or even a complete part of an ontology apply to other CQ's, scenarios or even ontologies. Such modularisation follows directly from one of the major design principles in software engineering: Separation of Concerns, here denoted separation of competencies. This should not be viewed as an advantage for the ontology engineer only; the customer or domain expert will be helped very much with a proper separation between competencies that can be applied in different situations. This consolidation of competencies as a separate area might even lead to the identification of knowledge assets that are so essential to the organisation that distinct groups or departments emerge.
When the motivating scenarios, glossary of terms and interesting concepts are defined, it is time to decide on the part of the model that should be modelled first. For the first iteration it is recommended to start with the 'piece of the puzzle' that is easiest to understand. For example, in the FIT with Ontologies project we started with the high-over staffing industry landscape.
Once the part to be modelled is selected, you can start collecting the objects that belong to the part being modelled. Limit the number of objects being modelled. E.g. only select the 15 most important ones. When selecting objects for new iterations, also take into account objects that have been identified in the previous iteration(s).
CQ's form a good background to the task of conceptual modelling, that is, laying out the classes of relevance and their connecting relationships. We will see that different layouts can be used to answer a particular CQ, but that one is more appropriate in how it fits the purpose and use of the ontology. If anything, this task is to be done in consultation with the domain experts. For that reason we do not demand here that the form of the conceptual model should be digital; a cardboard version from paper and post-its is sufficient and often even more efficient and valuable since this type of results are much clearer for the domain experts than any other digital form.
The step of conceptual modelling is an important step in the conceptual phase because the first version of the ontology is being developed. To establish a proper foundation for the ontology, we recommend organising a so-called pressure cooker. A pressure cooker is a session with a predefined scope joined by several parties to develop (part of) a domain model under the supervision of TNO. This pressure cooker method lasts several days or even a week resulting in a reduced development time and first quick steps towards a standardized model.
To achieve the best possible result, it is important that the right people join the pressure cooker and work together. The following three roles can be distinguished:
Domain expert. Domain experts bring understanding of the domain and the processes being modelled. The group of domain experts performs best when it is a mix of roles, expertise, organisations and (technical) experience. Also end users can be part of this group.
Ontology engineer. The main task of the ontology engineer during the pressure cooker is guiding the engineering process and making sure all knowledge is captured correctly. This person will also be the one formalising the ontology.
Session leader. To provide a structured session, a session leader is needed. This person keeps an eye on the goal of the session and facilitates the process. Although the scope of the session is determined in advance, it is possible that the direction or objectives must be changed during the session. The session leader guides and makes, in consultation with the participants, adjustments in the approach where necessary.
The following best practices can be used to facilitate a good pressure cooker:
Agree on the terminology for the most important terms being used during the session to make sure everyone is talking about the same thing. Document them and make them visible for everyone so that it can be consulted when doubts arise.
Use a 'parking lot' to park issues that are encountered, but can be discussed later.
Recognise when a new concept is introduced and write it down (on a post-it) to ensure it won't be forgotten in a later stage.
A pressure cooker lasting several (long) days is intensive, so set up a schedule with enough variety and rest. Variety can be achieved through different work forms, groups and group sizes.
Keep in mind: a pressure cooker is a collaborative effort. The parties involved share the responsibility to come up with a great result.
The authors of Falbo14 have identified a stage called "Ontology Capture and Formalisation". Indeed, although we have developed a conceptual model, we cannot as of yet test it nor apply it for reasoning. Those capabilities are reserved for a digital representation only. We call this Ontology Formalisation & Verification, depicted as follows:
The task for this stage is clear: translate the paper representation of the ontology into an exact digitial replica. The only thing that changes is its representation, and with that its computational capabilities. Functionally, terminologically, structurally, competentionally: no changes are allowed to be introduced. The purpose of this stage is to enable and execute the verification of the ontology: its consistency (it is impossible to deduce facts that contradict each other); its functionality (do the queries provide the data that we expect them to produce, more nor less of them?); its completeness (does the generated Glossary of Terms cover the original, manually produced one?). Defining axioms, translating CQ's to queries, adding test data, creating your TDD's Ontology Test Suite: this is a prerequisite for verifiying your ontology throughout its life-cycle.
This step completes the conceptual phase.
The domain experts involved in the conceptual modelling should also be involved in the steps of ontology formalisation and verification. Use the domain experts to perform a check and to review the final concepts in the ontology. The review can be performed in several ways:
The ontology engineer might encounter some uncertainties or questions while formalising the ontology. The engineer can ask for clarification or ask questions to the domain experts. The ontology engineer makes sure the context and the question being asked are clear and understandable for the domain expert.
Reviewing can be performed while using the ontology through some tooling or an application. This is a good way to simultaneously use and review the ontology.
Domain experts who are curious and tech savvy can review the turtle file and provide feedback in the source code.
When during the process of ontology formalisation and verification it turns out that a module of the ontology is incomplete or incorrectly modelled, this part should be revised in a new iteration of the conceptual model.
