OntoCaimer: An Ontology Designed to Support Alzheimer’s Patient Care Systems

Abstract

Caring for Alzheimer’s patients presents significant global challenges due to complex symptoms and the constant demand for care, which are further complicated by fragmented information and a lack of explicit integration between physical and computational worlds in existing support systems. This article details the construction and validation of OntoCaimer, an ontology designed to support Alzheimer’s patient care systems by acting as a comprehensive knowledge base that integrates disease recommendations with concepts from the physical world (sensors and actuators). Utilizing METHONTOLOGY and REFSENO formalisms, OntoCaimer was built as a modular ontology. Its validation through the FOCA method demonstrated a high quality score $(\hat{\mu }=0.99)$, confirming its robustness and suitability. Case studies showcased its functionality in automating recommendations, such as managing patient locations or environmental conditions, to provide proactive support. The main contribution of this work is OntoCaimer, a novel ontology that formally integrates clinical recommendations for Alzheimer’s care with concepts from cyber-physical systems (sensors and actuators). Its scientific novelty lies in bridging the gap between virtual knowledge and physical action, enabling direct and automated interventions in the patient’s environment. This approach significantly advances patient care systems beyond traditional monitoring and alerts, offering a tangible path to reducing caregiver burden.

1. Introduction

Caring for Alzheimer’s patients represents a growing global challenge, characterized by the complexity of its symptoms and the constant demand for patient care [1]. The World Health Organization (WHO) warns that by 2021, 57 million people were diagnosed with some type of dementia [2], (Alzheimer’s disease is the most common form of dementia, being diagnosed in 60–70% of cases.) and 60% live in low- and middle-income countries [2]. Furthermore, the WHO has declared Alzheimer’s disease a global public health priority, positioning it as the seventh leading cause of death, disability, and dependency among older people around the world [1]. Furthermore, the number of patients is expected to reach 82 million by 2030 and 152 million by 2050 [2,3]. In 2019, the cost of dementia was USD 1.3 trillion, where 50% of the costs were attributable to the care required by informal caregivers (close friends, family members, or non-professionals), who provided an average of 5 h of supervision and care daily [2].

The neurodegenerative condition Alzheimer’s disease, with no known cure, is characterized by progressive cognitive decline caused by a series of diseases that, over time, destroy nerve cells and damage the brain, affecting memory, thinking, and behavior, i.e., the ability to process thought [2]. Although the patient’s consciousness is not affected, the decline in cognitive function frequently manifests alongside, and sometimes before, changes in mood, emotional control, behavior, or motivation [2]. Furthermore, dementia generates physical, psychological, social, and economic impacts, affecting not only those who suffer from it but also their caregivers, families, and society as a whole [4]. Lack of awareness and understanding of this condition often leads to stigmatization and the creation of barriers to proper diagnosis and care [4]. As the disease progresses, the dependency of the patient increases, imposing a demand for constant care, 24 h a day, 7 days a week [4]. This arduous task falls mainly on informal caregivers [2], who without remuneration or training suffer significant physical and emotional exhaustion, stress, and depression [4].

Despite the vast amount of information available through organizations, guides, and databases specializing in neurodegenerative diseases, it is dispersed and fragmented, making the development of integrated support systems difficult. In the ontological field, although models for the formalization of knowledge have been developed, they present critical gaps, such as the lack of public access to the reuse of knowledge [5]. More alarmingly, existing solutions lack an explicit integration between the physical and computational world; existing ontologies present solutions in a virtual way (messages and alerts) without the ability to directly intervene or modify the environment. This limitation affects the replicability and scalability of projects in real environments [5].

However, the integration of cyberphysical systems (CPSs) has demonstrated its potential in healthcare [6]. OntoCaimer leverages this synergy between the structured knowledge of the ontology and the ability of CPSs to interact with the real environment [7]. This enables the development of systems that not only alert to situations but also intervene directly, automating key variables such as weight, environmental control, and feeding schedule management. This capability represents a significant advancement in reducing the burden on caregivers and improving the quality of life of patients, transforming care into a more proactive and efficient process.

Taking the above into account, this article presents in detail the construction of OntoCaimer, an ontology designed for the care of patients with Alzheimer’s disease. Its purpose is to act as a knowledge base that integrates recommendations and preventive actions for the symptoms of the disease. The ontology is modular and reuses concepts from other ontologies such as SOSA [7] and QUDT [8]. Its distinctive feature is the ability to connect disease information with concepts from the physical world (sensors and actuators), allowing the development of systems that not only provide alerts but also intervene in the environment to provide direct support to the patient.

Given the identified gaps, this research addresses the following central question: How can a domain ontology be designed and validated to effectively integrate clinical recommendations for Alzheimer’s care with concepts from the physical world (sensors and actuators) to enable proactive, automated patient support? To answer this question, this paper presents OntoCaimer, a modular ontology that successfully bridges the gap between fragmented clinical knowledge and cyber-physical systems. The most relevant findings of this work include the high quality and robustness of the ontology, confirmed through a rigorous validation process using FOCA methodology, which yielded a score of $\hat{\mu }=0.99$. Furthermore, its practical applicability was demonstrated through case studies that successfully automated environmental interventions based on patient symptoms, showcasing a significant advancement toward reducing caregiver burden and improving patient quality of life. Therefore, the primary contribution of this paper is the design, implementation, and rigorous validation of a modular and reusable ontology that serves as a foundational knowledge base for developing proactive care systems. The scientific novelty of our approach is the formal and explicit integration of the computational world (disease recommendations) with the physical world (sensors and actuators), a critical step that has been overlooked by previous ontological models in this domain.

In addition to this introduction, Section 2 presents related works. Section 3 presents the theoretical and conceptual framework for ontologies, as well as the methodologies for their definition and evaluation. Section 4 presents the stages and steps taken to define OntoCaimer, as well as its implementation and limitations. Section 5 presents the results obtained from the validation of OntoCaimer using approaches such as those proposed by McDaniel and Storey [9] and the FOCA method [10,11]. This section also presents the implementation of two case studies to demonstrate its functionality, in addition to the evaluation using competency-based questions. Finally, the implications, conclusions, and future prospects for Alzheimer’s patient care are discussed in Section 6 and Section 7, respectively.

2. Related Works

The study of caring for patients with Alzheimer’s disease has generated a vast amount of information; however, a persistent lack of tools that effectively integrate the available support systems has been identified. To understand the current landscape of ontological models in this field, a systematic review of the literature was carried out, following the guidelines established by Kitchenham [12]. The search covered databases such as IEEE Xplore, Science Direct, Scopus, Springer Link, and the Web Of Science, using the string (Ontology AND Alzheimer AND care * OR take care OR assist*) for the period of 2016–2025, which resulted in the selection of 6 primary articles from the 75 initially found. It is important to note that a complementary search in ontology repositories such as BioPortal, BETA Ontohub, AberOWL Repository, and OLS Ontology did not yield relevant results for Alzheimer’s care support.

The existing ontological models identified in this review focus on various care support activities, which have been classified into four main categories: (1) provision of personalized recommendations based on the patient’s profile [13,14], (2) recognition of daily activities [15], (3) continuous monitoring of the patient [16], and (4) nutritional assistance [17,18]. Although these projects contain valuable information for care, a significant limitation is that most of these ontologies are unfortunately not publicly available, restricting the reuse of formalized knowledge by the scientific and development community. This situation, coupled with the dispersion of information on recommendations and preventive actions in unstructured sources (such as organization websites or caregiver forums), highlights the need for a consolidated and accessible knowledge base.

The identified gaps are critical and define Ontocaimer’s contribution. Mainly, existing ontological models lack explicit integration of the physical world with the computational world, i.e., current solutions tend to be purely virtual (e.g., recommendations or alerts) and do not intervene in the physical environment or modify the environmental state to directly support the patient. Although some models mention the use of sensors, they lack details on their definition, measurement methods, or the inclusion of actuators for process automation, which hinders their replicability and extension. In addition, there are challenges such as data privacy management, scalability in the number of sensors versus maintenance costs [15], and the limited flexibility of models when tested only in controlled environments [15,18]. These gaps underscore the need for approaches that not only organize knowledge but also facilitate its interaction with the physical environment to provide comprehensive and proactive support to Alzheimer’s patients.

Likewise, the symptoms presented by a patient at different stages of Alzheimer’s disease were also obtained. For this purpose, the ADO ontology [19] was reused. This ontology is the result of research conducted by the Fraunhofer SCAI Institute [20] and the NeuroAllianz consortium [21], promoted by the German Federal Ministry of Education and Research (BMBF), with the aim of improving the diagnosis of neurodegenerative diseases such as Alzheimer’s, Parkinson’s, and epilepsy. ADO is one of the first ontologies to represent the clinical characteristics, treatment, risk factors, and other aspects of Alzheimer’s disease [19]. After identifying the symptoms that appear in each stage of Alzheimer’s disease, recommendations and preventive measures were sought in the found literature. Consequently, it was necessary to extract information and concepts from these studies in order to compile as many recommendations and preventive measures as possible for most of the symptoms that an Alzheimer’s patient might present.

In addition to ontology work related to Alzheimer’s disease, it was necessary to identify work related to sensors and actuators. In this regard, the ontology proposed by the World Wide Web Consortium (W3C) called Sensor, Observation, Sample, and Actuator (SOSA) was found [7]. This ontology includes concepts and relationships for concepts such as sensors and actuators, allowing us to present the entire process necessary to measure a variable and execute actions based on a result. Due to the characteristics and concepts proposed in SOSA, it was determined that it contains the necessary information to reuse and adapt some of its concepts, thus covering three of five dimensions: the general concepts dimension, the action dimension, and the observation dimension. The other two dimensions, patient and disease, are not covered. To complement this step, some concepts and instances from the QUDT ontology [8] were included, an ontology that defines and instantiates concepts for modeling physical quantities, units of measurement, and their dimensions in various measurement systems.

