## 3 Data Integrity Ontology in SPuMoNI
### DIOnt Software Methodology Architecture and Prototype Implementation  
DIOnt software methodology consists of three major steps and its architecture layout can be seen in Figure 4. A proof-of-concept prototype has been implemented based on that architecture, by adopting various software modules such as the Protege ontology editor, a rule engine, along with a reasoner and proper APIs, and finally the SQWRL queries. The DIOnt development first step, begins with the definition and description of ontology entities (classes, sub-classes, domains), as well as the relationships between class individuals, including definitions of the appropriate object and data properties, within Protege environment, as described in a previous section. A graph database (GDB) of Neo4j NoSQL type, has been utilized for storage purposes. The main reason behind the decision to utilize a graph database instead of a relational one is the native support that the former provides for the storage of relations between \begin{table}
\begin{tabular}{c c c c} \hline \hline
**No** & **Object Property** & **No** & **Object Property** \\ \hline
1 & isOrderOf & 15 & hasParameter \\
2 & underRecipe & 16 & hasActualData \\
3 & hasStart/hasEnd & 17 & hasTheoreticalData \\
4 & hasState & 18 & hasBOM \\
5 & hasProcessingPhase & 19 & hasMaterial \\
6 & hasALCOA & 20 & hasEffectivityDate/hasExpirationDate \\
7 & hasLog & 21 & hasMinQty/hasStdQty/hasMaxQty \\
8 & hasProduct & 22 & underSubrecipe \\
9 & hasQuantity & 23 & hasStartAction/hasEndAction \\
10 & hasSubrecipe & 24 & hasTracking \\
11 & hasInstruction & 25 & hasSignatureTime \\
12 & hasUnitProcedure & 26 & isPerformedBy \\
13 & hasEquipment & 27 & hasVerifier \\
14 & hasFunction & & \\ \hline \hline \end{tabular}
\end{table} 
Table 1: DIOnt object properties. Figure 3: DIOnt inter-domain entity relationships. nodes (i.e., in the case of an ontology, between classes). More specifically, a GDB treats relations between data as first-class objects and stores them directly, thus making them equally as important as the data itself. This allows data in the store to be linked together directly and, in many cases, retrieved with one operation. This is in contrast to the indirect representation and storage of relationships in a relational database, where relationships are usually reconstructed at the query execution time. Thus, the choice of a GDB for storing an ontology with many highly interlinked classes provides a natural and efficient solution. As a next step, the SWRL rules should be defined in such a way that they are aligned with ALCOA regulations. These rules should be described as OWL concepts (classes, properties, individuals), and be written to a database (RuleBase). As can be seen in Figure 4, all data inputs and SWRL rules are loaded into the rule engine via OWLAPI and SWRLAPI respectively. The rule engine, via the assistance of reasoner, runs and writes any inferred axioms back to the OWL ontology, enriching it with a new inferred knowledge base. These rules are generic in the sense that they are not targeted for the definition of a specific ALCOA principle constraint, but each one could be referred to more than one principle instead. For example, a generic SWRL rule would provide timestamps and, therefore, a time relationship between all entities of DIOnt ontology, via proper object properties. Now all original knowledge has been preprocessed, in terms of time sorting, in which the SQWRL queries will take advantage of that updated inferred knowledge and assist ALCOA module for the final decision regarding ALCOA principles that require time comparison (e.g., Available and Consistent). Hence, the final step involves the SQWRL (SWRL based query language) queries definitions, that have been particularly designed for the extraction of proper information inferred by the rules, knowledge base regarding ALCOA inconsistency evaluation and data assessment (Figure 4).