=Paper=
{{Paper
|id=Vol-3905/paper1
|storemode=property
|title=SABiOx: The extended systematic approach for building ontologies
|pdfUrl=https://ceur-ws.org/Vol-3905/paper1.pdf
|volume=Vol-3905
|authors=Camila Z. Aguiar,Vitor E. Silva Souza
|dblpUrl=https://dblp.org/rec/conf/ontobras/AguiarS24
}}
==SABiOx: The extended systematic approach for building ontologies==
https://ceur-ws.org/Vol-3905/paper1.pdf
SABiOx: the extended systematic approach for building
ontologies
Camila Zachhé Aguiar1 , Vítor E. Silva Souza1
1
Ontology & Conceptual Modeling Research Group (NEMO) – Federal University of Espírito Santo (UFES), Brazil – Av. Fernando
Ferrari, 514, Goiabeiras, Vitória, ES, 29075-910
Abstract
In the literature, several Ontology Engineering methods have been proposed in recent years, with the purpose of
guiding the ontology construction process and thus producing ontologies with better quality. However, the field
still lacks widely accepted and mature methods, which present a standardization of activities, documentation,
step-by-step instructions for building ontologies and sufficient details of their life cycle. In this paper, we present
SABiOx: an Ontology Engineering method which aims to guide the construction of ontologies in more detail,
supported by agile principles, with iterative and incremental cycles. SABiOx covers both the construction of
reference and operational ontologies, defining a life cycle formed by five phases (Requirement, Setup, Capture,
Design and Implementation) detailed in activities, artifacts and roles involved, and supported by Knowledge
Acquisition, Documentation, Configuration Management, Evaluation, Reuse and Publication activities. We report
on the application of SABiOx to ontology construction by inexperienced ontology engineers, demonstrating how
the guide have contributed to understanding and clarifying ontology construction activities and producing the
desired outcomes. In addition, we also compare SABiOx with other methods present in the literature.
Keywords
Ontology Engineering, Ontology Engineering Method, Ontology.
1. Introduction
Ontology construction methods have been proposed in Ontology Engineering (OE) with the aim of
guiding the ontology construction process and improve the quality of the results, establishing a standard
for their construction. Thus, Ontology Engineering must follow a well-defined method, dealing with
practical aspects that allow communities of specialists and ontologists to reach a consensus on the
domain of the ontology, in addition to keeping it alive and evolving [1]. Although several methods
have been proposed in recent years, the field still lacks widely accepted and mature methods [2]. Most
methods do not present standardized activities, documentation and ontology engineering techniques [3],
as well as sufficient details of the ontology life cycle [4, 5] or sufficient step-by-step instructions for
building the ontology [6].
In this context, we present the SABiOx method — the Extended Systematic Approach for Building
Ontologies — an Ontology Engineering method proposed with the objective of guiding the construction
of ontologies (of any domain) in more detail supported by agile principles, with iterative and incremental
cycles and constant revisions of the produced artifacts. SABiOx covers the construction of both
reference and operational ontologies, highlighting the importance of concept consensus, the adoption
of a foundational ontology, the application of ontological analysis and the reuse of resources.
As the name suggests, our proposal is based on the SABiO method [7], extended with details on the
ontology life cycle and its activities, and adjusted according to our experience in building core, domain
and network ontologies. The SABiO is a method for building reference and operational ontologies [8]
that incorporates best practices from Software Engineering (SE) and Ontology Engineering (OE). SABiO
Proceedings of the 17th Seminar on Ontology Research in Brazil (ONTOBRAS 2024) and 8th Doctoral and Masters Consortium on
Ontologies (WTDO 2024), Vitória, Brazil, October 07-10, 2024.
*
Corresponding author.
$ camila.z.aguiar@ufes.br (C. Z. Aguiar); vitor.souza@ufes.br (V. E. S. Souza)
https://nemo.inf.ufes.br/equipe/camila-de-aguiar/ (C. Z. Aguiar); http://www.inf.ufes.br/~vitorsouza/ (V. E. S. Souza)
0000-0001-7945-6489 (C. Z. Aguiar); 0000-0003-1869-5704 (V. E. S. Souza)
© 2024 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
CEUR
ceur-ws.org
Workshop ISSN 1613-0073
Proceedings
Figure 1: Overview of the SABIOx method representing the five phases (Requirement, Setup, Capture, Design
and Implementation) with solid circles and the activities with dots on these circles. The colored dots correspond
to the main activities of each phase, the gray dots correspond to the supporting activities (Documentation,
Control, Evaluation and Publication), the dotted circles around the dots correspond to the activities supporting
knowledge acquisition (in pink) and the reuse activities (in blue) that occur in parallel with some main activities.
focuses on the development of domain ontologies, and explicitly recognizes the importance of using
foundational ontologies and performing ontological analysis in the ontology development process.
The paper is organized as follows: Section 2 presents the SABiOx method, providing an overview of its
proposed life cycle and describing its activities; Section 3 discusses related work on ontology engineering
methods; Section 4 reports on the application of SABiOx and compares it with other methods present
in the Ontology Engineering literature; finally, Section 5 concludes with final considerations.
2. SABiOx: the extended systematic approach for building ontologies
SABiOx proposes an iterative and incremental ontology life cycle composed of five phases, each of
which defining a phase life cycle composed by a set of activities. Figure 1 provides an overview of
SABiOx’s phases (solid line circles) and activities (dots over the circle lines). Each phase is concerned
with a different aspect of the Ontology Engineering process. The Requirements phase elicits the
requirements for the ontology, i.e., what it is intended to capture/represent. The Setup phase defines
the baseline (e.g., modeling language, reuse of other ontologies, etc.) for building ontology models. The
Capture phase identifies and models the conceptualization (i.e., concepts, relations, axioms, etc.) to meet
the elicited requirements. The Design phase specifies technological features (e.g., encoding language,
reuse of existing vocabularies, etc.) for the implementation of the ontology. Finally, the Implementation
phase encodes the ontology in an operational language (e.g., OWL).
The phases are defined in a progressive way so that each phase uses the result of the previous
phase to provide gradual enrichment in the life cycle, e.g., the specification document produced in
the Requirements phase is used during Setup and Capture. Conversely, the outcome of each phase
can be revised (represented by the dashed lines in Figure 1), e.g., the outcome of the Implementation
phase can give rise to a revision in the Design and Capture phases. Hence, the life cycle is designed
to accommodate the iterative construction of ontologies and their evolution over time, i.e., iterating
through the cycles generates new increments or changes in the ontology. For each phase of the ontology
life cycle there can be several phase life cycles, executed based on agile principles (inspired by Software
Engineering).
Each one of SABiOx’s phases define a phase life cycle, consisting of main activities, which define
the main procedures for producing the result of that phase, and supporting activities, which define
auxiliary procedures for the main activities. In Figure 1, supporting activities are represented by gray
dots/lines following the main activities (when performed in sequence) or colored dotted circles around
main activities (when performed in parallel).
Supporting activities are divided in six categories: Knowledge Acquisition activities lead to the
extraction of knowledge from different sources; Documentation activities record the results of other
activities in the process (e.g. ontology specification document, ontology reference document, concept
catalog, ontology view, conceptual model, operational ontology document and operational ontology);
Configuration Management activities control the versioning and changes in the produced artifacts;
Evaluation activities assess the quality of the produced results by applying verification with competency
questions, validation with ontology instances and tests with queries about the competency questions over
the operational ontology; Reuse activities reuse ontological and non-ontological resources (e.g. literature,
ontologies, vocabularies, etc.); and Publication activities make the produced ontology available.
SABiOx does not prescribe a specific agile process to be followed. However, it defines the roles that
are expected to be involved in its phases and activities. These roles could be performed by the same
person in an individual effort or by different people in a collective, distributed effort in the context of an
organization. The Ontology Owner is a person interested in building the ontology for a given purpose
and responsible for defining its requirements. The Ontology Team is a person or group of people
effectively responsible for building the ontology. Such team is composed by one or more Domain
Experts, with knowledge/expertise on the domain of the ontology, and Ontology Engineers, with
knowledge/expertise on ontology design and implementation.
In the following subsections, we describe each phase of SABiOx in a bit more detail, illustrating each
activity with a running example: the development of OOC-O, an ontology on Object-Oriented Code, that
aims to identify and represent the semantics of the entities present at compile time in object-oriented
(OO) source code [9]. Due to space constraints, we only provide an overview of each phase. For the
interested reader, a guide to SABiOx with fully detailed descriptions of its activities and the complete
set of artifacts produced for OOC-O are available as supplementary material1 .
2.1. Requirements phase
The Requirements phase aims to identify the purpose of the ontology within a defined domain and to
discover the needs that the ontology should satisfy regarding its content and characteristics.
This phase starts with the Define Purpose activity, in which the ontology engineer elicits expectations
from the ontology owner in order to answer three questions: what is the domain that the ontology
intends to represent, for what the ontology will be useful, and why the ontology should be built.
For OOC-O, the purpose was defined as: to represent the concepts of object orientation present in a
source code (what); so that these concepts can be interpreted and identified by different programming
languages in a unique way (for what); because each programming language defines its own syntax and
semantics, resulting in source code with heterogeneity and interoperability difficulties (why).
Next, in Identify and Size Domain the ontology engineer continues to work with the ontology owner
in order to identify the knowledge that the ontology should cover (horizontal dimension), as well as the
level of detail that the ontology should cover of the domain (vertical dimension), also specifying what
1
https://nemo.inf.ufes.br/projetos/sabiox
is out of the scope of the ontology. For OOC-O, in the horizontal dimension the domain was defined
as concepts related to object-oriented software development; whereas for the vertical dimension the
domain was limited to represent source code at compile time only, not covering runtime concepts.
Then, in Elicit Requirements the ontology engineer elicits functional (FRs) and non-functional re-
quirements (NFRs) from the ontology owner. FRs define what is or is not relevant to the ontology (e.g.,
competency questions the ontology should be able to answer) and are used in the subsequent activities
to evaluate whether the ontology meets its requirements. NFRs, on the other hand, are not related to
the contents of the ontology, but instead to quality aspects (e.g., usability, maintainability) or design
constraints (e.g., implementation language). For OOC-O, a set of FRs, such as, “What are the main
elements of an OO source code?”, “Which elements make up a class?”, etc; and a set of NFRs, such as,
being modular, being grounded on a foundational ontology, etc were elicited.
In Identify Subdomains, the ontology engineer can modularize the elicited requirements in subdomains,
allowing the targeted or distributed construction of the ontology in later phases. For OOC-O, three
subdomains were defined: Core (general object-oriented concepts), Class (class-related concepts) and
Class Member (concepts related to class members — attributes and methods)).
The Requirements phase follows with two supporting activities under the responsibility of the ontology
engineer: Document Specification produces an Ontology Specification Document with the results of
the previous activities and Control Specification controls the changes, versions and deliveries of the
information present in the specification document, providing Configuration Management capabilities to
the process. Finally, Evaluate Specification, allows the ontology owner to assess whether the information
elicited and registered in the Ontology Specification Document meets the expectations. If changes or
further elicitation is needed, another iteration of this phase life cycle ensues.
2.2. Setup phase
The Setup phase aims to define questions that will guide the elaboration of the reference ontology, i.e.,
decisions that have an impact on the conceptual modeling tasks to follow. The phase starts with Define
Modeling Language, in which the ontology engineer defines the modeling language to be used in the
construction of the reference ontology (conceptual model). The choice of language directly influences
the integration and reuse of the ontology under construction, since ontologies developed in different
languages may require greater adaptation efforts. For OOC-O, the OntoUML language [10] was adopted.
Next, in Define Foundational Ontology the ontology engineer defines the foundational ontology to be
adopted, which guides the modeling process of the ontology under construction and the views of the
reused ontologies. To do this, the popularity, usability, and adherence of the foundational ontology for
the defined domain must be considered, as well as the expertise of the ontology engineer in the chosen
ontology. For OOC-O, the UFO ontology [11] was chosen.
Then, in Define Concept Criteria, the ontology engineer works with the domain expert to define
the criteria that will be adopted to identify if a concept is adherent to the domain of the ontology
under construction. For this, a list of objective criteria, with quantitative information, or subjective
criteria, with qualitative information, is defined. These criteria can be defined for individual analysis
of each knowledge source or joint analysis over all the cataloged sources. Given the depth of domain
knowledge at this point, defining criteria can be challenging. Thus, as knowledge is enriched and
decisions about the domain are made, one should return to this activity to update these criteria. For
OOC-O, the following criteria were established: the concept refers to programming constructs used at
compile-time; the concept is present in more than 50% of the programming languages analyzed; and
the concept is related to the main elements of object-orientation: class, method and attribute.
In Define Ontologies to Reuse, the ontology engineer defines the reference ontologies to be reused,
i.e., ontologies or ontology fragments that match the purpose of the ontology under construction. The
reuse of ontologies is a challenge [3]. One must search for candidate ontologies in search engines,
repositories, and known ontologies, analyzing, among other things, whether the candidate ontology
represents appropriate concepts to anchor the ontology under construction and/or the coverage of the
candidate ontology with respect to the requirements of the ontology under construction. For OOC-O,
existing ontologies that deal with source code and object-orientation were searched in search engines
and known ontologies. Six ontologies were found and analyzed according to purpose and adherence to
the domain of OOC-O. In the end, the Source Code Ontology (SCO) [12] was selected for reuse.
The Setup phase follows with Documentation, Configuration Management and Evaluation activities
quite similar to the ones from the previous phase.
2.3. Capture phase
The Capture phase aims to represent in a well-founded way the domain conceptualization based on
the specification elaborated in the Requirements phase and the questions defined in the Setup phase,
which should be revised at each iteration in order to add, detail, and delete requirements and questions
related to the domain needs. In this context, conceptualization is an intentional semantic framework
that encodes the implicit rules that constrain the structure of a part of reality [13].
It starts with Identify Concepts, an activity divided in two parts. In the first, Catalog Concepts, the
ontology engineer works with the domain expert and/or the ontology owner to identify which domain
concepts are part of the purpose of the ontology. Data sources (e.g., books, papers, standards, etc.)
could also be used. Concepts related to the ontology domain should be cataloged according to the
criteria defined in the Define Concept Criteria activity from the Setup phase. For OOC-O, books and
specification documents of five OO programming languages (Eiffel, Smalltalk, Java, C++ and Python )
were defined as knowledge sources and used for capturing the concepts. In the second, Extract Ontology
View, the ontology engineer extracts the view of the reference ontologies to be reused in the modeling
of the ontology under construction. For this, a modularization strategy should be used over the original
ontology, since a view of the ontology will be developed that will reflect a part or a set of concepts
extracted from it. As the view is being built, ontology analysis must be applied to ensure ontology
compatibility with the ontology under construction. For OOC-O, the view of the SCO ontology was
elaborated in order to represent only the concepts from the object-orientation domain.
Next, in Identify Axioms, the ontology engineer works with the domain expert to identify the constraint
and inference axioms that the conceptual model of the ontology under construction must consider. As
the conceptual model is developed, one should return to this activity to ensure a more complete and
unambiguous model. For OOC-O, axioms such as ∀𝑐1 , 𝑐2 : 𝐶𝑙𝑎𝑠𝑠, 𝑖 : 𝐼𝑛ℎ𝑒𝑟𝑖𝑡𝑎𝑛𝑐𝑒, 𝑖𝑛ℎ𝑒𝑟𝑖𝑡𝑠𝐼𝑛(𝑐1 , 𝑖) ∧
𝑖𝑛ℎ𝑒𝑟𝑖𝑡𝑒𝑑𝐹 𝑟𝑜𝑚(𝑐2 , 𝑖) → 𝑠𝑢𝑏𝐶𝑙𝑎𝑠𝑠𝑂𝑓 (𝑐1 , 𝑐2 ) were defined for the inheritance relationship, which is
established when a subclass is inherited from a superclass.
Then, in Model Ontology, the ontology engineer continues to work with the domain expert in order to
model concepts and relationships covered by the purpose of the ontology in a technology-independent
ontology representation language. This modeling should apply both ontology analysis, in order to
categorize concepts according to a foundational ontology, and conceptual ontology patterns, in order to
leverage fragments of foundational ontologies. Ontology modeling can follow a top-down, bottom-up
or middle-out approach [3]. The ontology concepts and relationships should be modeled using the
modeling language defined in activity Define Modeling Language. For each modeled concept, you must
define its category according to the underlying ontology defined in the activity Define Foundational
Ontology. For each relationship established, you must define its name, direction, type and cardinality.
In addition, as the model is being built, conceptual ontology standards should be applied to ensure
the standard quality of the model. This activity requires decision making about the domain and its
representation, and should consider the knowledge acquired from the knowledge sources.
The ontology engineer and the domain expert continue to work closely during activities Integrate
Ontology and Modularize Ontology, iterating with the previous activities from this phase. In the former,
they integrate both the views of the ontology under construction and the views of the reused ontologies.
In the latter, they identify the modules into which the ontology can be decomposed and which can be
considered separately while being interconnected with other modules [14].
As modeling is evolutionary, the model must continuously undergo adjustments, apply ontology
analysis, integrate ontology views, and reorganize its modules, returning to these activities whenever
necessary. For OOC-O, the conceptual model of the object-oriented domain was built, integrated with
SCO and modularized in three parts, following the subdomains identified earlier.
The Capture phase also follows with Documentation, Configuration Management and Evaluation
activities quite similar to the ones from the previous phases. A final supporting activity, Publish
Reference Ontology, makes the artifact that results from this phase available to its target audience.
2.4. Design phase
The Design phase aims to define technological issues that will guide the implementation of the oper-
ational ontology, i.e., decisions that are dependent on the technological environment. The reference
ontology, elaborated in the Capture phase, provides the initial information to specify the design that
may be originated by different technological choices. This phase bridges the gap between the conceptual
modeling of reference ontologies and their encoding in terms of an operational ontology language [8].
The phase starts with Define Encoding Language, in which the ontology engineer defines the repre-
sentation language to be applied in the construction of the operational ontology, i.e., in the codification.
The choice of language directly influences the integration and reuse of the ontology under construction.
For OOC-O, the OWL language was chosen.
Next, in Identify Vocabularies, the ontology engineer identifies the vocabularies to be adopted in the
coding of the ontology under construction, both base vocabularies to assist in the construction of the
ontology and vocabularies of the reused ontologies. In this context, vocabulary is defined as the set of
concepts and relations of a given domain, without necessarily adopting a complex formalism such as
that of an ontology. For OOC-O, the vocabularies SCO, OWL, RDF(S) and XML Schema were reused.
Then, in Define Ontology Encoding, the ontology engineer indicates how the architecture of the oper-
ational ontology will be derived from the reference ontology, considering the defined coding language.
An ontology can be defined as a set of representational primitives that model a knowledge domain,
characterized as concepts/classes, relations/properties, and attributes/properties of data types [5]. In
the case of the OWL language, the architecture will be based on classes and properties extracted from
the conceptual model. It is also suggested that the nomenclature and the use of vocabularies to be
adopted in encoding the ontology are defined. The architecture should adopt modularization for ease
of understanding and reuse. In OOC-O, concepts and relations are represented as OWL classes and
properties. Naming patterns were defined in order to ensure unique identifiers for each element.
As with the Setup phase, the Design phase follows with Documentation, Configuration Management
and Evaluation activities.
2.5. Implementation phase
The Implementation phase aims to implement the reference ontology produced in the Capture phase
into an operational ontology, according to the design specifications elaborated in the Design phase. This
phase transforms the reference ontology into a machine-interpretable ontology, making it available for
use in applications, decision support, and domain reasoning.
The phase is mainly composed by activities Code Concepts, Code Relations and Code Axioms, in
which the ontology engineer encodes, respectively, the concepts, relations and axioms of the reference
ontology as elements of the formal operational ontology language, according to the assumptions defined
in the operational ontology document in the Design phase. For OOC-O, the concepts, relations and
axioms from the reference ontology are encoded as OWL classes, properties and constraints.
Similar to the Capture phase, the Implementation phase follows with Documentation, Configuration
Management, Evaluation and Publication activities.
3. Related works and baseline
We found in the literature methods that adopt different principles, processes and activities for the
construction of ontologies and that have already been discussed in literature reviews [2, 1, 15]. There
are works aimed at (i) acquisition and reuse of knowledge, (ii) processing and transformation of
information, and (iii) development of domain and application specific ontologies. In what follows,
we briefly summarize methods related to SABiOx that were selected from recent publications [1, 15],
focusing on those that define an ontology life cycle and/or allow collaborative/distributed work.
Methontology [16] is a proposal for ontology engineering based on the software development
process, including its rigor. The method follows three categories: management, to define what, how and
how many resources will be dedicated and their quality; development, to specify requirements, model
knowledge, transform into a formal semi-computable model, implement in computational language
and provide maintenance; and support, which includes knowledge acquisition, assessment, integration,
documentation and configuration management activities that are carried out in conjunction with
development activities. The life cycle is iterative, based on prototypes and reuse of existing ontologies.
UPON [17] is based on the Unified Process (UP) and supported by the Unified Modeling Language
(UML), with an iterative and incremental nature. The method includes cycles, phases, iterations and
workflows. The phases are defined as inception, to capture requirements and perform some conceptual
analysis; elaboration, to identify the fundamental concepts; construction, to design and implement; and
transition, to test and release ontologies. For each phase, iterations are executed, which follow the
workflows requirements, analysis, design, implementation and test.
OTKM [18] is a proposal for the introduction and maintenance of ontologies based on knowledge
management applications with a focus on Knowledge Processes and Meta Knowledge Processes. The
method follows the phases: feasibility study, to identify problems and opportunities; kickoff, to gather
requirements; refinement, to model and formalize the ontology; evaluation, to validate technical and
user issues; and application/evolution, to put the ontology to use and evolve it throughout the time.
101 Method [19] is a proposal for the iterative development of operational ontologies that supports
design decisions, guiding the activities of determining the domain of the ontology with competency
questions, considering the reuse of existing ontologies, enumerating important terms in the ontology,
defining classes and hierarchies, class properties, constraints and instances. The life cycle of the method
is not precisely defined, but it presents the construction process and the sequence of its activities.
HCOME [20] is a proposal for the development and evaluation of living ontologies in the context
of communities of knowledge workers. The method defines the life cycle formed by the specification
phase, to define the object, scope and requirements; conceptualization phase, for the development and
maintenance of the ontology through knowledge acquisition; and exploration phase, to apply and
evaluate the ontology. Activities are performed iteratively until a consensus is reached.
DILIGENT [21] is a proposal for the construction of reference ontologies in a distributed and
collaborative way, based on the evolution of prototypes. To mediate conflicts and differences in the
representation of consensual knowledge about the domain, the method adopts an argumentation
framework. The method follows the steps build, local adaptation (the built ontology is distributed so that
its users perform specific local changes), analysis, revise (the shared ontology is revised and updated),
and local update (update the local ontology with the new version of the shared ontology).
NeON [22] is a proposal for building ontological networks with reuse of ontological and non-
ontological resources, including nine scenarios, glossary of processes and activities, life cycles and
methodological guidance. The scenarios can be combined in different ways to build the ontology,
the building ontological networks from scratch scenario being mandatory and integrating all other
scenarios. The activities knowledge acquisition, documentation, configuration management, evaluation
and assessment must be carried out throughout the development of the ontology network.
SAMOD [23] is a proposal inspired by Test-Driven Development to develop ontologies with small
steps from an interactive workflow to the creation of well-developed and documented models from
domain descriptions. The method follows interactive steps consisting of defining a new test case,
merging the current model with the model developed in the previous step and refactoring the current
model executing testing for all test cases.
LOT [24] is a proposal focuses on the alignment with industrial development, in addition to academic
and research projects, and software development. LOT focuses on the reuse on terms and on the
publication of the built ontology according to Linked Data principles. The method follows interactive
steps ontological requirements specification, ontology implementation, ontology publication and ontology
maintenance, defining roles involved and main expected outputs.
SABiO [7] is the baseline of the SABiOx method, consisting of five main phases: purpose identifica-
tion and requirements elicitation; ontology capture and formalization; operational ontology design;
operational ontology implementation; and testing. Furthermore, these phases are supported by well-
known activities in the Software Engineering field, such as knowledge acquisition, reuse, configuration
management, evaluation, and documentation.
SABiOx was compared with the above methods as part of our efforts to evaluate our proposal,
presented next.
4. Evaluation
We evaluated the proposal of SABiOx with two efforts: a comparison with the related work presented
in Section 3 plus our baseline, SABiO [7], and a questionnaire submitted to inexperienced Ontology
Engineers that have applied SABiOx.
4.1. Comparison with related work and baseline
For the comparison with related work, we followed criteria adapted from protocols established in other
studies [2, 15] and emerging methodologies. Table 1 shows the comparison of the methods according to
the defined criteria.
Eleven criteria and their respective characteristics (abbreviated in parentheses) were defined, namely:
C1 Type of ontology: reference (REF), operational (OPE), not defined (NO); C2 Collaborative construc-
tion: is (YES) or is not (NO) addressed; C3 Reusability of existing ontologies: is (YES) or is not (NO)
supported; C4 Interoperability: is (YES) or is not (NO) addressed, by providing some strategy (e.g.,
sharing the same standards or high level concepts) that promotes interoperability in the ontologies that
are built; C5 Degree of application dependency: application dependent based on application knowledge
base (DEP), application semi-independent based on possible usage scenarios (SEM), and application
independent, no assumptions are made about the intended uses of the ontology (IND); C6 Life cycle:
sequential (SEQ), traditional cycle that performs activities sequentially so that the next activity be-
gins after the previous one is completed and all terms are identified at the beginning of the process;
incremental (INC), partial specification of requirements leading to the development of pieces of the
ontology at each increment; prototype (PRO), specification and ontology are built during the process
and according to the needs; iterative (ITE), each iteration advances the ontology development process,
but does not necessarily get an ontology increment at each iteration; and not defined (NO), no clearly
proposed life cycle; C7 Approach to identify concepts: bottom-up (BOT), top-down (TOP), middle-out
(MID) or not defined (NO); C8 Possible data sources for identifying ontology concepts: domain experts
(EXP), ontological resources (ONT) and data-driven (DAT); C9 Evaluation strategies for the produced
artifacts: verification with competency question or domain experts (VER), validation with instantiation
of concepts (VAL) and test with queries on the ontology (TES); C10 Expected roles in life cycle activities:
ontology engineers (OEN), knowledge engineers or knowledge workers (KEN), domain experts (DEX),
user (USE), ontology owner (OOW), ontology designer (ODE), ontology programmer (OPR), ontology
tester (OTE) or not defined (NO); C11 Method details: process (PRO), phase or stage (PHA), activity or
workflow (ACT), output (OUT), input (INP), example (EXA), tool (TOO) and not defined (NO).
To compare SABiOx with related work and baseline in a more qualitative way, we mapped their
activities to common development — specification, conceptualization, formalization, implementation and
maintenance/evolution — and support — knowledge acquisition, evaluation, integration, documentation,
reuse and configuration management — activities identified in the literature [25, 26].
Table 2 summarizes the development activities of the analyzed methods, except for maintenance/evolu-
tion, which is addressed only by LOT and OTKM as the Application/Evolution aims to keep the ontology
up to date. As noted in the table, the specification activity is not defined in DILIGENT, the conceptu-
alization activity is not defined in LOT and the implementation activity is not clear in HCOME and
Table 1
Comparison of methodologies based on the established criterion.
Method C1 C2 C3 C4 C5 C6 C7 C8 C9 C10 C11
Methontology REF NO YES NO IND PRO NO EXP VER NO PRO
OPE VAL PHA
ACT
OUT
EXA
UPON REF YES YES YES SEM INT TOP EXP VER OEN PHA
OPE INC BOT ONT VAL KEN ACT
MID DAT DEX
OTKM NO YES YES NO DEP ITE TOP EXP VER OEN PHA
BOT DAT DEX ACT
MID OUT
EXA
101 Method OPE NO YES NO IND ITE TOP EXP VAL NO PRO
BOT PHA
MID ACT
HCOME OPE YES YES NO SEM ITE NO EXP VER KEN PHA
ONT ACT
DAT TOO
DILIGENT REF YES YES NO NO ITE NO EXP VER OEN PRO
OPE KEN PHA
DEX ACT
USE INP
OUT
EXA
TOO
NeON REF YES YES YES SEM ITE TOP EXP VER DEX PHA
OPE INC BOT ONT VAL USE ACT
SEQ MID DAT OEN INP
OUT
EXA
SAMOD REF YES YES NO SEM ITE MID EXP VAL DEX PHA
OPE TES OEN
LOT REF YES YES NO SEM ITE NO EXP VER DEX PRO
OPE ONT TES OEN PHA
DAT USE ACT
OUT
EXA
TOO
SABiO REF YES YES YES IND NO NO EXP VER DEX PRO
OPE DAT VAL USE PHA
TES OEN ACT
ODE
OPR
OTE
SABiOx REF YES YES YES IND ITE TOP EXP VER OOW PRO
OPE BOT ONT VAL DEX PHA
MID DAT TES OEN ACT
INP
OUT
EXA
DILIGENT. Further, support activities are rarely addressed by methods (except the evaluation activity)
and, when addressed, do not present detailed information.
The Evaluation activity is treated in Methontology in the Evaluation phase with verification of the
ontology correctness with the specification and validation of its purpose; UPON has the Test phase with
coverage of the ontology in relation to scenarios and competency questions; OTKM has the Evaluation
phase with technical properties of the ontology and correspondence to user needs; 101 Method has the
Step 7 with the creation of ontology instances; HCOME has the Exploration phase with stakeholder
assessment of the ontology; NeON has the Evaluation activity with technical validation of requirements;
SAMOD has the Step 1 with model, data, and SPARQL query tests; LOT has the Evaluation activity
with validation of the meaning of the definitions, verification with competence questions and test case,
SABiO has the Evaluation process and the Testing phase with technical review to verify if requirements
are met (answers to competency questions) and validate by instantiation and execution of test cases
Table 2
Mapping of methods based on their development activities.
Method Specification Conceptualization Formalization Implementation
Methon- Specification phase with re- Conceptualization phase Conceptualization phase Implementation phase with
tology quirement and competency with glossary of terms, with conceptual model ontology codified in a for-
question hierarchy, instances of mal language
concepts and conceptual
model
UPON Requirement workflow Analysis workflow with Design workflow with cate- Implementation workflow
with use case and compe- resource reuse, conceptual gorization, refinement and with ontology codified in a
tency question model and glossary of organization of concepts, formal language
terms taxonomy and conceptual
model
OTKM Kickoff phase with specifi- Kickoff phase with semi- Kickoff phase with organi- Refinement phase with for-
cation and ontology reuse formal ontology descrip- zation of concepts hierar- malization of ontology into
tion chically and grouped taxonomy and appropriate
relationships
101 Step 1 with definition of the Step 3 with list of important Step 4 with definition of Step 5 and Step 6 with def-
Method domain, scope and compe- domain terms classes and hierarchical tax- inition of properties, data
tency questions onomy type and cardinality
HCOME Specification phase with re- Conceptualization phase Conceptualization phase Not defined
quirements specification with ontology reuse with ontology modeling,
integration and merging
DILI- Not defined Local Adaptation phase Build phase with building Not defined
GENT with local ontology the shared ontology and
changes Revision phase with con-
sensus changes in local on-
tologies replicated in the
shared ontology
NeON Requirements Specification Conceptualization activity Formalization activity with- Implementation activity
activity with definition of without further details be- out further details beyond without further details
purpose, scope, FRs* (com- yond organizing and struc- transforming the meaning- beyond implementing
petency questions), NFRs, turing the knowledge into ful model into a semi- the model in an ontology
intended uses, end-users, a meaningful model computable model language
implementation language
and glossary of terms
SAMOD Step 1 with description of Step 1 with definition of the Step 1 with conceptual Step 1 with converting the
motivation scenarios and glossary of terms modeling in graphical rep- model to OWL
competency questions resentation
LOT Requirements specification Not defined Conceptualization sub- Encoding subactivity of
activity with use case speci- activity of Ontology Ontology Implementation
fication and data exchange Implementation activity activity with implemen-
identification to know the with conceptual modeling tation in operational
domain, purpose and scope in graphical representation language and ontology
identification, FRs with or logical language and reuse
competency questions, nat- definition of axioms
ural language statements
or tabular information and
formalization of test cases
SABiO Purpose and Requirements Capture and Formalization Capture and Formalization Design and Implementa-
Elicitation phase with defi- phase with reuse of ontolog- phase with conceptual tion phases with specifica-
nition of purpose, intended ical and non-deontological modeling in graphical rep- tion of the design, archi-
use, FRs (competency ques- resources resentation, dictionary of tecture and environment
tions), NFRs and ontology terms, ontological analysis of the ontology and imple-
modularization and definition of axioms mentation in operational
language
SABiOx Requirements phase with Capture phase with identi- Capture phase with concep- Design and Implementa-
definition of purpose, do- fication of concepts, reuse tual modeling of a graphi- tion phases with identifica-
main dimension, FRs (com- of ontological and non- cal representation, axioms, tion of vocabularies, defini-
petency questions), NFRs ontological resources, cata- integration and modulariza- tion of structure and codifi-
and subdomains log of concepts and vision tion cation of concepts, relation-
of reused ontologies ships and axioms in opera-
tional language
* FR: Functional Requirement, NFR: Non-Functional Requirement
(queries in the operational ontology).
On the other hand, Knowledge Acquisition is only superficially treated in Methontology and SABiO,
being mentioned in OTKM, HCOME and NeON; Documentation is only superficially treated in Methon-
tology, NeON, LOT, SABiO, being mentioned in OTKM, HCOME and SAMOD; Reuse is treated in details
in NeON and LOT and superficially in SABiO, being mentioned by the other methods; Integration
is only superficially treated in Methontology and OTKM, being mentioned by NeON; Configuration
Management is only superficially mentioned in NeON and SABiO; and Publication is only treated in
LOT.
The scenario presented in this section demonstrates how current Ontology Engineering methods
detail their phases and activities and highlights the motivation to extend the SABiO method to provide
more information and clarity in the ontology development process, since gaps in the understanding and
execution of the method can impact the adoption of the methodology and the quality of the artifacts
produced. SABiOx presents complementary characteristics in relation to other methods, mainly with
respect to the proposal of: (i) guiding the development of the reference and operational ontology,
(ii) adopting a small set of roles (ontology owner, domain expert and ontology engineer), (iii) defining a
clear life cycle to follow, (iv) demonstrating the application of the method by example, and (v) providing
a detailed guide to carry out all activities proposed by the method (development and support activities).
4.2. Feedback from ontology engineers
SABiOx is the result of our experience in developing domain and core ontologies over the years and
has been maturing as new ontologies were developed using the method, until we reached the current
version presented in this article. Thus, although a recent proposal, the SABiOx method has already
been used in the development of the core ontology SCO [12] and three domain ontologies, OOC-O [9],
ORM-O [27] and DepIn-O [28], all of them performed by inexperienced ontology engineers from our
research group in academic settings. To get feedback from users of SABiOx, we asked three of the
aforementioned ontology engineers to answer a questionnaire (the author of OOC-O did not participate),
whose results are discussed as follows.
Regarding their profile, the questionnaire asked about (i) Level of education: 1 in undergraduate
studies and 2 in (post)graduate studies; (ii) Degree: 1 in Computer Engineering and 2 in Computer
Science; (iii) Experience in ontology development: 1 had already developed an ontology and 2 had not
developed any ontology before applying SABiOx; (iv) Experience in using an ontology engineering
method: 1 had used SABiO method before; (v) Challenges using other methods: again, the same subject
reported difficulty in understanding the method and how it should be applied.
Regarding the application of the SABiOx method, we observed that (i) Applied phases: all users
conducted the Requirement, Setup and Capture phases and one user also performed Design and
Implementation; (ii) Ontology type: all users developed a domain ontology; (iii) Challenges using
SABiOx: users reported difficulty in applying the activities of the configuration management process
with respect to document and ontology version control and difficulty in interpreting how to perform
some more complex activities such as ontology modeling and concept capture; (iv) Contribution using
SABiOx: all users indicated that the method contributed to the development of the ontology, reporting
that the method ensured robustness to the complete ontology construction process, from conception to
implementation, as well as enriched the documentation prepared for the ontology, guided the acquisition
of knowledge about the ontology domain and helped to understand the expected results of the activities
by providing illustrative examples.
Thus, the information obtained from the questionnaire and from our observation in the application
of the SABiOx method provide us some evidence of the contribution of the method to Ontology
Engineering, particularly for inexperienced ontology engineers, by guiding the development process
and adopting iterative and incremental cycles focused on the quality of the artifacts produced. In
this sense, we observed that the cycles allow for in-depth discussion of the domain, concepts and
modeling, contributing to its incremental maturation, that the involvement of domain experts is crucial
for the quality of the ontology, that the use of a foundational ontology offers ontological patterns
that contribute to a well-founded ontology and its interoperability, that the reuse of ontologies offers
important subsidies to advance in development more quickly and clearly, and that a guide with detailed
information and examples contributes to an ontology of quality and for the inclusion of inexperienced
engineers in the area. Of course, such evaluation is still preliminary and further efforts in applying
SABiOx are necessary for the method to gain the much desired maturity.
5. Final considerations
This article presented SABiOx, a method for Ontology Engineering that extends SABiO [7] by providing
more details on the ontology life cycle and more clearly guide the ontology construction process with
iterative and incremental cycles. Comparison with other methods proposed in the literature and feedback
from early users of SABiOx indicate that our proposal is able to fill a gap in the field, contributing with
a more opinionated process for developing ontologies, particularly suitable for inexperienced ontology
engineers.
Since the level of detail provided by the method is an important criterion to enable its maturation
and adoption, SABiOx presents in detail (but without excess) the activities that compose the phases of
the process, describing what must be done, indicating techniques and strategies for carrying them out,
as well as input/output artifacts and examples. In addition to the main activities normally addressed
by the methods, SABiOx also describes support activities that are not described (and sometimes not
even mentioned) by other methods, which might lead ontology engineers to doubts and uncertainties.
SABiOx has already been applied for the construction of ontologies containing positive and constructive
feedback, demonstrating its contribution to the area, as well as motivating its evolution and distribution
through tools and learning support.
Future work includes more experiments applying SABiOx, including practitioners in industry, and
the continuous evolution of the method, refining its process and providing tools to support it.
References
[1] K. I. Kotis, G. A. Vouros, D. Spiliotopoulos, Ontology engineering methodologies for the evolution
of living and reused ontologies: status, trends, findings and recommendations, The Knowledge
Engineering Review 35 (2020) e4.
[2] R. Iqbal, M. A. A. Murad, A. Mustapha, N. M. Sharef, et al., An analysis of ontology engineer-
ing methodologies: A literature review, Research journal of applied sciences, engineering and
technology 6 (2013) 2993–3000.
[3] M. Fernández-López, A. Gómez-Pérez, Overview and analysis of methodologies for building
ontologies, The knowledge engineering review 17 (2002) 129–156.
[4] A. S. Abdelghany, N. R. Darwish, H. A. Hefni, An agile methodology for ontology development,
International Journal of Intelligent Engineering and Systems 12 (2019) 170–181.
[5] T. Slimani, A Study Investigating Knowledge-based Engineering Methodologies Analysis, Interna-
tional Journal of Computers and Applications 128 (2015) 67–91.
[6] F. M. Mendonça, A. L. Soares, Construindo ontologias com a metodologia ontoforinfoscience: uma
abordagem detalhada das atividades do desenvolvimento ontológico, Ciência da Informação 46
(2017).
[7] R. de Almeida Falbo, Sabio: Systematic approach for building ontologies., in: Onto. Com/odise@
Fois, 2014.
[8] G. Guizzardi, On ontology, ontologies, conceptualizations, modeling languages, and (meta)models,
in: Databases and Information Systems IV – Selected Papers from the 7th International Baltic
Conference, DB&IS 2006, 2007, pp. 18–39.
[9] C. Z. d. Aguiar, R. d. A. Falbo, V. E. S. Souza, OOC-O: A Reference Ontology on Object-Oriented
Code, in: Proc. of the 38th International Conference on Conceptual Modeling, Springer, 2019.
[10] G. Guizzardi, C. M. Fonseca, A. B. Benevides, J. P. A. Almeida, D. Porello, T. P. Sales, Endurant
Types in Ontology-Driven Conceptual Modeling: Towards OntoUML 2.0, in: Proc. of the 37th
International Conference on Conceptual Modeling (ER 2018), Springer, 2018, pp. 136–150.
[11] G. Guizzardi, A. Botti Benevides, C. M. Fonseca, D. Porello, J. P. A. Almeida, T. Prince Sales, UFO:
Unified Foundational Ontology, Applied Ontology 17 (2022) 167–210.
[12] C. Z. d. Aguiar, F. Zanetti, V. E. S. Souza, Source code interoperability based on ontology, in:
Proceedings of the XVII Brazilian Symposium on Information Systems, 2021, pp. 1–8.
[13] M. Uschold, M. King, Towards a methodology for building ontologies, Citeseer, 1995.
[14] M. d’Aquin, Modularizing ontologies, Springer, 2012, pp. 213–233.
[15] A. Sattar, E. S. M. Surin, M. N. Ahmad, M. Ahmad, A. K. Mahmood, Comparative analysis of
methodologies for domain ontology development: A systematic review, International Journal of
Advanced Computer Science and Applications 11 (2020).
[16] M. Fernández-López, METHONTOLOGY: From Ontological Art Towards Ontological Engineering,
AAAI Technical Report (1997) 33–40. doi:10.1109/AXMEDIS.2007.19.
[17] A. Nicola, M. Missikoff, R. Navigli, A proposal for a unified process for ontology building: UPON,
in: International Conference on Database and Expert Systems Applications, volume 3588, Springer
International Publishing, 2005, pp. 655–664. doi:10.1007/11546924\_64.
[18] Y. Sure, S. Staab, R. Studer, On-to-knowledge methodology otkm, Handbook on ontologies (2004).
[19] N. F. Noy, D. L. McGuinness, et al., Ontology development 101: A guide to creating your first
ontology, 2001.
[20] K. Kotis, G. A. Vouros, Human-centered ontology engineering: The hcome methodology, Knowl-
edge and Information Systems 10 (2006) 109–131.
[21] H. S. Pinto, C. Tempich, S. Staab, Ontology Engineering and Evolution in a Distributed World
Using DILIGENT, Springer, 2009, pp. 153–176.
[22] M. C. Suárez-Figueroa, A. Gómez-Pérez, E. Motta, A. Gangemi, Ontology Engineering in a Net-
worked World, Springer, 2012.
[23] S. Peroni, A simplified agile methodology for ontology development, in: OWL: Experiences and
Directions–Reasoner Evaluation: 13th International Workshop, OWLED 2016, and 5th Interna-
tional Workshop, ORE 2016, Bologna, Italy, November 20, 2016, Springer, 2017, pp. 55–69.
[24] M. Poveda-Villalón, A. Fernández-Izquierdo, M. Fernández-López, R. García-Castro, Lot: An
industrial oriented ontology engineering framework, Engineering Applications of Artificial
Intelligence 111 (2022) 104755.
[25] O. Corcho, M. Fernández-López, A. Gómez-Pérez, Methodologies, tools and languages for building
ontologies. where is their meeting point?, Data & knowledge engineering 46 (2003) 41–64.
[26] Y. Sure, C. Tempich, D. Vrandecic, Ontology engineering methodologies, Semantic Web Technolo-
gies: Trends and Research in Ontology-based Systems (2006) 171–190.
[27] F. L. Zanetti, C. Z. de Aguiar, V. E. S. Souza, Representacao ontologica de frameworks de mapea-
mento objeto/relacional, in: Proc. of the 12th Seminar on Ontology Research in Brazil, 2019.
[28] C. Guterres, C. Z. de Aguiar, V. E. Souza, Depin-o: An ontology on dependency injection software
frameworks, 2023.