## 3 Data Integrity Ontology in SPuMoNI
### DIOnt Brief Description  
Data integrity ontology (DIOnt) was selected for the semantic representation of all involved data and relevant process development, and the modeling of the regulatory requirements, targeting ALCOA data integrity rule compliance, aligned with RegTech system architecture. DIOnt ontology will be described in brief in this subsection, as it has been extensively presented in our previous research work [34]. The hierarchical structure of DIOnt, which, to a certain extent, has been motivated by the OntoReg ontology [5], is shown in Figure 2a-d. The higher level of DIOnt consists of two generic classes, AbstractConcepts (Figure 2a) and PhysicalConcepts, respectively. The class PhysicalConcepts is then specialized into its subclasses, namely ProcessDomain, RegulatoryDomain, and ProductDomain (Figure 2b-d), which in turn, are further specialized into various subclasses, thus forming the three basic levels of the DIOnt ontology. Figure 2: _Cont_. Below that level, there are four hybrid classes, namely Position, Substance, Operation and EquipmentModule, which belong to both Process and Regulatory domains. A pharmaceutical Process consists of UnitProcedures, while every Unit Procedure consists of one or more Operations which are executed by the same Equipment. The RegulatoryDomain contains all regulatory requirements, derived by the ALCOA principles, and these are represented as relations between class individuals, which are then translated into a set of tasks, executed in a given sequence, via the use of data and object properties (Figure 3). This is achieved via the ValidationTask, ValidationPlan, ValidationTest, and Action classes as well as the Regulation and Position classes. Moreover, the classes Document and TaskReport are responsible for the relevant procedure report documentation. Last, the class ProductDomain, is responsible for accurately describing the manufactured product across the whole pharmaceutical manufacturing line, from its original ingredients to the final batch composition, and its order. This is achieved via Product, Order, Lot, and BatchNumber, class individuals. Figure 3 shows the inter-domain relationships between the DIOnt entities, represented by object properties (as corresponding numbered arrows), which are presented in Table 1. Due to the fact that the overall DIOnt hierarchical structure consists of a great number of classes (95), as seen in Figure 2a-d, the number of relevant object and data properties required for their accurate relation description is quite high (99 and 52, respectively). Therefore, Figure 3 displays only the Process domain originated entity relationships, which constitute a part of the overall properties required; therefore, many of these relationships have been omitted to simplify the presentation. In this way, the DIOnt restrictions and constraints can be defined and tailored specifically for corresponding ALCOA principles, and they are specified by respective SWRL rules. These rules enhance the OWL semantics of the DIOnt ontology classes and represent the functionalities required in order to perform the evaluation compliance of the ALCOA principles. Specifically, the SWRL rules enable rule-based reasoning, as they are loaded into the rule engine of the ALCOA assessment module, via the support of a Reasoner mechanism that is capable of inferring logical consequences from existing rules, and thus of enriching the DIOnt ontology with new inferred knowledge. Additionally, an SWRL-based query language (SQWRL) is used for extracting information from the inferred ontology, and its renewed knowledge base, performing ALCOA inconsistency evaluation. Hence, the DIOnt ontology forms the basis for the development of an appropriate regulatory compliance model, on top of the SPuMoNI's RegTech architecture which, as a proof-of-concept prototype, combines generic SWRL rules and SQWRL queries in order to perform ALCOA assessment, with the overall aim to enhance the process data integrity. Figure 2: (a) Class AbstractConcepts and its subclasses.