This item was submitted to Loughborough’s Institutional Repository
(https://dspace.lboro.ac.uk/) by the author and is made available under the
following Creative Commons Licence conditions.
For the full text of this licence, please go to:
http://creativecommons.org/licenses/by-nc-nd/2.5/
An incremental hybridisation of heterogeneous case
studies to develop an ontology for capability
engineering
Huseyin Dogan
Engineering Systems of Systems
Group
Loughborough University, UK
Michael J de C. Henshaw
Engineering Systems of Systems
Group
Loughborough University, UK
Julian Johnson
BAE Systems, UK
Copyright © 2012 by Huseyin Dogan, Michael J de C. Henshaw and Julian Johnson.
Permission granted to INCOSE to publish and use.
Abstract. An analysis of perspectives for “capability engineering” has been conducted by the
INCOSE UK Capability Working Group (CWG). This paper is a continuation of this study
led by the CWG ontology work stream that aims to develop a single shared ontology for the
concept of capability engineering to enable semantic interoperability and to support a formal
and explicit specification of a shared conceptualisation. Case study material from the
different domains of rail, defence and information services was used. The ontology
development was executed in three phases; (1) pre-analysis, (2) ontology modelling and (3)
post-analysis. The pre-analysis involved literature reviews, requirements specification,
systems engineering process utilisation; and resource identification i.e. examination of the
case study material. The ontology modelling phase comprised information extraction and
classification in addition to modelling and code representation using a mark-up tool, MS
Excel and Protégé. The post-analysis involved validation workshops through using expert
focus groups.
Introduction
This paper is primarily based on the research conducted by the INCOSE UK Capability
Working Group (CWG) which identified eight perspectives of capability and developed an
entity relationship diagram for the concept of capability engineering (Henshaw et al. 2010).
The CWG perspectives analysis sub-group view ‘capability’ as the ability to do something
which has an overarching approach that links value, purpose, and solution of a systems
problem. The holistic thinking mindset, socio-technical nature and similarity in scope to
views of systems engineering are emphasised to elaborate the significant difference from
product systems engineering and broader characteristics to process perspective of systems
engineering.
This paper introduces rigour, richness and detail to the concept of capability engineering
thorough development of a user-centred, systematic and case study based ontology. Noy and
McGuiness (2000) describe the rationale behind developing an ontology as; to share common
understanding of the structure of information to enable semantic interoperability; to enable
the reuse of domain knowledge through a data structure and conceptual schema; to make
domain assumptions explicit; and to analyse domain knowledge. Semantic interoperability is
the ability to exchange data in order to improve interoperability between systems. The scope
of capability engineering is large and there are challenges in producing an all-embracing
model with a vocabulary agreed by all parties. Modelling the whole space in one set of a
language can be difficult. A case study based information extraction approach that looked at
the problem space in chunks (domains) is described within this paper. The progressive
updating of the ontology due to evolving nature of the problem space is discussed by using
the initial validation results from the focus groups.
Objectives
A set of high level objectives are derived through analysis of the CWG workshop discussions
and prior meetings with the CWG ontology work stream members:
• Objective 1: to develop a sector-independent ontology by extracting and classifying
information from case studies across heterogeneous domains to explicitly specify the
concept of capability engineering.
• Objective 2: to develop an information model from the ontology that is to be informed
by the capability engineering activity model to support the ‘management of
knowledge’ within the context of capability engineering.
• Objective 3: to evaluate (verify and validate) the ontology through expert reviews and
application to a case study.
The next section discusses the current ontology-based approaches and proposes a flow chart
for the development of the capability engineering ontology.
Ontology-Based Approaches
Ontology-based modelling for information and knowledge management has been widely used
(Hughes et al. 2009; Duan et al. 2009; Dongmin et al. 2010; Liu et al. 2010). Generally, an
ontology is defined as an explicit specification of a conceptualisation where concepts and
their relations are extracted from the real world (Studer et al. 1998; Duan et al. 2009). An
ontology-based approach is complementary to more conventional modelling approaches such
as Unified Modelling Language (UML) and Systems Modelling Language (SysML) because
an ontology is significantly useful in defining a domain from multiple author perspectives
and terminologies. Allemang 2008 elaborate one of the tenets of the Semantic web “AAA;
Anyone can say Anything about Any topic”. In contrast to conventional modelling, ontology
model has formalisms and associated inferencing that facilitate bringing multiple user
perspectives and vocabularies together. However, like conventional modelling, it also
focuses on the key concepts, i.e. “what is”, as in, “what is capability engineering and how is it
different from other engineering domains?”. The classes and relationships typically
associated with the model can also be added.
A single shared ontology for capability engineering can enable semantic interoperability and
support a formal and explicit specification of a shared conceptualisation. As recommended by
Unshold and Gruniger (2004) when developing a practical single shared upper ontology, the
mapping of ontology amongst domains and the eight different worldviews identified by the
INCOSE UK CWG (e.g. equipment, organisational and service centric worldviews) needs to
be human assisted rather than fully automated to achieve the interoperability,
interconnectedness and correlation desired between these heterogeneous domains. The
ontology shall also form tight definitions and be independent of industry sector and
applications. These are discussed later within the requirements analysis section.
A variety of methods, methodologies, tools and languages for ontology development have
already been analysed by various authors (Corcho et al. 2002; Mizoguchi 2003; Mizoguchi
and Kozaki 2009). Languages such as OWL (Web Ontology Lanaguage) and IDEF5
(Integrated Definition for Ontology Description Capture Method) in addition to tools
including Protégé and Hozo are examined to check their applicability. A process flow chart is
also proposed for developing an ontology for capability engineering as a result of analysing a
variety of developments including
• ontology-based conceptual knowledge representation model (Kourlimpinis et al.
2008);
• ontology-based information model development for science information reuse and
integration (Hughes et al. 2009);
• ontology-based knowledge modelling framework for intangible cultural heritage (Tan
et al. 2009);
• domain ontology life-cycle engineering framework for modular product design (Duan
et al., 2009; Liu et al. 2011); and
• ontology for product-service system by Cranfield University (Annamalai et al. 2010).
Annamalai et al. (2010) discusses methodologies for developing an ontology through
analysing various approaches and argued that “there is no one correct way to model a domain
and that ontology development is necessarily an iterative process”. Although there are major
similarities with these reviewed approaches, the details and context vary. As illustrated in
Figure 1, a process flow chart is proposed that incorporates the findings from the above to
enhance ontology development through pre-analysis, modelling and post-analysis phases.
The pre-analysis phase predominantly focuses on case studies. These are discussed next.
Case Studies
Appropriateness of case study material
Case studies are relatively important when extracting the necessary information and
evaluating the ontology developed. Post-analysis evaluation through application to a specific
case study can support the validation and refinement of the ontology. The INCOSE UK
Capability Working Group was approached to identify the appropriate case studies in
heterogeneous domains including defence, rail and information services; progress is reported
on these domains herein and further analysis is being conducted in other domains. A list of
features that makes the case studies appropriate is derived to guide the decision on case study
selection.
• Does the case study contain sufficient material of relevance to our definition of
capability (i.e. ability to do something) and can we map this onto the capability
engineering entity relationship diagram?
• Which domain does the case study belong to e.g. defence (land/air/sea), rail, health?
• How can we determine the level of abstraction the case study material address e.g.
generic domain, collaborative programme, specific project?
• Is there a concise but substantial source that provides detailed information about this
case study?
• Is this case study document in a form (e.g. MS Word) that is easy to process?
• What worldviews of the CWG white paper does this case study address?
• What will be the applications of an ontology for this particular case study?
Figure 1. Process flow chart for ontology development
As shown in Figure 2, various case study options have been analysed to determine their
relevance to developing a capability engineering ontology. For example, the Queen Elizabeth
Class (QEC)
1
contributes to a high level capability (i.e. the carrier strike capability) and can
have capabilities within itself (UKMoD 2012). The case studies in Figure 2 are discussed
with regards to their relevance to capability engineering e.g. the search and rescue contribute
to the overall crisis management capability but on its own it is very specific. Consequently,
this may influence the information resources to be used to extract the terms or concepts.
These programmes are perceived as capabilities; QEC is perceived as equipment-based,
ATTAC (Availability Transformation: Tornado Aircraft Contract) as service and support
related and GVA (Generic Vehicle Architecture) as capability systems engineering.
1
Note material associated with QEC and Carrier Strike in this paper are limited to that available in the public
domain.