3. Conceptual and Theorical Background

This section provides background information on Alzheimer’s disease and the ontologies.

3.1. Ontologies

Guarino pointed out that in its most prevalent use in artificial intelligence, an ontology is ‘an engineering artifact, consisting of a specific vocabulary used to describe a certain reality, plus a set of explicit assumptions about the intended meaning of words in the vocabulary’. He further clarified that this set of assumptions usually takes the form of a first-order logical theory, where the terms of the vocabulary appear as concepts and relationships. Furthermore, he pointed out that in more sophisticated cases, ontology includes additional axioms to express relationships between concepts and restrict their interpretation.

In [22], the main components that an ontology should have are mentioned, namely the following:

• Classes: These represent concepts in a broad sense and are usually organized into taxonomies to apply inheritance mechanisms.
• Relationships: These represent associations between concepts in the domain and are usually binary, with a defined domain and range.
• Attributes: These differ from relations in that their domain is a data type (e.g., a text string or number), while the domain of relations is a concept.
• Axioms: These are used to model statements that are always true, verify the consistency of the ontology, and infer new knowledge.
• Instances: These represent specific elements or individuals in the ontology, i.e., specific examples of the defined classes.

3.2. Types of Ontologies

According to [23], there are four types of ontologies: (1) top-level ontologies, which describe incredibly general concepts such as space, time, matter, object, event, and action, independent of a particular domain or problem, (2) domain ontologies, which describe the vocabulary related to a generic domain, such as medicine or automobiles, specializing the terms of the high-level ontology, (3) task ontologies, which describe the vocabulary related to a generic task or activity, such as diagnosing or selling, also specializing terms from the top-level ontology, and (4) application ontologies, which describe concepts that depend on both a specific domain and a specific task and are usually specializations of domain and task ontologies.

Fensel [24] proposed an alternative classification of ontologies, dividing them into four main categories: (1) generic or common sense ontologies that capture general knowledge about the world, providing basic notions and concepts about space, time, state, events, etc. which are applicable to various domains, (2) representation ontologies that do not belong to any specific domain and offer entities without predefining what they represent, instead defining concepts that express knowledge in an object-oriented or framework-oriented way, (3) domain ontologies that capture specific knowledge of a particular type of domain, such as electronics or medicine, and finally (4) method and task ontologies, which are distinguished by the fact that the former offer specific terminology for problem-solving methods, while the latter provide terms for specific tasks. Both provide a relevant perspective on domain knowledge.

3.3. Methodologies for Implementing Ontologies

There are various methodologies for systematizing the implementation of ontologies, such as ontology-based knowledge management [25], METHONTOLOGY [26], a translation approach for portable ontology specifications [27], ontologies and first-order logic (FOL) [28], and REFSENO [29]. After a detailed study of these, the METHONTOLOGY and REFSENO formalisms were chosen for the specification and conceptualization of OntoCaimer. This decision was based on the fact that REFSENO is an adaptation of METHONTOLOGY, which is widely used in different contexts. Furthermore, it is specially designed for software engineering, offering constructors that facilitate the definition of concepts, attributes, and their relationships.

The METHONTOLOGY [26] and REFSENO [29,30] methodologies were taken into account for the construction of the ontology. In summary, the combination of METHONTOLOGY and REFSENO offered a robust and specialized approach to ontology creation, particularly in the field of software engineering. METHONTOLOGY provides a systematic and rigorous methodological framework, guiding the process from specification to maintenance with a strong emphasis on documentation and continuous evaluation. REFSENO complements this structure by offering a representation formalism specifically designed for software engineering, enabling explicit, consistent, and adaptable modeling of domain knowledge, and integrating functionalities such as case-based reasoning. In this way, METHONTOLOGY ensures the quality of the development process, while REFSENO guarantees the suitability and accuracy of the semantic content for the specific domain.

Unlike other methodologies that may be less intuitive or more complex for those unfamiliar with first-order predicate logic, REFSENO provides techniques that support analysis of the consistency of an ontology and its instances. In REFSENO, knowledge is represented at two levels of abstraction: the level of knowledge, which describes ‘what’ to represent and is independent of implementation, and the level of symbols, which describes how to represent it through implementation [29]. In addition, REFSENO proposes three levels of knowledge: epistemological (primitives such as concepts, attributes, and relations), conceptual (standard vocabulary), and linguistic (concrete instances). For the construction of an ontology at the conceptual level, REFSENO suggests the stages of construction, evolution, and validation. For OntoCaimer, descriptive logic (DL) was also incorporated due to its greater expressiveness than propositional logic [31].

The effectiveness of these methodologies for systematizing the implementation and evaluation of ontologies is not intrinsic; on the contrary, their success lies in the interaction of multiple critical factors. These include the experience of the development team, the inherent complexity of the domain to be modeled, and the specific objectives pursued by the project. Fortunately, our team has a proven track record in applying these methodologies, which allows us to ensure that our approach aligns with best practices in knowledge representation through ontologies.

3.4. Evaluation of Ontologies and Domain Ontologies

Ontologies are evaluated through the verification and validation processes. This involves a rigorous analysis of both the ontology construction process and the precision with which it represents the knowledge domain to which it applies [32,33,34].

According to [9], to evaluate a domain ontology, it is essential to consider five main types of approaches, each addressing different aspects of the ontology’s quality and usefulness:

• Domain or Task Fit: This evaluates how well the ontology fits the specific domain or task for which it was designed. This involves analyzing whether the concepts and relationships represented are relevant and appropriate for the context of use.
• Error Checking: This focuses on identifying errors within the ontology, such as logical inconsistencies, redundancies, or incorrect definitions. This step is essential to ensure the validity and internal consistency of the ontology.
• Libraries: This involves comparing the ontology with existing ontology libraries or repositories to verify its alignment with recognized standards and its interoperability with other ontologies.
• Metrics: This uses quantitative metrics to evaluate characteristics such as the complexity, coverage, modularity, and maintainability of the ontology. These metrics allow for an objective and comparative evaluation between different ontologies.
• Modularization: This analyzes the modular structure of the ontology, evaluating whether it is organized into independent and reusable modules, which facilitates its maintenance and future extension.

Applying these five types of evaluation provides a comprehensive view of the quality of an ontology, ensuring that it is accurate, useful, and sustainable over time.

McDaniel and Storey [9] proposed an evaluation pipeline as a comprehensive strategy to ensure the quality of ontologies and improve their availability for reuse. This pipeline allows combining different evaluation approaches and integrating elements from the five identified classes, which enables a more complete and accurate assessment. Using the pipeline, either in whole or in part, facilitates the validation and improvement of ontologies and can be adapted to address various problems related to their evaluation. Thus, the pipeline not only systematizes the evaluation process but also promotes the adoption of quality standards and the reuse of ontologies in different contexts. The pipeline is organized into two phases: validation and improvement. The validation phase suggests checking fitness, removing errors, and applying metrics. The improvement phase suggests pruning, modularizing, and placing in a library.

According to [9], the reasons for using the domain ontology evaluation approach include (1) interoperability and accurate modelling, as high-quality ontologies are essential for interoperability between software applications and for accurately modelling a domain of interest, (2) difficulty in finding suitable ontologies, as it is difficult for knowledge engineers to find an appropriate ontology for a specific application, often forcing them to create new ontologies, (3) the need for effective tools, as effective tools are required to adequately address the problem of ontology selection and evaluation, and (4) the importance of systematic evaluation, as evaluating the quality of an ontology is essential to ensure that the task is performed accurately, whether selecting or creating a new ontology.

4. Materials and Methods

This section presents the steps taken to define OntoCaimer. Taking into account the previous section, the structures and artifacts of Methontology and REFSENO were used in the design of OntoCaimer, and the following stages were followed, which are described in detail in this section: (1) the scope, objective, conceptual representation, and scope of the ontology, (2) knowledge acquisition, (3) conceptualization of knowledge, (4) implementation of the ontology, and finally (5) recommendations for use. Each of these stages is presented in detail in the following sections. In addition, the ontology was validated using the pipeline proposal by McDaniel and Storey [9]. This issue is addressed in detail in Section 5.

4.1. Scope, Objective, Conceptual Representation, and Scope of the Ontology

OntoCaimer is a formal representation of knowledge for the care of Alzheimer’s patients. In this sense, it emerges as a valuable resource for the scientific community, providing a solid knowledge base for future research and the development of electronic systems or simulations focused on the care of patients with Alzheimer’s disease.

The scope defined for OntoCaimer is to serve as a source of information on recommendations and preventive actions for the different symptoms suffered by Alzheimer’s patients. In addition, it provides its users with a bridge between knowledge of the disease and concepts from the physical world, such as sensors and actuators. This is why it is called OntoCaimer (Onto = ontology, Ca = care, and Imer = Alzheimer’s). In electronics, an actuator is a device that transforms an electrical signal into a mechanical force or movement. In other words, it converts electrical energy into physical action. This is why Ontocaimer can be used as a basis for the development of systems that not only alert to potential problems but also use actuators to provide direct support to the patient. The ability of OntoCaimer to automate key variables such as weight, environment, and feeding schedules represents a significant advance in reducing the burden on caregivers and improving the quality of life of patients.

The relationships in Ontocaimer were based on UML class diagrams [35] (see Figure 1), covering (1) association, to establish the link between classes without a specific dependency relationship, (2) directed association, to indicate a relationship with a defined direction between classes, (3) aggregation, to denote a relationship where the existence of the child concept does not depend crucially on the parent concept, (4) composition, for those cases that involve establishing a relationship where the child concept depends heavily on the parent concept, often representing mandatory concepts, and (5) inheritance, to represent a child concept as a specialization of a parent concept.

