The first task was to identify the key concepts and relationships in the domain of interest. To this end, we analysed the documents (PRD and HR) for real world objects (e.g. a project manager) and for information pieces which should be grouped together (e.g. all facts related to costs are grouped under the concept
Then a hierarchy between the concepts was established (e.g. PEOPLE has the subconcepts PROJECT MANAGER and PROGRAMME MANAGER). The attributes of those concepts are defined (e.g. the concept PEOPLE has the attributes FORENAME and SURNAME). The subconcepts inherit the attributes from their superconcept. In addition, subconcepts have additional attributes (e.g. a PROJECT MANAGER has the attribute MANAGES_PROJECT which specifies a relation to the concept PROJECT). In a next step, all these relations were specified and corresponding attributes were added to the concepts.
Secondly, the rules and constraints were developed. The aim was not to develop an expert system but to insert some useful knowledge rules of an expert of the domain to allow the system to create new knowledge. For the case study, this means that we had to think about how a programme manager makes his decisions. For example, if he wants to know whether a project is critical or not, he looks at certain parts of PRD and HR documents. He first looks for the colour of the RAG rating (HR), which in general identifies if a project is critical or not. As a next step, he compares the expected costs (budget) with the real costs. We combine these two information to a rule that specifies that a project is critical when the RAG rating is amber and the real costs are greater than the budget.
The definition of rules may lead to a major redefinition of concepts, their attributes and relations. For example, in the case study, the RAG rating was first only an attribute of the concept PROJECT. But as the RAG rating comes from highlight reports which are written quarterly, it was necessary to store the date along with the corresponding rating. So we developed a new concept RAG_RATING which has the attributes RATING (which specifies the colour), DATE and OF_PROJECT. Now it is possible to define rules for the concept PROJECT which are based on the RAG rating from different quarters. Before, this was only possible via the detour of the concept HIGHLIGHT_REPORT. In this capturing phase the elements of the ontology and their relations are described in plain text or visualised in rough sketches.
In the coding stage, the ontology is explicitly represented in a formal language. In the case of Ontobroker, this is F-Logic (see 4.3.2).
In some cases, the capturing and coding step can be merged into one single step depending on the F-Logic knowledge of the members of the capturing group (if there are domain experts who have a sound knowledge of the domain specific terms and relations but no understanding of F-Logic, it might be necessary to keep those steps separated).
In the BT case, this meant that the concepts and attributes were directly coded in F-Logic whereas the rules were first captured in plain text and later coded in F-Logic.
Was this article helpful?
What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.