> For the complete documentation index, see [llms.txt](https://tno-data-science.gitbook.io/repro/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://tno-data-science.gitbook.io/repro/part-i-the-repro-method/chapter-1-overview-of-the-repro-method.md). # Chapter 1: Overview of the REPRO method ## Introduction The REPRO method that we propose is a combination from current approaches in literature ([Noy01](/repro/closure/literature.md#noy01), [Falbo14 ](/repro/closure/literature.md#falbo14)and [Peroni17](/repro/closure/literature.md#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: ![Figure 1 - A birds-eye view on the REPRO method](/files/-MHGvVgmSE4hBB5TbUPe) The core characteristic of REPRO is that it consists of two phases ([Falbo14](/repro/closure/literature.md#falbo14)), the Conceptual phase (no.2 in Figure 1 above) and the Computational phase (no.3) that are addressed in an iterative approach ([Peroni17](/repro/closure/literature.md#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: 1. 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](https://www.manufactus.com/kanban/?lang=en) 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; 2. 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. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://tno-data-science.gitbook.io/repro/part-i-the-repro-method/chapter-1-overview-of-the-repro-method.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.