Figure 1. UML representation of OntoCaimer. Source: the authors.

The main objective of OntoCaimer is to offer a platform that contains concepts related to the support and management of symptoms suffered by Alzheimer’s patients in each stage of the disease and which also covers knowledge about sensors and actuators. Having these two areas covered allows the systems that are proposed and developed to be used as a knowledge base or as a basis for creating artifacts that interact with the real world, giving the user design flexibility. The details of all the concepts covered by the ontology can be found later in the implementation stage in Section 4.3.

The applications of OntoCaimer are mainly in academia and healthcare. In the academic field, academic, technological, or healthcare research groups will be able to use their knowledge and understand the terms and relationships between the tacit and real worlds and learn how different concepts associated with disease can be automated. For example, a recommendation may have variables. In this case, a variable could be the patient’s weight, room lighting, or patient position, among others. These variables can be measured and generate an action when the variable is outside of a normal range. Some examples would be (1) if the patient is extremely overweight, then the system could automatically request an appointment with a doctor; (2) if the light in the room is too low, then it could turn on the lamps; or (3) if the patient is outside a safe area, then it could send an alert to the caregiver. In the field of healthcare, OntoCaimer can be used as a basis to develop a care system for patients with Alzheimer’s. These types of systems can be used in nursing homes, hospitals, or homes for the elderly. In this case, OntoCaimer presents an example of how to automate a set of recommendations for certain symptoms using sensors. This example is presented in Ontocaimer Application, Section 5.5.

4.2. Knowledge Acquisition

The knowledge acquisition process was divided into two steps. The first involved acquiring concepts related to Alzheimer’s disease, symptoms, recommendations, and preventive measures. The second step involved acquiring concepts related to sensors and actuators. After these steps were completed, the knowledge was unified. The analysis of related work on the acquisition of knowledge about the acquisition of concepts related to Alzheimer’s disease, sensors, and actuators was addressed in detail in Section 2 on related work.

4.3. Conceptualization of Knowledge

Based on the results obtained in the previous process, it was possible to obtain concepts and relationships that represent an overview of the symptoms suffered by a patient with Alzheimer’s, recommendations and preventive actions, and real-world (physical-world) concepts, namely sensors and actuators. After the creation of OntoCaimer, it was evaluated and improved. This process is explained in Section 5, related to the evaluation of the ontology.

Figure 1 shows a graphical representation in UML of the concepts and relationships established in Ontocaimer. As can be seen, each color identifies a group of terms in the ontology. For example, purple corresponds to the dimension of the patient, light blue corresponds to the dimension of the disease, and the other colors correspond to the relationships of concepts from another widely used subontology known as SOSA [7], which is a lightweight ontology for sensors, observations, samples, and actuators. Table 1 and Table 2 present in detail the concepts of Ontocaimer and its relationships, respectively.

Table 1. OntoCaimer glossary of concepts. Source: the authors.

Dimension	ID	Term	Definition	Source
OntoCaimer: Patient dimension	1	Person	A human being who can be male or female. In this definition, they can be a patient or a caregiver.	Own definition.
	2	Caregiver	A person in charge of the well-being of a patient suffering from Alzheimer’s.	Own definition.
	3	Patient	A person diagnosed with Alzheimer’s by a specialist.	Own definition.
	4	DailyActivity	Activities that a patient performs in their daily life, e.g., bathing, eating, or taking medication.	Own definition.
	5	Room	A place where the patient may be, e.g., a bedroom, bathroom, living room, or dining room.	Own definition.
OntoCaimer: Disease dimension	6	Stage	Alzheimer’s is a disease that presents different stages; this concept refers to these stages.	Own definition.
	7	Recommendation	Actions recommended to the caregiver to avoid or reduce the symptoms that a patient may present in the different stages of Alzheimer’s.	Own definition.
	8	Symptom	A perceived change in function, sensation, or appearance reported by a patient indicative of a disease.	Taken from [19].
	9	Changes_in_sleep_patterns	The patient experiences changes in sleep patterns, such as sleeping during the day and being awake at night.	Taken from [36].
	10	Confusion_about_where_they_are_or_what_ day_it_is	The patient is confused about the current location and date.	Taken from [36].
	11	Delusion_and_paranoia	Delusions and paranoia: the patient believes fictional scenarios are real, e.g., that their partner is in love with someone else or that their caregivers want to hurt them.	Taken from [19].
	12	Difficulty_to_walk_or_sit	The patient has difficulty walking or sitting.	Taken from [19,36].
	13	Difficulty_in_doing_tasks_involving_ multiple_steps	The patient has difficulty performing tasks involving multiple steps.	Taken from [19].
	14	Difficulty_swallowing	When eating, the patient has difficulty swallowing food.	Taken from [19].
	15	Experiencing_increased_trouble_with_ planning_or_organizing	The patient experiences problems planning or organizing.	Taken from [36].
	16	Getting_lost	Regardless of where they are, the patient may get lost, whether at home or on the street.	Taken from [19].
	17	Groaning_moaning_or_grunting	The patient makes sounds such as groans or moans.	Taken from [19].
	18	Impulsive_behavior	The patient behaves impulsively.	Taken from [19].
	19	Inability_to_communicate	Inability to communicate.	Taken from [19].
	20	Inability_to_recognize_oneself_or_family	Inability to recognize oneself or one’s family.	Taken from [19].
	21	Increased_memory_loss_and_confusion	Increased memory loss and confusion.	Taken from [19].
	22	Increased_sleeping	The patient experiences increased sleepiness.	Taken from [19].
	23	Lack_of_control_of_bowels_and_bladder	Lack of bowel and bladder control.	Taken from [19].
	24	Losing_things_or_misplacing_them	The patient tends to lose or misplace things.	Taken from [19].
	25	Mood_and_personality_changes	Changes in mood and personality.	Taken from [19].
	26	Poor_judgment	The patient experiences poor judgment.	Taken from [19].
	27	Problems_coping_with_new_situations	Problems coping with new situations, schedule changes, or an unexpected doctor’s appointment.	Taken from [19].
	28	Problems_recognizing_family_and_friends	Problems recognizing family and friends.	Taken from [19].
	29	Repeating_questions	Repeating questions, despite receiving an answer.	Taken from [19].
	30	Repetitive_behavior	Repetitive behaviors, such as wringing hands or shredding tissues.	Taken from [36,37].
	31	Seizure	Seizure.	Taken from [19].
	32	Skin_infection	Skin infections.	Taken from [19].
	33	Sundowning	This symptom occurs in the afternoon. The patient may become upset or disoriented, see or hear things that are not there, and attempt to leave the house.	Taken from [37,38].
	34	Taking_longer_than_before_to_complete_ normal_ daily_tasks	The patient takes longer to complete daily tasks.	Taken from [19].
	35	Trouble_handling_money_and_paying_bills	Problems handling money and paying bills.	Taken from [19].
	36	Weight_loss	The patient experiences weight loss.	Taken from [19].
	37	Unit	Represents the various standards of quantity and units, e.g., kilograms, meters, or feet.	Taken from [8].
SOSA: Observation dimension	38	Observation	Act of carrying out an observation to estimate or calculate the value of a feature of interest (FeatureOfInterest). This class allows connecting to a sensor (Sensor), which was measuring (ObservableProperty) on that object of interest (FeatureOfInterest).	Taken from [7].
	39	ObservableProperty	Observable property or characteristic of the object of interest (FeatureOfInterest), e.g., the height of a tree, the depth of a lake, or the temperature of a surface.	Taken from [7].
	40	Sensor	A device or agent, including humans or software involved in a process. Sensors respond to a stimulus that the sensor is observing, generating a result (Result), e.g., accelerometers, gyroscopes, and barometers.	Taken from [7].
SOSA: Actuation dimension	41	Actuation	Carries out a process or action (Actuation) to change the state of an object using an actuator (Actuator).	Adapted from [7].
	42	Actuator	Device that is used by an actuation (Actuation) to change the state of the world, e.g., a device that can automatically open or close a window.	Taken from [7].
	43	ActuableProperty	Property of an object that is actionable, e.g., the ability of a window to open or close.	Taken from [7].
SOSA: General concepts	44	FeatureOfInterest	Object of interest that has a property, which is estimated or calculated using an observation (Observation) to obtain a result (Result) or a property that is being altered by an actuator (Actuator). For example, when measuring the height of a tree, the height is the observable property (ObservableProperty), 20M is the result (Result), and the tree is the object of interest (FeatureOfInterest).	Taken from [7].
	45	Platform	A platform is an entity that hosts a sensor (Sensor), an actuator (Actuator), or other platforms (Platform).	Taken from [7].
	46	Result	The result (Result) of an observation (Observation) or action (Actuation).	Taken from [7].

Table 2. OntoCaimer’s glossary of relationships. Source: the authors.

