Figure 7-1 shows a representation of the formalised multi-level ontology: The core and Level 1 ontology logic was built upon the declared core and Level 1 terms and relationships. This logic was described as ‘structural’ as it was explicitly coded through constraining logic or integrity constraints and inference rules which allow the inference of new relationships based on predefined logic. This structural logic in the Core and Level 1 ontologies forms the meta knowledge that as described in the unified approach to interoperability (Usman 2012). This logic can span both the core and Level 1 ontology levels, requiring the Core and Level 1 semantics to be declared prior to logic declaration; hence the logic is shown as being built on the semantic levels. The Level 2 ontology is declared using the full set of Core and Level 1 semantics and logic hence is shown at the top of the ontology structure. The detailed development and testing of the solution is shown in Section 7.4.
Figure 7-1 - The formalised solution ontology
Figure 7-1 shows how the solution functions:
A new system is declared into the knowledge base (Level 2 ontology).
If the new system is rejected by any of the structural logic i.e. it does not meet the requirements for interoperability as defined within the ontology solution logic, the declaration is rolled back and the system is rejected from the knowledge base with corresponding error message feedback.
If the new system meets the requirements for interoperability it is incorporated into the knowledge base and becomes available for queries; the formalised ontology in itself is only a part of the solution as it only answers some of the ontology
competency questions set out in Section 4.2.1. Formalised queries were required to fully answer the competency questions not answered by the function of the structural logic.
Section 7.4.6 lists the ontology competency questions, how the solution answers them, and the code for any queries.
7.3 Formalising the logical rules
The rules defined in Chapter 6 were rewritten using a more rigorous common logic format.
Where possible the statements were written in the ‘if’, ‘then’ format to aid the process of coding them in the Knowledge Framework Language (KFL). It was found that logic
statements not written in this format often required several logical statements to codify them, whereas those defined using this format were usually defined in a single code statement.
This proved important at the testing stage, as it was difficult to keep track of which code statements affected which logical rules where there was not a one to one correlation. It was also found that the rules written in this format were easier to codify as it clearly structures the object and conditional statements in a manner suitable for coding.
At this early stage it was apparent that the syntactic, semantic and logical rigor that was required when coding the heavyweight ontology, while significantly increasing the
complexity, would enable the solution to discern acceptable and non acceptable conditions in the knowledge base if the correct rules were formalised within it such as the example given in Section 7.4.1. Without this complexity, the solution could not resolve the issue of potential ontological ambiguity.
7.3.1 Integrity constraint and inference rule evolution
A list of the Inference Rule (IR) and Integrity Constraint (IC) logic for the 3 levels of the ontology was developed with examples being:
If a system input is not approved the system output is not approved (IR)
A system type must have some form of inputs, outputs, resource and constraints defined (IC)
A full list of the logic statements is available in Appendix B.
It can be seen that there are relatively few rules at the Core level, which is due to the limited number of terms available. There are also few rules for the Level 2 ontology as this level is more about providing the specialised terms for the MI domain and instances. The majority of the logic is created in the Level 1 ontology due to it having both the Level 1 and Core
ontology terms and relationships to consider, and is not the instance level ontology (unlike Level 2). The different level of logic required at the ontology levels was consistent with the solution concept:
A core concept ontology should have relatively low numbers of foundational concepts or terms, meaning the opportunity for logical rule is limited as this could result in the
ontology becoming overly specific or over-constrained and so limiting its applicability.
This would be a key failing for a ‘core’ or foundational ontology.
Domain ontologies, as shown in Figure 4-8, would be expected to contain a large number of domain specific concepts and terms, meaning the opportunity and requirement for constraining logic are much greater.
The ‘Level 2’ ontology defined in this research, which is effectively the knowledge base, would be expected to contain a large and potentially rapidly growing number of terms, but these would be ‘instances’ of the terms defined in the higher level
ontologies. As such they would be constrained by the structural logic of the
ontologies on which is it built (i.e. IR, ICs and relationships) but would generally be at an inappropriately high level of specificity to define broadly applicable constraining logic hence little of no structural logic would be expected.
The logic statement numbers that are missing in Appendix B are those which were proposed but discounted prior to coding. The logic statements that are numbered with letter suffixes are those that have been broken down into a number of simple statements: this was due to the need to declare the statement at the right ontological level i.e. the right level of
specificity, requiring logic to be declared explicitly at core concept (core ontology), Domain concept (domain ontology) or instance (knowledge base) level or at multiple levels. The statements that have been struck through with a statement in red have been removed or discounted through the ontology development process for the reason stated. The listing does not show that many of the statements that were initially written at one level were moved to another depending on the developing view of the level of generalisation of the logic . There were a large number of changes made to the logic statements during the ontology development, excluding syntax errors and corrections. The key reasons for modifications can be summarised as:
Logic removed/ modified as it was incorrectly stated at either the type or instance level (i.e. the wrong ontology level/ level of generalisation). This was the most common issue.
Logic removed completely as it is not relevant to the core purpose of the solution i.e.
is not related to system interoperability.
Logic removed completely as the statement was disproved through the testing stage.
Logic removed completely as it duplicates another statement.
IC removed as the application of the rule has been automated through the use of an inference rule (IR).
Further issues were identified during the testing stages however, these are discussed throughout Chapter 8.