IT Infrastructure Sample

Purpose of Use
This project shows how to write ontology to create an IT infrastructure, both a simple one and even a complex one.
While creating it, it involves several interesting features.
First, the simple example demonstrates using modal expressions.
Then, in the advanced example, it includes using references, semantic rules including SWRL to write complex statements.
Click here to create a simple version
Click here to create an advanced version
Simple Version
The first project shows a simple ontology structure using basic grammar and some modal expressions. You can play with this project.
The diagram of the project is as follows.
For example, the two sentences below are equivalent.
By using this functionality, user can avoid defining additional relations for passive expressions such as writing this line.
While writing additional sentences creates a redundant relation "is-hosted-by" on Taxonomy tree, using passive expressions will keep the tree structure simpler by displaying the single-verb relations.


Fig1. Taxonomy Tree After Using Passive Expressions Fig2. Taxonomy Tree After Defining Other Relation
* Warning
: In order to write passive expressions,
1) the verb must be in a single verb form. Combined verbs connected with dash(-) can NOT be applied.
E.g. has, have, loves, love (O)
has-son, is-loving (X)
2) the verb must be followed by the keyword "by", in order to set the inverse role. If you don't, there is no way to distinguish if it is about a concept or a relation.
E.g. Every machine is fixed by. (O) -> "fixed" will be treated as a relation.
Every machine is fixed. (X) -> "fixed" will be treated as a concept!
Advanced Version
The second project shows more advanced version. In this tutorial, you will be introduced with using some of advanced features including references and SWRL rules.
The structure of this project is developed based on the previous example as in the diagram below, with the new components marked in orange - customer, incident, operator. Moreover, new conditions are added as below.
*. If something is affected by an incident that has status ‘Open’, the thing is inoperable.
*. If something is affected by an incident that has status ‘Fixed’, the thing is operable.
*. If something is not affected by an incident, the thing is operable.
*. If something is served (or hosted or connected) by something inoperable, then the thing is also inoperable.
But, if server is connected by multiple power nodes, server is operable if it has at least one operable power-node.
1. Using Reference
Referencing other ontologies is useful when you want to reference big files into your ontology as shown in the Italian Dinner Sample.
Another useful case of referencing is when a single file gets bigger that you need to split it into several files. Referencing those files can provide you the same effect as if using one file before you split it. For example, after you download this project you can see it consists of multiple files of each component (from 1_Server.encnl to 7_Incidents.encnl) and they are all referenced in IT Infrastructure_Advanced.encnl by using empty prefixes as below.
[] ('./1_Server.encnl')
[] ('./2_Application.encnl')
[] ('./3_Customer.encnl')
[] ('./4_Cluster.encnl')
[] ('./5_PowerNode.encnl')
[] ('./6_Operator.encnl')
[] ('./7_Incidents.encnl').
Reasoning in this IT Infrastructure_Advanced.encnl file would work the same way as before it was divided into different pieces. Especially, using empty prefixes lets you not need to specify prefixes in every referred elements which is both convenient and safe from user's mistake assigning wrong reference prefix. However, note that this empty prefix works only for CNL files.
To see the contents of the reference, click the small button on the right side of the reference name and select 'Open In New Window'.
2. Using Semantic Web Rule Language(SWRL) Rules
Using SWRL rules extends the expressivity of OWL 2 language. Here are a few examples of using SWRL expression in different files.
(1) 4_Cluster.encnl
Cluster-1 is hosted by Server-3.
Cluster-1 hosts Application-4.
Application-4 is an application.
The given four
statements above create a concept 'cluster' and an instance 'Cluster-1' which is hosted by 'Server-3' and hosts 'Application-4'.
Here is the diagram together with other ontolgy files (from 1_Server.encnl to 4_Cluster.encnl) .
According to this ontology, a reasoner will acknowledge two relations.
-
Server-1 hosts Cluster-1.
-
Cluster-1 hosts Application-4.
However, it will not infer a relation - "Server-1 hosts Application-4". In the open-world assumption one does not imply other relation unless you explicitly state the rules about it. For this you can add SWRL rule, which enables you to express the relation between individuals with which an individual has relations.
When writing the word thing to represent more than one object, you can differenciate them by adding a tag with a different number in between brackets, such as thing (1) and thing (2). This rule is saying that if a thing(1) hosts another thing(2) which hosts an application, then it also means that this thing(1) also hosts the application.
After adding this statment, you can retrieve inferred knowledge through reasoning as below.
(2) 7_Incidents.encnl
SWRL syntax extends the OWL syntax, which means you can use SWRL rules which can be also equivalently written in OWL.
For example, if there is a OWL statement as below,
this can be written in SWRL statement as this. These two sentences are semantically equivalent.
3. Final Result
The whole structure of this ontology is decribed as in the following diagram.