ID	Term	SC 1	Definition	Source
1	actsOn	Actuator-ActuableProperty	An actuator acts on an actionable property.	Source: own.
2	actsOnProperty	Actuation-ActuableProperty	An actuation acts on an actionable property.	Taken from [7].
3	areDoneBy	DailyActivity-Patient	A daily activity is performed by a patient. Inverse of Does.	Source: own.
4	belongsTo	Symptom-Stage	A symptom belongs to a stage.	Source: own.
5	does	Patient-DailyActivity	A patient performs one or more daily activities.	Source: own.
6	hasFeatureOfInterest	Actuation or Observation-FeatureOfInterest	This has an object of interest, and an actuation (Actuation) or an observation (Observation) has an object of interest.	Taken from [7].
7	hasRecommendation	Symptom-Recommendation	This has a recommendation, and a symptom (Symptom) has one or more recommendations (Recommendation).	Own source.
8	hasResult	Actuation or Observation-Result	This has a result, and an actuation (Actuation) or observation (Observation) has a result (Result).	Taken from [7].
9	hasSymptom	Stage-Symptom	This has symptoms, and a stage (Stage) has one or more symptoms (Symptom). It is the inverse of belongsTo.	Own source.
10	Hosts	Platform-Actuator or Sensor	A platform hosts an actuator or a sensor.	Taken from [7].
11	isActedOnBy	ActuableProperty-Actuator	An actionable property (ActuableProperty) is activated by an actuator. It is the inverse of actsOn.	Taken from [7].
12	isCaredBy	Patient-Caregiver	A patient is cared for by a caregiver. It is the inverse of takesCare.	Source: own.
13	isFeatureOfInterestOf	FeatureOfInterest-Actuation or Observation	An object of interest is a characteristic of an actuation or an observation.	Taken from [7].
14	isHostedBy	Actuator or Sensor-Platform	This is hosted by an actuator (Actuator), or a sensor (Sensor) is hosted by a platform (Platform).	Taken from [7].
15	isInTheRoom Patient-Room	This is in the room. A patient (Patient) is in a room (Room).	Own source.
16	isObservedBy	ObservableProperty-Sensor	This is observed such that an observable property (ObservableProperty) is observed by a sensor (Sensor).	Taken from [7].
17	isPatient	Room-Patient	This is the patient. In a room (Room), there is the patient (Patient). The inverse of this is in the room (isInTheRoom).	Own source.
18	isRecommended	Recommendation-Symptom	This is recommended. A recommendation (Recommendation) is recommended for a symptom (Symptom). Inverse of has recommendation (hasRecommendation).	Own source.
19	isResultOf	Result-Actuation or Observation	A result (Result) is the result of an actuation (Actuation) or observation (Observation).	Taken from [7].
20	isSufferedBy	Symptom-Patient	A symptom (Symptom) is suffered by a patient (Patient). Inverse of suffers (suffers).	Own source.
21	madeActuation	Actuator-Actuation	An actuator makes an actuation.	Taken from [7].
22	madeByActuator	Actuator-Actuator	An actuation is made by an actuator.	Taken from [7].
23	madeBySensor	Observation-Sensor	An observation (Observation) is made by a sensor (Sensor).	Taken from [7].
24	madeObservation	Sensor-Observation	A sensor (Sensor) makes an observation (Observation).	Taken from [7].
25	observedProperty	Observation-ObservableProperty	In Spanish, an observation (Observation) observes an observable property (ObservableProperty).	Taken from [7].
26	Observes	Sensor-ObservableProperty	In Spanish, a sensor (Sensor) observes an observable property (ObservableProperty).	Taken from [7].
27	suffers	Patient-Symptom	In Spanish, a patient suffers from one or more symptoms (Symptom).	Own source.
28	takesCare	Caregiver-Patient	In Spanish, cuida; a caregiver takes care of one or more patients.	Source: own.
29	unit	Result-Unit	In Spanish, unidad; a result has a unit of measurement (Unit) as its unit.	Taken from [8].

¹ Super Concept.

4.3.1. Ontocaimer Concepts and Relationships

The concepts defined in OntoCaimer are presented in Table 1, which has the following columns. The first column contains the name of the dimension or category to which the concept belongs according to Figure 1, followed by the identifier to easily locate it. Then there is the definition of the concept, and finally, the fourth column indicates the source of information from which the concept was obtained, which can be one of three types:

• Taken from [«Reference»]: This indicates that the definition of the term has been used exactly as defined in the source «reference», i.e., no modifications or alterations have been made to its content.
• Adapted from [«Reference»]: This indicates that the definition in the third column is an adaptation of the original definition taken from the source «reference» indicated.
• Own definition: This indicates that the definition in the third column represents a new proposal based on the research carried out.

The relationships between the concepts used in OntoCaimer are explained in detail in Table 2, which includes the name of the relationship, the related concepts, their descriptions, and the source of information from which they were obtained.

4.3.2. Recommendation Instances

Ontocaimer compiles recommendations and preventive actions for most of the symptoms that an Alzheimer’s patient may experience at their different stages. Therefore, the recommendations compiled in the previous phase were not added as a subclass of the concept ’Recommendation’ but were instantiated in this class. To facilitate understanding of these concepts, recommendations and preventive actions were grouped according to the stage of Alzheimer’s disease in which the symptom manifests itself. These characteristics of Ontocaimer are presented in detail in a repository on Zenodo through the following link accessed on 1 September 2025: https://doi.org/10.5281/zenodo.16884234. This information contains the recommendations for early-stage symptoms, moderate-stage symptoms, and severe-stage symptoms. Table 3 presents an example of two symptoms of the severe stage with their respective recommendations.

Table 3. Sample of recommendations for severe Alzheimer’s disease. Source: the authors.

Symptom	ID	Attribute	Value
Seizure	1	DescriptionRecommendation	Keep the patient safe and comforted.
	2		Place something soft under the patient’s head.
	3		Remove glasses.
	4		Move any heavy or sharp objects out of the way, e.g., chairs or tables.
	5		Lay the patient on their side.
	6		Call an emergency service if the patient is injured or the seizure lasts more than two minutes.
Weight loss	7	DescriptionRecommendation	Avoid food outside of schedule.
	8		Ensure patient’s dentures are properly fitted.
	9		The eating area should be quiet and calm.
	10		Serve meals at the same time.
	11		The patient should not lose more than 5 kg in weight monthly.

4.4. Implementation of the Ontology

There are a variety of languages and formalisms for implementing an ontology, some of which are as follows: Ontolingua [39], OntoEdit [40], and Protégé [41]. This work was carried out with Protégé because its user interface is user-friendly and intuitive, and its features allow the creation, editing, and verification of ontologies and extraction of knowledge bases. In addition, this editor has strong support from the academic, governmental, and corporate communities. The version used for the implementation of Ontocaimer was Protégé version 5.5.0, which can be downloaded through the following link created on GitHub, thus facilitating its replicability and extension for the community and interested researchers accessed on 1 September 2025: https://github.com/ldlasso2/OntoCaimer/blob/master/Protege-5.5.0-win.zip. In addition, Web Ontology Language (OWL) was used, mainly because Protégé allows the creation and implementation of OWL ontologies and because, according to the World Wide Web Consortium (W3C), Web Ontology Language (OWL) is a language that facilitates the automatic interpretation of content and provides additional information and vocabulary along with formal semantics, making it a more favorable choice than other languages such as Extensible Markup Language (XML), Resource Description Framework (RDF), and RDF Schema (RDF-S). As a result, each Ontocaimer concept became a class, each attribute became a data property across domains, and each relationship became an object property.

Limitations and Recommendations for Using OntoCaimer

This section aims to provide a realistic view of ontology, detailing the aspects that readers should take into account when using or extending OntoCaimer.

• OntoCaimer uses some concepts from the SOSA ontology. However, when instantiating the Actuation or Actuator concept, an error occurred in the inferences, as it inferred that both concepts were the same. This is because in the original design presented in [7], the ‘actsOnProperty’ relationship connects ActuableProperty with the two concepts mentioned, Actuation and Actuator, generating an erroneous inference. For this reason, ‘actsOn’ was created, a relationship that links Actuator with ActuableProperty, replacing ‘actsOnProperty’ between the three concepts and correcting the erroneous inference.
• As shown in Figure 1, the patient and disease dimensions are linked to the SOSA observation dimension through the relationships ‘hasFeatureOfInterest’, ‘isFeatureOfInterestOf’, ‘hosts’, and ‘isHostedBy’. This link originates from the concepts Patient and Room because the design proposed by the authors uses Room as the location for sensors and actuators and Patient as a feature of interest for the theoretically created automation system. This does not mean that only these two concepts can be used as shown in Figure 1 (it is a design proposed by the authors); the other concepts can be used as the OntoCaimer user wishes. For example, a symptom can be a feature of interest, or a caregiver can host the sensor. This all depends on the design of the solution.
• One way to evaluate and improve the understanding of an ontology is to implement the concepts through an example. Examples of this ontology can be found in Section 5.5, related to Ontocaimer application. For OntoCaimer, two patients were simulated with their caregiver, and it automated recommendations associated with the symptoms suffered by these patients. To accomplish this, rules and reasoners are used to activate or deactivate actuators and generate alert messages and other responses that seek to support patient care. It is important to emphasize that the design and automation presented in the examples are not intended to limit or establish how OntoCaimer users can design their solutions; they are simply examples of how concepts can be used.
• OntoCaimer does not seek to replace healthcare or care specialists; its main objective is to support the development of systems that help caregivers in this arduous task.

5. Results

This section presents the validation of OntoCaimer. Ontologies, despite containing information, can have flaws in their design and construction. Therefore, for the validation of OntoCaimer, the steps suggested by Mcdaniel and Storey [9] were followed. They proposed three phases for validating an ontology: (1) checking suitability, which refers to verifying the ontology’s capacity for a specific task and domain, followed by (2) cleaning practices that seek to eliminate errors and finally (3) applying quality metrics to the ontology, with the first step being carried out using the FOCA method [10,11]. In addition to these steps, the following were carried out: (4) creating OntoCaimer instances based on the automation of two cases and (5) applying competency questions.

5.1. Verifying Domain and Task Suitability

To validate OntoCaimer, we began by checking its domain and task suitability. For this step, the FOCA methodology proposed by Bandeira et al. [10,11] was used, which supports the self-evaluation of ontologies based on quality criteria proposed by Vrandečić [42], including completeness, adaptability, conciseness, consistency, computational efficiency, and clarity. Quality criteria are compared with five knowledge representation roles proposed by Bandeira et al. [10,11], including substitution, ontological commitments, intelligent reasoning, efficient computation, and human expression [43]. Based on their similarity, and using the goal, question, metric (GQM) approach to metric design in software engineering [44]. An evaluation was designed that allowed the quality of the ontology to be calculated, minimizing subjectivity with awareness and objectivity. FOCA suggests three steps, which are described in detail below:

