## 3 Methodology
### Ontology-Integrated Federated Unlearning (OFU-Ontology) Algorithm
#### 3.2.1 System Architecture  
The overall architecture of the proposed federated unlearning system integrates an ontology module alongside traditional federated nodes and a central coordinating server. Each client locally holds a subset of data and participates in collaborative training. During the unlearning phase, clients may request the removal of specific data or features, and the central server orchestrates this removal using relevance information extracted from an ontology. Unifying data semantics in the UDL module requires establishing an ontology to formally define the concepts, relationships, and class hierarchies of the domain (e.g., similarities between digits via their shapes in MNIST, or topic relationships among Reddit comments). Being offline, an expert can periodically update the ontology with annotations, while online integration allows for learning via client feedback logs. Hence, the model can evolve its definition of relevance with time. With such a mechanism developed, unlearning may remain consistent with current data semantics or regulatory interpretations. The system architecture of OFU-Ontology, as shown in Figure 6, consists of three major components: federated nodes, central coordinating server, and the ontology module. 1. Federated nodes: Each federated node locally stores its dataset and maintains a copy of the model. Federated nodes train the model locally on data unique to them and communicate updates of their models to the central server. At each node, there is also storage of gradient information for each data point during training, later to be used for unlearning. 2. Ontology module: The ontology module describes inter-entity relationships and relevance hierarchies among different types of data entities. This module assigns relevance scores to data points on the basis of domain knowledge, with higher scoresimplying higher importance and lower scores suggesting that a data point can be prioritized for unlearning with the least possible effect on the model quality. The ontology module can either be embedded locally at each node, or it can be housed centrally and accessed on unlearning requests. The ontology model is used for representing relationships and hierarchies within the data and hence forms a basis for assigning relevance scores to data points. The ontology is built using the following:  
* Entities represent key features or data elements in the domain. For instance, in healthcare, entities might include \"symptom\", \"diagnosis\", \"treatment\", etc. * Attributes are properties of entities that provide additional detail. For example, the \"symptom\" entity may have attributes such as severity, duration, and frequency. * Relationships define the connections between entities. For instance, \"symptom\" might be related to \"diagnosis\" through a \"leads to\" relationship. * Importance hierarchy indicates that the ontology includes a hierarchical structure that defines the importance of different entities and relationships. The ontology is used to calculate a relevance score \(R(d_{i})\) for each data point \(d_{i}\). This score helps determine which data points have a higher impact on model quality and should therefore be prioritized for retention or unlearning. 3. Central coordinating server: The central coordinating server aggregates the updates received from the nodes and synchronizes with the global model. It also facilitates the federated unlearning by managing relevance-weighted updates and calibration training to minimize knowledge permeation from unlearned data. Figure 6 shows the ontology visualizations designed for each evaluation dataset to illustrate how domain knowledge is structured to facilitate relevance-based unlearning. Figure 6a shows the MIMIC-III dataset ontology with medical entities such as diagnoses,  
Figure 6: Ontology visualizations for evaluation datasets.