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.

One thing to note is that passive voice syntax is supported from the Fluent Editor 2014.
For example, the two sentences below are equivalent.

Server-1 hosts Application-1.
Application-1 is hosted by Server-1.

By using this functionality, user can avoid defining additional relations for passive expressions such as writing this line.
Application-1 is-hosted-by Server-1.

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.

Additional Conditions
*. 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 a cluster.
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.

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.     

If a thing (1) hosts a thing (2) and the thing (2) hosts an application then the thing (1) hosts the application.

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,       

If an incident affects the thing and the incident has-status Open then the thing has-status Inoperable.

this can be written in SWRL statement as this. These two sentences are semantically equivalent.

Every-single-thing that is affected by an incident that that has-status Open has-status Inoperable.


3. Final Result

The whole structure of this ontology is decribed as in the following diagram.