• Step 1: Define the ontology type. According to the four types of ontologies proposed by Guarino [23] and discussed in detail in Section 3, there are four types of ontologies: (1) high-level ontologies, (2) domain ontologies, which are responsible for describing the vocabulary related to a generic domain, (3) task ontologies, which describe the vocabulary related to a generic task or activity, and (4) application ontologies. It is possible to see and determine that OntoCaimer is a type 2 ontology, i.e., a domain ontology.
• Step 2: Execution of the questions. Being a domain ontology, the FOCA methodology poses a group of questions where the ontology is evaluated based on completeness, adaptability, conciseness, consistency, computational efficiency, and clarity. In Table 4, these questions and their respective answers are presented.
  Table 4. Sample excerpt on recommendations for severe Alzheimer’s disease. Source: the authors.

  ID	Goal	Question	Metric	Rating	Average
  1	Check if the ontology meets the surrogate role.	Q1. Were the competency questions defined?	1. Completeness	100	100
  		Q2. Were the competency questions answered?	1. Completeness	100
  		Q3. Did the ontology reuse other ontologies?	2. Adaptability	100
  2	Check whether the ontology meets the ontological commitments role.	Q4. Did the ontology impose a minimum ontological commitment?	3. Conciseness	*	75
  		Q5. Did the ontology impose a maximum ontological commitment?	3. Conciseness	50
  		Q6. Are the ontology’s properties consistent with the domain?	4. Consistency	100
  3	Check if the ontology meets the intelligent reasoning role.	Q7. Are there contradictory axioms?	4. Consistency	100
  		Q8. Are there redundant axioms?	3. Conciseness	100	100
  4	Check if the ontology meets the efficient computing role.	Q9. Did the reasoner introduce modeling errors?	5. Computational efficiency	100
  		Q10. Did the reasoner execute quickly?	5. Computational efficiency	100	100
  5	Check if the ontology meets the human expression role.	Q11. Is the documentation consistent with the modeling?	6. Clarity	100	66.6
  		Q12. Were the concepts well written?	6. Clarity	100
  		Q13. Are there annotations in the ontology that show the definitions of the concepts?	6. Clarity	0

  * Due to the type of ontology, this question does not apply.
• Step 3. Quality calculation. After answering the questions from the previous step, the quality of the ontology was calculated while considering the five goals mentioned above. To ensure the robustness of our domain ontology, we employed a structured approach rooted in the goal, question, metric (GQM) paradigm. This systematic verification process encompassed five distinct objectives, which were thoroughly explored through 13 specific questions. The evaluation of these questions was quantified using six carefully selected metrics. Based on the methodology proposed by Bandeira et al. [11], we established precise validation criteria for each question. This allowed us to objectively determine the extent to which the ontology satisfied the intent of each question, assigning a numerical score on a scale from 0 to 100. The culmination of this detailed assessment involved calculating the average score for each objective, providing a comprehensive measure of the ontology’s validity.
  Verifying the quality of an ontology is a crucial step. Bandeira et al. [11] proposed two methods for this calculation: full quality and partial quality. For this work, full quality verification was chosen due to its capacity to consider the five knowledge representation roles embedded in the five goals in Table 4: (1) the surrogate role, (2) the ontological commitments role, (3) the intelligent reasoning role, (4) the efficient computation role, and (5) the human expression role. To calculate the overall quality of the ontology, the beta regression model developed by Ferrari and Cribari-Neto [45] was employed. Beta regression is a data modeling technique that is well suited to this type of analysis. The quality of the ontology is calculated using beta regression models, with its result ranging from 0 to 1 (see Equation (1)), where 0 indicates that the quality of the ontology is quite low and 1 indicates that the quality is quite high [10,11].
  The criteria used to calculate the overall quality are detailed below. Using Equation (1), an evaluator i must calculate the overall quality of the ontology ${\hat{\mu }}_i$ while considering the following:

  -

  $Co{v}_s$: This is the average of the scores obtained in objective 1, meaning the average of P1, P2, and P3.

  -

  $Co{v}_c$: This is the average of the scores obtained in objective 2, meaning the average of P5 and P6.

  -

  $Co{v}_R$: This is the average of the scores obtained from objective 3.

  -

  $Co{v}_{cp}$: This is the average of the scores obtained from objective 4.

  -

  $LExp$: This variable refers to the evaluator’s experience. If the evaluator is considered to be quite experienced, then the value of the variable will be one; otherwise, it is zero.

  -

  $Nl$: This is used only if it was impossible for the evaluator to answer all the questions for some objective.

  -

  $Sb=1$, $Co=1$, $Re=1$, $Cp=1$, because the total quality considers all roles.

  Substitution ($Sb$) assesses the ontology’s ability to model the domain; ontological commitment ($Co$) measures its adherence to ontological principles; intelligent reasoning ($Re$) examines its support for inference processes; and efficient computing ($Cp$) refers to its computational ease of processing. It is important to note that the role of human expression, although not explicit in the equation, is implicit in the process, since it directly depends on the evaluator’s knowledge and skill in interpreting and responding to all queries, influencing the application and understanding of the other criteria.

Taking into account Equation (1), and by replacing the values it suggests with those in Table 4, Equation (2) was obtained. Then, the operations were developed, and the final result of Equation (3) was obtained, where it can be observed that the total quality of OntoCaimer was $\hat{\mu }=0.99$, concluding that it is a high-quality ontology:

$${\hat{\mu }}_i={\displaystyle \frac{exp\left(-0.44+0.03{(Co{v}_s\times Sb)}_i+0.02{(Co{v}_c\times Co)}_i+0.01{(Co{v}_R\times Re)}_i+0.02(Co{v}_{cp}\times Cp)-0.661LEx{p}_i-25{(0.1\times Nl)}_i\right)}{1+exp\left(-0.44+0.03{(Co{v}_s\times Sb)}_i+0.02{(Co{v}_c\times Co)}_i+0.01{(Co{v}_R\times Re)}_i+0.02{(Co{v}_{cp}\times Cp)}_i-0.661LEx{p}_i-25{(0.1\times Nl)}_i\right)}}$$

(1)

$$\hat{\mu }={\displaystyle \frac{exp\{-0.44+0.03\times (100\times 1)+0.02\times (75\times 1)+0.01\times (100\times 1)+0.02\times (100\times 1)-0.66\times 0-25\times (0.1\times 0\left)\right\}}{1+exp\{-0.44+0.03\times (100\times 1)+0.02\times (75\times 1)+0.01\times (100\times 1)+0.02\times (100\times 1)-0.66\times 0-25\times (0.1\times 0\left)\right\}}}$$

(2)

$$\hat{\mu }={\displaystyle \frac{exp\{-0.44+3+1.5+1+2-0-0\}}{1+exp\{-0.44+3+1.5+1+2-0-0\}}}={\displaystyle \frac{exp\left\{7.06\right\}}{1+exp\left\{7.06\right\}}}=0.99$$

(3)

The OntoCaimer ontology stands out for its high quality, evidenced by a FOCA score close to one, which positions it as an exceptional model in the five roles defined by Bandeira et al. [11] as follows. (1) Surrogate role: it acts as a coherent substitute by aligning its documentation with the modeled concepts. (2) Ontological commitments role: it fulfills its ontological commitments by presenting precise and domain-specific definitions; (3) Intelligent reasoning role: it enables intelligent thinking without generating inconsistencies; (4) Efficient computation role: it demonstrates computational efficiency with satisfactory response times. (4) Human expression role: it facilitates human expression, being easily understandable for experienced users, although it requires a brief learning curve for those new to the field.

Ontology assessment often faces the challenge of subjectivity in scoring. To mitigate this and improve transparency, the scoring criteria were described in detail with clear examples to reduce individual bias. Each rater reviewed the ontology independently following predefined criteria, and the scores were discussed as a group until a consensus was reached, ensuring a collective judgment over personal opinions. Furthermore, to ensure replicability, meticulous documentation of the entire process was provided, including a detailed description of the criteria, step-by-step instructions for the assessment, and the standardized forms used by the raters. Although subjectivity is never completely eliminated, this structured, systematic approach and the use of multiple raters significantly contribute to a more objective and reliable assessment.

5.2. Troubleshooting

According to Mcdaniel and Storey [9], cleaning and correcting errors is necessary to make the ontology usable. This process includes removing synthetic errors, reviewing inconsistencies, and reducing redundancies. For these, two solutions were used. The first was to use a web tool called OntOlogy Pitfalls Scanner! (OOPS!) [46] (link accessed on 1 September 2025: https://oops.linkeddata.es), which allows for finding flaws in the structural, functional, and usability areas of the ontology. Second, the solution called Ontology Taxonomy Evaluation proposed in [47] was used. This method consists of verifying the three main factors in an ontology. These factors help ensure the quality and usefulness of the ontology:

• Inconsistency: This refers to errors such as circularity (a class defined as a specialization or generalization of itself), partitioning errors (incorrect definition of disjoint classes or incomplete definition of classes), and semantic errors (a class is a subclass of another to which it does not belong).
• Incompleteness: This refers to the lack of domain concepts in the taxonomy or undefined relationships between classes, such as unspecified disjoint classes or the lack of coverage of all individuals of a class by its subclasses.
• Redundancy: This refers to the presence of redundant grammatical definitions (more than one definition for a class or relationship) or identical formal definitions of classes or instances with different names.

As a result of using OOPS!, a report was obtained where one can see the common errors that the ontology presents in addition to their details. This report is presented in web format, and thus screenshots were taken of the results obtained by OntoCaimer. These images can be observed in a complete and complementary way through the following link to the project repository in Zenodo accessed on 1 September 2025: https://doi.org/10.5281/zenodo.16887263. Table 5 presents a summary and abstraction of the information in these images, where the faults and errors that OntoCaimer presented during its evaluation are presented. Therefore, not all the errors that OOPS! detected are shown. As seen in Table 5, the error identified in OOPS! comes with a nomenclature that begins with the letter P followed by the error number and its definition, followed by the level in which the error was found, the number of concepts in which said error was presented, and finally the reason why these errors were presented in OntoCaimer. The levels presented in column 2 are defined by OOPS!, which are (1) critical, where it was considered crucial to correct the error, otherwise it could affect the consistency, reasoning, and applicability in other features of the ontology, (2) important, where it was considered important to correct this error, though not as critical as the previous level, and (3) minor, where it was considered to not be a problem, but its correction would make the ontology more attractive.

Table 5. Summary of the OntoCaimer evaluation results using OOPS!. Source: the authors.

ID	Error	Level	Cases	Reason
1	P07, combining different concepts into the same class.	Minor	13	This error occurs because all symptoms are under the same class: symptom.
2	P08, loss of annotations.	Minor	102	If ontologies such as SOSA and QUDT have annotations on their concepts, then the tool does not detect them. On the other hand, OntoCaimer does not present annotations because the concepts used as recommendations and symptoms are very explicit.
3	P11, missing domain or range in properties.	Important	5	Properties that do not have a domain or range belong to the SOSA and QUDT ontologies. Thus, they are not defined by their authors, and it is not necessary to create them.
4	P13, inverse relationships not explicitly declared.	Minor	4	The inverse relationships that are missing belong to the SOSA and QUDT ontologies. Therefore, they are not defined by their authors, and it is not necessary to create them.
5	P22, use different naming conventions in the ontology.	Minor	Ontology	When reusing two ontologies, different nomenclatures are introduced. For example, SOSA uses CamelCase, and OntoCaimer uses delimiters like ‘_’ to make the symptoms clearer to the reader.

As can be seen in Table 5, the errors presented by OntoCaimer are of a minor and important level, which will not affect any of its characteristics, including usability, conciseness, and adaptability. Thus, OntoCaimer can be used without problems. Continuing with the application of the second method proposed in [47], this suggests carrying out a manual evaluation where the errors are verified while taking into account the three factors mentioned and defined above (inconsistency, incompleteness, and redundancy). The results of this evaluation are presented in Table 6, where the criterion, the sub-criteria, and the results are shown. From the results obtained, it is possible to observe and conclude that OntoCaimer is a consistent, complete, and consolidated ontology.

Table 6. OntoCaimer’s ontological taxonomy evaluation. Source: the authors.

ID	Criterion	Subcriterion	Result
1	Inconsistency	Evaluates circulation, partitioning, and semantic errors.	To validate inconsistencies, each concept, relationship, subconcept, and instance was reviewed. It was found that there were no errors of any kind. In addition, the Hermit reasoner available in Protégé was used, which helped identify inconsistencies.
2	Incompleteness	Refers to leaving out of the ontology some existing concepts in the domain and the omission of disjoint knowledge.	Some classes that were reused from other ontologies did not define the range, domain, or inverse function; however, the concepts that were not reused met this criterion, and thus it can be concluded that OntoCaimer is complete.
3	Redundancy	Grammatical redundancy errors, where some classes or instances have identical definitions.	It was possible to verify that there were no redundancy or incompleteness errors in the different concepts proposed by OntoCaimer.

5.3. Application of Quality Metrics

The next step proposed in [9] is the application of quality metrics. For this, the five criteria proposed by Gómez et al. [48] were used: consistency, completeness, conciseness, extensibility, and sensitivity. The results of this evaluation are presented in Table 7, where the criterion to be evaluated, its description—taken from [48]—and the result obtained can be found. According to Table 7, the quality assessment of OntoCaimer indicates that the ontology satisfactorily meets the five criteria, suggesting that it is a well-designed, reliable, complete, and flexible tool for its purpose.

Table 7. OntoCaimer quality assessment. Source: the authors.

ID	Criterion	Subcriterion	Result
1	Consistency	This criterion relates to the conclusions that the ontology can provide; that is, the ontology does not generate contradictory conclusions based on valid definitions.	By examining and evaluating OntoCaimer using different methods, among which its application to automate recommendations stood out, it is possible to affirm that OntoCaimer provided truthful and expected conclusions for the proposed cases. In addition, the content of OntoCaimer was consistent with the domain it represented. Furthermore, the data sources used to build OntoCaimer, like the reused ontologies, are from reliable sources and verified by the scientific community.
2	Completeness	This criterion considers that definitions are complete and that the ontology contains the concepts it is supposed to contain.	OntoCaimer met this requirement because its concepts and relationships were complete.
3	Conciseness	The ontology should not contain unnecessary or useless definitions and should not contain explicit or inferred redundancies.	OntoCaimer was built to avoid duplication of information. For example, repeated recommendations were removed. Each of the concepts or relationships proposed in OntoCaimer is necessary, useful, and non-redundant.
4	Extensibility	This criterion relates to the ease with which knowledge can be added to the ontology without affecting its quality.	Because it has a modular design, OntoCaimer allows for seamless extension.
5	Sensitivity	This criterion refers to the potential damage to the ontology if small changes are made to a definition.	The information contained in OntoCaimer is simple and appropriate for its domain, due to the fact that it comes from verified sources. Furthermore, its design was modular, so it is not sensitive to damage caused by small changes.

5.4. Improving the Ontology

The final step proposed by McDaniel and Storey [9] is ontology improvement. The authors proposed two tasks to accomplish this. The first is to prune and modularize the ontology, followed by placing it in a library. The first task involves dividing the ontology into sections, each of which responds to a task or has a specific purpose relative to the area the ontology manages. This task is not necessary in OntoCaimer because it was designed modularly. As can be seen in Figure 1, OntoCaimer consists of five modules: (1) patient, (2) disease, (3) observations, taken from the SOSA ontology, (4) drive module, taken from the SOSA ontology, and (5) general SOSA concepts. For the second task, a repository was created on GitHub where OntoCaimer and the OntoCaimer version are located. Here, the concepts for the use cases required in the implementation were instantiated, a stage that is also part of the evaluation. This implementation is found in the next section. The intention of sharing the ontology on GitHub is to allow anyone to access it and be able to use it in future projects, and the link accessed on 1 September 2025 to it is as follows: https://github.com/ldlasso2/OntoCaimer.

5.5. Ontocaimer Application

This section presents the application of OntoCaimer concepts, the rules created in Protégé, and the inferences generated by the Pellet reasoner, available as a plugin in Protégé 5.5.0. This version can be downloaded through the following GitHub link accessed on 1 September 2025: https://github.com/ldlasso2/OntoCaimer/blob/master/Protege-5.5.0-win.zip. The application of OntoCaimer concepts was carried out with the objective of automating some of the recommendations for the symptoms presented by two hypothetical patients (protopersonas), created solely to better illustrate the use of OntoCaimer. In addition, the results obtained from the automation and the answers to competency-based questions are presented.

If the reader wishes to see all recommendations, they can do so by accessing the complete list of recommendations available in a repository on Zenodo at the following link: https://doi.org/10.5281/zenodo.16884234 (accessed on 1 September 2025). The concepts that will be used in the following examples are sensor, observation, action, and recommendation, among others, and their definitions can be found in Table 1. Furthermore, to facilitate understanding, the names of the instances will be placed in parentheses, while the entire logic of the automation of the recommendations is described.

5.5.1. Development of the First Use Case

The first case in this set of examples was a patient named ‘Joe’, instantiated in (P1). This patient suffered from the symptom of weight loss, and the associated recommendations for this symptom are as follows: (1) avoid eating outside of established eating hours, (2) ensure the relative’s dentures are properly positioned, (3) eat in a calm and quiet area, (4) serve meals at the same time, and (5) the patient’s weight should not decrease by more than 5 kg per month. For this example, recommendations (1), (3), and (5) were automated with two different approaches. For recommendations (1) and (5), sensors would measure the variables in the patient (P1), and for recommendation (3), sensors would measure variables in the dining room (Room1). For recommendation (1), a GPS sensor (GPS) was used with patient (P1) to determine their location (PatientPosition). The location of the patient was the characteristic of interest for automation, and thus it was associated with observation 1 (O1). In this sense, the following rule was created in Protégé. If the patient (P1) is in the kitchen outside of mealtimes (breakfast, lunch, and dinner), then an alert will be generated, which will be sent to the caregiver’s (C1) cell phone (CaregiverPhone). Figure 2 presents all the relationships and instances related to observation 1 (O1).

Figure 2. Instance and relationship diagram of observation 1 (O1). Source: the authors.

For recommendation (3), it was proposed to use a noise sensor (NoiseSensor) located in the dining room (Room1), which would be associated with observation 2 (O2), and an actuator (WindowOpenCloser) that opened and closeed the window in the dining room (Room1). For the actuator to work, sound limits were established that, depending on the result of the sensor (NoiseSensor), would determine the state of the dining room (Room1). Some of these limits were inspired by those suggested in [49,50]. Below 55 decibels, the room was calm, and from 56 to 66 decibels, the room was somewhat noisy. Above 66 decibels, the room was considered noisy. If the state of the dining room (Room1) was not calm, then the window would be closed to reduce the noise level. Figure 3 shows all the relationships and instances associated with observation 2 (O2).

Figure 3. Instance and relationship diagram of observation 2 (O2). Source: the authors.

Finally, for recommendation (5), related to the patient’s weight, a scale (WeighingMachine) was used as a sensor linked to observation 3 (O3). When the initial weight of the patient and the weight measured with the sensor had a difference greater than 5 kg, an alert (Alert) would be sent to the cell phone (CaregiverPhone) of the caregiver (C1). The relationships and instances related to observation 3 (O3) are presented in Figure 4. Rectangles with diamonds inside represent instances, those with a plus sign represent instances that can be displayed within them, this is a simplified way of showing the plugin representations, take this into account for Figure 2, Figure 3, Figure 4, Figure 5 and Figure 6.

Figure 4. Instance and relationship diagram of observation 3 (O3). Source: the authors.

Figure 5. Instance and relationship diagram of observation 4 (O4). Source: the authors.

Figure 6. Instance and relationship diagram of observation 5 (O5). Source: the authors.

5.5.2. Development of the Second Use Case

The second patient was named ‘Mary Bet’ and was instantiated as patient (P3) who suffered from the following symptoms: (1) ‘sundowning’ and (2) ‘delusions and paranoia’. The recommendations for these two symptoms are as follows. For sundowning, (a) encourage movement and exercise, (b) stay nearby while she is doing homework so one can calm her down, (c) encourage a nap after lunch if it does not interfere with sleep at night, (d) make ‘quiet time’ with soft music after lunch part of her routine, (e) have an early dinner or a late-afternoon snack, (f) good lighting can sometimes help reduce confusion, and reducing noise and overstimulation can also help reduce confusion and anxiety, (g) tell her the time, where she is, and what is happening, which can also help reduce confusion and anxiety, (h) redirect her attention with an activity, (i) close curtains or blinds at dusk to minimize shadows and the confusion they may cause, (j) provide comfort items, and (k) restrict sweets and avoid caffeine at night.

Regarding the relationship between the symptoms of delusions and paranoia, these are the recommendations. (a) Leave the patient alone, or approach the patient slowly to avoid frightening them. (b) Avoid arguing or trying to explain that what they are thinking, seeing, or hearing is not real. (c) Redirect their attention with an activity. (d) Cover or remove mirrors and patterned rugs or wallpaper that may confuse the person. (e) Check for noises the person might mistake for someone speaking. (f) Make sure the person has had recent hearing and vision tests. Any glasses or hearing aids should be in good condition and working properly. (g) Finally, if their hallucinations involve multiple senses, seek immediate medical attention.

Taking into account recommendations (d), (f) and (i) of the ’sundowning’ symptom and recommendation (e) of the ’delusions and paranoia’ symptom, it is possible to infer that it is necessary to maintain a quiet space without noise (e, f) which has good lighting (f) no shadows (i), and soft music (d) so that the patient is calm. The space designated for automation was the room (Room 2). On the other hand, continuing with the numbering of the observations in the first use case, observation 4 (O4) was instantiated, which has the property of observing the light (Light) that is in the room (Room 2). Depending on the results of observation 4 (O4) the light intensity (LightPotency) of the lamps would be modified using the dimmer (LightinghDimmerSwitch). The relationships and instances related to observation 4 (O4) are presented in Figure 5.

For this use case, time plays an important role. The clock (Clock) determines when the quiet time (QuietTime) begins, where the curtains (CurtainActuation) will be closed to maintain controlled lighting and prevent shadows (Shadows). Quiet music (Music) will also be activated in the room (Room2). Therefore, the clock (Clock) was used as a sensor to observe the shadows (Shadows) and the quiet time (QuietTime). Observation 5 (O5) is related to the clock (Clock), where the time to execute the aforementioned actions will be observed. The relationships and other instances related to observation 5 (O5) are presented in Figure 6.

This design consists of automating some of the recommendations based on the symptoms presented by the patients. It should be noted that this design is not the only way to automate recommendations. OntoCaimer provides the versatility to automate recommendations and processes according to user needs.

5.6. Results

In order to ensure that the ontology meets the development of tools that support the care of patients with Alzheimer’s and that the recommendations chosen in the previous section were also automated, sensor observations were instantiated, and it was verified that the state of the actuators would be modified based on the observation result. Figure 7 shows observation 1 (O1), which found in the patient’s position and the time at which they took this position. Since patient (P1) was not in the kitchen during mealtimes, no alert was generated. When it was detected that the patient (P1) was in the kitchen outside of mealtimes, an alert was be generated. This can be seen in Figure 8. Figure 7, Figure 8, Figure 9, Figure 10, Figure 11, Figure 12, Figure 13, Figure 14 and Figure 15 present the data properties associated with the different instantiations of OntoCaimer concepts, such as observations, actuations, sensors, etc. Their characteristics are shown within them, such as: Observations show their results and the sensor they are associated with. Finally, a red box shows the changes associated with the example, such as the results of observations, the activation of actuators, alerts, the status of a room, etc.

Figure 7. Observation 1 (O1) results without activation (Alert). Source: the authors.

Figure 8. Results of observation 1 (O1) with actuator (Alert). Source: the authors.

Figure 9. Observation 2 (O2) results without actuation (WindowActuation). Source: the authors.

Figure 10. Observation 2 (O2) results with actuation (WindowActuation). Source: the authors.

Figure 11. Results for observation 3 (O3) without activation (Alert). Source: the authors.

Figure 12. Results for observation 3 (O3) with activation (Alert). Source: the authors.

Figure 13. Results for observation 4 (O4) without actuation (LightPotency). Source: the authors.

Figure 14. Results for observation 4 (O4) with actuation (LightPotency). Source: the authors.

Figure 15. Observation 5 (O5) results without actuation (CurtainActuation, Music). Source: the authors.

Figure 9 presents the results of observation 2 (O2), which shows the level of noise in the dining room. The room was calm and quiet, and thus the actuator (WindowActuation) did not respond. Figure 10, on the other hand, shows the state of the room changing to ‘noisy’ and the actuator changing to ‘close’, indicating that the windows would be closed.

Figure 11 shows the weight of the patient (P1), which was normal, and there was no action, contrary to Figure 12, where the patient (P1) presented weight loss, which generated an alert message to the caregiver.

Figure 13 shows the results of observation 4 (O4). The sensor result was a high light level, and thus the drive (LightPotency) had no response, contrary to what is shown in Figure 14, where the light level was low and the drive (LightPotency) was placed in a high light state or ‘high light’, which would modify the environment.

Finally, for observation 5 (O5) and the associated recommendation, it was established as follows: at 5:00 p.m., the curtains would close, and music would be played. In Figure 15, it can be seen that at 12:00 p.m., there was no activation by (CurtainActuation) or (Music). However, in Figure 16, it is possible to see how the activations were generated.

Figure 16. Observation 5 (O5) results with actuation (CurtainActuation, Music). Source: the authors.

In these tests that emulated the real world, the results were satisfactory, since the expected results were obtained. When the sensor detected any change that did not comply with the proposed rules, an action was generated. For example, if the patient was in the kitchen outside of their mealtimes, an alert was generated to the caregiver so that they could check that the patient was not eating outside of their schedule. Each of the results presented previously shows how the action changed when the value measured by the sensor varied, proving that recommendations can be automated and thus help the caregiver with their daily tasks. The proposed ontology can be found at the following link accessed on 1 September 2025 https://github.com/ldlasso2/OntoCaimer. For these use cases, the Pellet Reasoner was used, which is available as a plugin in Protégé version 5.5.0. To obtain the results that were shown, it was necessary to activate the data property assertions option in the application. This option is located in Preferences. In the Reasoner tab, one must look for the Displayed inference tab and activate everything found in the section called Individual inferences, as shown in the red box of the in Figure 17.

Figure 17. Protégé settings. Source: the authors.

5.7. Application of the Competency Questions

This section lists a variety of questions that may arise in real-life situations involving patients and their caregivers, e.g., in a nursing home, a hospital, or a patient’s home. To answer the competency questions, the patients instantiated in the previous section (Section 5.5) were taken as a reference. From these recommendations, it was possible to identify a group of variables and related questions, such as the following: What are the mealtimes? Is the dining room noisy? Is the patient eating snacks? Is the patient at a healthy weight? What activities can I do with the patient based on their stage of Alzheimer’s? These questions were answered by the ontology (see Table 8). Furthermore, it is important to mention that all variables and questions were related to a symptom, and they should be monitored by the caregiver. Furthermore, variables, restrictions, and data properties, among other tools, can be automated based on what OntoCaimer suggests to support the caregiver and patient care.

Table 8 presents the competency questions defined to validate the scope and utility of OntoCaimer. For each question, a concise summary of the results obtained from the ontology is provided. The complete SPARQL queries used to retrieve these results are available in our supplementary materials in the Zenodo repository for full reproducibility: https://doi.org/10.5281/zenodo.17117349 (accessed on 1 September 2025). Readers who wish to run the queries presented in the Zenodo repository accessed on 1 September 2025 (https://doi.org/10.5281/zenodo.17117349) should note the prefixes presented in Table 9 and place them at the beginning of the query, as shown in Figure 18.

All queries were performed within the ontology containing patient instances, available for direct download from the GitHub repository (OntoCaimer/OntoCaimerV2-Joe-Mary.owl at master · ldlasso2/OntoCaimer · GitHub). The prefixes specified in Table 9 are designed for use within this ontology, where the prefix c: http://www.semanticweb.org/OntoCaimer/ denotes the local OntoCaimer domain (not an active web domain). Consequently, all queries should be executed within the downloaded ontology to ensure proper functionality and avoid execution errors.

Table 8. Competency questions and results from OntoCaimer. Source: the authors.

ID	Competency Question	Summary of the Obtained Result
1	What exercises can I do with patient Joe?	The ontology recommended activities for the severe stage, such as ‘balance in a standing position’ and ‘sit unsupported for a few minutes each day’.
2	What recommendations have examples?	The query identified 20 recommendations that include specific examples for caregivers, covering symptoms from all stages of the disease.
3	What activities does patient Joe have on his agenda?	Joe’s daily activities include dinner, lunch, and sleep.
4	What time should patient Joe have lunch?	Joe should have lunch at 12:00 p.m.
5	What is the activity starting at 9 p.m. for patient Joe?	The activity scheduled for Joe at 9:00 p.m. is ‘sleep’.
6	What is patient Mary Bet’s most recent symptom?	Her most recent symptom is ‘delusion and paranoia’.
7	What are patient Joe’s symptoms?	The main symptom registered for Joe is ‘weight loss’.
8	What are patient Joe’s recommendations?	Recommendations include ‘ensure patient’s dentures are properly fitted’ and ‘the eating area should be quiet and calm’.
9	What are the seizure recommendations?	For seizures, it is recommended to ‘keep the patient safe and comfortable’, ‘place something soft under their head’, and ‘call for emergency services if it lasts more than two minutes’.
10	Who takes care of patient Joe?	Joe’s caregiver is ‘Antony’.
11	Is patient Joe’s weight appropriate?	No (false). The system detected that his weight is below the healthy threshold defined in the recommendations.
12	What is the condition of the dining room?	The current state of the dining room is ‘calm and silent’.
13	What are the symptoms of the severe stage?	Symptoms include ‘inability to communicate’, ‘difficulty swallowing’, ‘seizure’, and ‘weight loss’.
14	What sensors does the dining room have?	The dining room is equipped with a NoiseSensor.
15	How much noise is there in the dining room?	The numerical value of the noise level in the dining room is 34 decibels.
16	What is the noise level in the dining room?	The inferred state from the noise level is ‘calm and silent’.
17	What activities can I do with patient Mary?	Activities such as ‘reading books or newspapers’, ‘looking at old photographs’, ‘listening to favorite music’, and ‘flower arranging’ are recommended.

Table 8. Competency questions and results from OntoCaimer. Source: the authors.

ID	Competency Question	Summary of the Obtained Result
1	What exercises can I do with patient Joe?	The ontology recommended activities for the severe stage, such as ‘balance in a standing position’ and ‘sit unsupported for a few minutes each day’.
2	What recommendations have examples?	The query identified 20 recommendations that include specific examples for caregivers, covering symptoms from all stages of the disease.
3	What activities does patient Joe have on his agenda?	Joe’s daily activities include dinner, lunch, and sleep.
4	What time should patient Joe have lunch?	Joe should have lunch at 12:00 p.m.
5	What is the activity starting at 9 p.m. for patient Joe?	The activity scheduled for Joe at 9:00 p.m. is ‘sleep’.
6	What is patient Mary Bet’s most recent symptom?	Her most recent symptom is ‘delusion and paranoia’.
7	What are patient Joe’s symptoms?	The main symptom registered for Joe is ‘weight loss’.
8	What are patient Joe’s recommendations?	Recommendations include ‘ensure patient’s dentures are properly fitted’ and ‘the eating area should be quiet and calm’.
9	What are the seizure recommendations?	For seizures, it is recommended to ‘keep the patient safe and comfortable’, ‘place something soft under their head’, and ‘call for emergency services if it lasts more than two minutes’.
10	Who takes care of patient Joe?	Joe’s caregiver is ‘Antony’.
11	Is patient Joe’s weight appropriate?	No (false). The system detected that his weight is below the healthy threshold defined in the recommendations.
12	What is the condition of the dining room?	The current state of the dining room is ‘calm and silent’.
13	What are the symptoms of the severe stage?	Symptoms include ‘inability to communicate’, ‘difficulty swallowing’, ‘seizure’, and ‘weight loss’.
14	What sensors does the dining room have?	The dining room is equipped with a NoiseSensor.
15	How much noise is there in the dining room?	The numerical value of the noise level in the dining room is 34 decibels.
16	What is the noise level in the dining room?	The inferred state from the noise level is ‘calm and silent’.
17	What activities can I do with patient Mary?	Activities such as ‘reading books or newspapers’, ‘looking at old photographs’, ‘listening to favorite music’, and ‘flower arranging’ are recommended.

Table 9. Prefixes for SPARQL queries accessed on 1 September 2025. Source: the authors.

ID	Prefix
1	PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
2	PREFIX owl: <http://www.w3.org/2002/07/owl#>
3	PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
4	PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
5	PREFIX c: <http://www.semanticweb.org/OntoCaimer/>
6	PREFIX sosa:<http://www.w3.org/ns/sosa/>
7	PREFIX ssn:<http://www.w3.org/ns/ssn/>
8	PREFIX qudt:<http://qudt.org/schema/qudt/>
9	PREFIX bif: <http://www.openlinksw.com/schemas/bif#>

Table 9. Prefixes for SPARQL queries accessed on 1 September 2025. Source: the authors.

ID	Prefix
1	PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
2	PREFIX owl: <http://www.w3.org/2002/07/owl#>
3	PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
4	PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
5	PREFIX c: <http://www.semanticweb.org/OntoCaimer/>
6	PREFIX sosa:<http://www.w3.org/ns/sosa/>
7	PREFIX ssn:<http://www.w3.org/ns/ssn/>
8	PREFIX qudt:<http://qudt.org/schema/qudt/>
9	PREFIX bif: <http://www.openlinksw.com/schemas/bif#>

Figure 18. Example of SPARQL query execution with prefixes. Source: the authors.

6. Discussion

This study focused on the creation of OntoCaimer, a domain ontology designed for the care of patients with Alzheimer’s disease. Unlike other existing models that lack explicit integration between the physical and computational worlds, our ontology addresses this limitation by linking disease knowledge with cyber-physical system (CPS) concepts such as sensors and actuators. This approach not only enables information management but also enables the automation of actions in the patient’s environment.

Our findings demonstrate that OntoCaimer is a high-quality ontology, since the evaluation, conducted using the FOCA methodology, yielded a score of $\hat{\mu }=0.99$. This result, calculated using the beta regression model, validates the robustness of the ontology design in five knowledge representation roles: surrogate, ontological commitments, intelligent reasoning, efficient computation, and human expression. The rigorous validation process, which included reviews of consistency, completeness, and conciseness, confirmed that OntoCaimer is a reliable and well-designed tool.

Case studies illustrated OntoCaimer’s functionality by automating recommendations for symptoms such as weight loss and sundowning. The results showed that, based on sensor data, the ontology could generate alerts to caregivers or trigger actuators to modify the environment, such as closing curtains or adjusting the lighting. This validates the hypothesis that it is possible to develop systems that not only alert but also intervene directly to provide proactive support to patients and reduce caregiver workload. The implementation of OntoCaimer using Protégé and the Pellet Reasoner proved effective in generating logical inferences for these automations.

One of the main limitations of existing ontology models is their lack of public availability. To mitigate this, OntoCaimer has been made available at a GitHub repository accessed on 1 September 2025 (https://github.com/ldlasso2/OntoCaimer), thus encouraging the reuse of knowledge by the scientific community. However, evaluation using the OOPS! tool identified minor and major errors, such as the combination of concepts in the same class and the lack of explicit declaration of inverse relationships in reused ontologies. Although these errors were determined not to compromise OntoCaimer’s core functionalities, correcting them would improve its attractiveness and usability.

7. Conclusions

This study introduced OntoCaimer, a modular ontology whose primary scientific contribution is the formal integration of knowledge about Alzheimer’s disease with the physical world of sensors and actuators. This novel approach addresses a critical gap in existing patient care systems, which have historically been limited to virtual alerts or fragmented information. By providing a validated knowledge base that semantically links symptoms to potential automated environmental actions, our work establishes a robust foundation for the next generation of cyber-physical support systems aimed at improving patients’ quality of life and reducing the immense burden on caregivers. The developed ontology allows for the synthesis of preventive actions and recommendations for most of the symptoms presented by Alzheimer’s patients at each stage. This represents a reduction in the workload for the caregiver. Furthermore, the ontology allows for the abstraction of important variables such as the patient’s monthly weight, the state of the environment in a room, and the location of the patient. The ontology can be used to automate some of these recommendations, providing support for patient care. This ontology will support the development of patient care support systems, regardless of the sensors or methodologies used. Furthermore, OntoCaimer is based on knowledge of Alzheimer’s disease and knowledge of sensors, observations, and actuators, making it an ideal bridge between these two areas of knowledge. Validation using the FOCA method and the presented use cases confirmed that OntoCaimer can serve as a solid knowledge base for the development of cyber-physical systems that support caregivers and improve patients’ quality of life.

The authors acknowledge several limitations in this study. The primary limitation, as highlighted by the validation process, is that while the FOCA method confirmed the ontology’s formal and structural quality, its real-world effectiveness has not yet been empirically evaluated. The case studies presented serve as a proof-of-concept for the ontology’s functionality but do not provide a generalized assessment of its practical impact.

Consequently, the most critical line for future work is to move beyond formal validation and conduct a pilot study involving real patient groups and their caregivers. Such a study would be designed to collect empirical data and allow for generalized statistical assessments of key outcomes. For instance, we could measure the impact on caregiver-reported stress levels, the frequency of adverse events (e.g., wandering episodes), or improvements in patient comfort indicators. This empirical validation is an essential next step to translate the formal correctness of OntoCaimer into proven clinical utility, which would allow measuring its tangible impact and obtaining direct feedback.

In addition, the integration of artificial intelligence algorithms, such as machine learning, could be explored to predict the onset of symptoms and automate recommendations in a predictive rather than reactive manner.

Finally, the expansion of the ontology to include information on other forms of dementia or neurodegenerative diseases is suggested, which would increase its applicability and value in the health field.