Embed Size (px)
Citation preview
ISSN 1744-1986
T e c h n i c a l R e p o r t N O 2006/ 21
The Role of Ontology in an ExtendibleTool for Capturing Statistical Information
Ben Cleyndert
29 September, 2006
Department of ComputingFaculty of Mathematics, Computing and TechnologyThe Open University
Walton Hall, Milton Keynes, MK7 6AAUnited Kingdom
http://computing.open.ac.uk
i
The Role of Ontology in an Extendible Tool for Capturing Statistical Information
(M801 Dissertation)
A dissertation submitted in partial fulfilment of the requirements for the Open University’s
Master of Science Degree in Computing for Commerce and Industry
Ben Cleyndert U0964938 5 March 2007 Word Count: 17,859
ii
Preface
I would like to extend my thanks to my employer, Balfour Beatty Management,
for providing both funding and occasional leave for the completion of this
dissertation. I would like to acknowledge Martin Teal, my supervisor, for
commentary through the development of this paper. Most of all I thank my
wife and family for releasing time and extending support for completion of this
course.
iii
Table of Contents
Preface ii
List of Figures ix
List of Tables xi
Abstract xii
Chapter 1 Introduction 1
1.1 Background to the research 1
1.2 Aim of research and objective of dissertation 4
1.3 Overview of the dissertation 5
Chapter 2 Research Methods 7
2.1 Selection of research methods 7
2.2 Application of the research methods 12
2.2.1 Construct the conceptual framework 13
2.2.2 Develop the system architecture 15
2.2.3 Analyse and design the system 16
2.2.4 Build the system 16
iv
2.2.5 Observe and evaluate the system 17
2.3 Summary 17
Chapter 3 Ontology and the Semantic Web 19
3.1 Ontology language selection 19
3.1.1 Scope of ontology 20
3.1.2 Schedule of ontology languages 22
3.1.2.1 Traditional ontology specification languages 23
3.1.2.2 Web ontology languages 23
3.1.3 Comparison methods for ontology languages 25
3.1.3.1 Ontology comparison by assessment against criteria 25
3.1.3.2 Ontology comparison by semiotic framework 27
3.1.4 Ontology language selection 28
3.2 Ontology tools 30
3.2.1 Selection criteria 30
3.2.2 Tool Selection 30
3.3 Discussions and summary 31
Chapter 4 MDA and the Semantic Web 33
v
4.1 MDA 33
4.2 The Semantic Web and MDA 37
4.3 MDA derivatives 40
4.3.1 Model development and model integration 40
4.3.2 Model driven distribution pattern design 41
4.3.3 Orchestration and Choreography 43
4.3.4 Generating Web applications from process models 44
4.3.5 MDA and Semantic Web services 45
4.3.5.1 MDA for specifying Semantic Web services 45
4.3.5.2 Product-line, MDA and OWL-S 47
4.3.6 Transformations between UML and OWL-S 48
4.4 Integrated approach for prototype development 49
4.5 Discussions and summary 50
Chapter 5 Development of System Architecture 52
5.1 Introduction 52
5.2 Three-tier architecture 52
5.3 Semantic Web architecture 53
vi
5.4 Distribution pattern 56
5.5 Blackboard pattern 58
5.6 Model View Controller pattern 60
5.7 Integrated architecture for the prototype 61
5.8 Summary 63
Chapter 6 Overview of System Design 65
6.1 Transformation of UML to OWL 66
6.2 Transformation of UML to OWL-S 68
6.3 Design of core OWL classes 69
6.4 Design of core OWL-S classes 71
6.5 Database design for ontology definitions and instances 72
6.6 Design of transformation classes 74
6.7 Software component (Agent) design 78
6.7.1 Service Broker 79
6.7.2 Blackboard 79
6.7.3 Coordination Agent 80
6.7.4 Ontology Data Agent 80
vii
6.7.5 Graphical Data Agent 82
6.7.6 Statistical Agent 82
6.8 Summary 84
Chapter 7 Results 85
7.1 Deployment of elicitation method 89
7.2 Conformity to requirements 90
7.2.1 Collection of data described by any UML static diagram 91
7.2.2 Specification of system behaviour by UML 91
7.2.3 Extendible by new components 91
7.2.4 Interpretation of OWL schemas for instantiation of instances 91
7.2.5 Interpretation of OWL-S process specifications at runtime 92
7.2.6 Compliance to the integrated MDA approach 92
7.3 Research question 94
7.4 Summary 95
Chapter 8 Conclusions and Future Research 96
8.1 Limitations of work 96
8.2 Comparison of results with the body of knowledge 96
viii
8.3 Conclusions 98
8.4 Future research 99
Appendices 101
Appendix A Domain Modelling 101
Appendix B Requirements Elicitation and Specification 121
Appendix C Specification Modelling 125
Appendix D Design Modelling 130
Appendix E Elicitation Results 165
Appendix F Prototype Software 198
References 199
Index 205
ix
List of Figures
Figure 2.1 Jarvinen’s taxonomy of research methods 7
Figure 2.2 V-Shaped life-cycle model 11
Figure 2.3 Timeline implementation of methods 11
Figure 4.1 Distribution pattern modelling approach 42
Figure 4.2 Process model development process 44
Figure 4.3 Product-line approach 47
Figure 5.1 Three-tier architecture 53
Figure 5.2 Semantic Web components 54
Figure 5.3 Transformation of Dai et al’s components to a three-tier
architecture 55
Figure 5.4 Service discovery architecture 56
Figure 5.5 Example distribution patterns 57
Figure 5.6 Reflective Blackboard pattern 60
Figure 5.7 Semantic Web architecture with Reflective Blackboard pattern 60
Figure 5.8 MVC architecture 61
Figure 5.9 Presentation layer of the coordination agent 62
x
Figure 6.1 UML Profile of supported OWL constructs 68
Figure 6.2 UML Profile of supported OWL-S constructs 70
Figure 6.3 UML static diagram of OWL Schema classes 71
Figure 6.4 UML static diagram of OWL-S schema classes 72
Figure 6.5 DBMS schema supporting OWL Profile 73
Figure 6.6 DBMS schema for storage of instance data 74
Figure 6.7 OWL Instantiation and DBMS classes 76
Figure 6.8 OWL-S instantiation classes 77
Figure 6.9 Communication ontology 78
Figure 6.10 UML static diagram of top-level Blackboard classes 81
Figure 6.11 UML static diagram of Coordination Agent classes 82
Figure 6.12 UML static diagram of Ontology Data Agent classes 83
Figure 7.1 OWL-S Elicitation process 86
Figure 7.2 Coordination Agent Interface 87
Figure 7.3 Data agent interface 89
xi
List of Tables
Table 3.1 Definition of concepts 26
Table 3.2 Definition of taxonomies 27
Table 3.3 Definition of relations and functions 27
Table 3.4 Definition of axioms 27
Table 3.5 Definition of instances 27
Table 3.6 Evaluation of ontology languages 28
Table 5.1 Schedule of requirements for prototype 63
xii
Abstract
Software systems are generally built by software development professionals
who are remote from the intended user’s domain. A problem with
development of systems is the successful transferral of domain knowledge
from the user to the software development team. Unified Modelling Language
(UML) is an established common language used to facilitate this. The
Semantic Web uses collaboration of agents for the completion of ad-hoc
tasks. This collaboration of agents can be considered as a software system
with its data and functionality being described by ontology. To overcome the
problem of domain knowledge transferral, there is potential to utilise the
Model Driven Architectural (MDA) approach in the creation of these ontologies
to provide users with the capability to develop software systems directly.
This research provides an overview of MDA and the Semantic Web and
details integration of the two fields to define a unified methodology and
architecture for the production of software through modelling. The MDA based
modelling methodology developed produces runtime artefacts that define data
structures and orchestrate software components in the delivery of system
solutions. A prototype is used to evaluate the capability of the derived
methodology and architecture to deliver a well-defined system derived directly
from modelling techniques familiar to users exposed to UML. Evaluation of the
prototype demonstrates that bespoke software systems can be created using
runtime artefacts derived from modelling.
1
Chapter 1 Introduction
1.1 Background to the research
The objective of this work described by Proposed M801 Topic (2005), is to
produce a tool:
‘.. to allow knowledge acquisition from experts in the form of statistical
data. The knowledge will be in the form of graphs that will be entered
via an interactive interface. The tool needs to be extendible by users
with relatively small amounts of software development experience.
Extensions will take the form of tailoring the tool and adding new
elicitation techniques. The system will be developed in Java in order to
meet platform independence requirements and facilitate extendibility.’
Proposed M801 Topic (2005)
Due to issues regarding the interpretation and usage of statistical information,
the realm of statistics is the first aspect of research considered. These issues
create ambiguity and conflicting conclusions to be drawn from similar
statistical studies (Beckett (2005) and McKeigue et al (2004)). The Semantic
Web (Antoniou et al (2004)) uses ontology (Fensel (2002)) to formally
describe information and has the potential to reduce ambiguity within the
description and usage of statistics. In corroboration with this assertion, the
Statistical Knowledge Network is developing the GovStat ontology to address
similar issues (Marchionini et al (2003)).
2
The Semantic Web and mainstream software engineering appear to have
been developing as independent streams and there are ‘synergies that could
be exploited to enable new, breakthrough capabilities in software engineering’
(Frankel et al (2004)). A well-embedded tool within software engineering is
the Unified Modelling Language (UML). Some of its popularity is derived from
its capacity to present models of software systems in a manner that both the
users and developers of such systems can understand and discuss, (The
Open University M878 (2001)).
The Object Management Group (OMG) have taken UML and integrated it into
the core of their Model-Driven Architectural (MDA) approach to software
engineering. The aim of the MDA approach is to develop modelling to the
extent where they can be transformed into actual software artefacts (Kleppe
et al (2003)). Thomas (2004) presents concerns with the underlying
philosophy of this aim. Thomas considers that modelling is inherently abstract
from a product, and that if a model were a product then there would be no
distinction between them. In contrast to Thomas’s opinion, technology is
moving forward to embrace the MDA approach through production of tools to
support the process (Kleppe et al (2003)).
Within the realm of the Semantic Web, the vision is one where an agent can
be requested to perform some ad-hoc service, and then subsequently co-
ordinate and collaborate with other agents to provide that service (Berners-
Lee et al (2001)). In the Semantic web, these agents exist as software
components that describe the services that they offer. These software
3
components obviously exist at a much higher level of abstraction than the
code in which they are written.
This higher level of abstraction allows the interaction of components to be
modelled to provide a system (Gannod et al (2004)). In terms of Thomas’s
(2004) concerns, this maintains the abstraction of the modelling process at
some level above that of the detail component implementation. Modelling at
this level has the potential to enable the usage of the MDA approach without
the intricacies of transforming models into actual code.
This has the affect of taking the philosophy of the MDA approach and
extending it. The MDA approach is concerned with the production of models
that are used for code generation. By increasing the abstraction of the
modelled artefacts, the models themselves can become executable artefacts
to be used at runtime (Knublauch (2004)). If UML can be used as the vehicle
to model systems, then there is the potential that users can develop systems
themselves, Timm et al (2005).
A requirement for the Proposed M801 Topic (2005) is that the tool needs to
be extendible by users with relatively little software development experience.
UML is a tool that breaks barriers between domain experts and software
experts to present a system in a commonly understood manner. By using
UML within the context of the MDA approach to produce an executable
artefact, the domain expert can create a system to meet their requirements
without knowledge of code. The expert is only required to understand the
configuration of services that are required to achieve their goal (Shen et al
4
(2005)). Hence, the integrated usage of the MDA and the Semantic Web
provides the background for this dissertation.
1.2 Aim of research and objective of dissertation
The driver for this work is Frankel el al’s (2004) belief that integration of the
Semantic Web and mainstream software engineering could offer benefit to
the software engineering field. This statement is considered justified by the
existence of work to unify the MDA approach with the Semantic Web
practices. This dissertation sets out to build on the work of unification to
produce a concrete prototype created through unification of the methods.
The aim of the research is to investigate the level of integration that can be
achieved between development of applications for the Semantic Web and
utilisation of the MDA approach to software development. Research therefore
focuses on the grounding of the two methods to establish where there is clear
synergy and, therefore, where the approaches can be unified. The research
question for this dissertation is:
Can the Object Management Group's Model-Driven Architecture
approach be integrated with Semantic Web ontology languages to
produce a tool based on collaborating software agents that captures
observational data described by ontologies for the purpose of further
expert knowledge elicitation through extendible statistical elicitation
techniques?
The objective of the dissertation is to build a prototype that can demonstrate a
positive response to the research question. In order to evaluate the prototype,
5
Al-Awadhi et al’s (2006) statistical elicitation technique is modelled in UML to
produce artefacts used to instantiate a system based on the components of
the prototype. Al-Awadhi et al’s paper was provided by The Open University
as their expectation of the tool to be produced. Appendix A provides domain
modelling of Al-Awadhi et al’s technique. To support Al-Awadhi et al’s
technique, the requirements for the prototype can be summarised as follows:
The tool is to capture instances of observational data and their context
as instances structured in a predefined ontology. The tool must allow
for elicitation of expert knowledge to extend observational data via
statistical elicitation techniques using an interactive interface.
The components required to realise the prototype bridge a number of
methods and technologies. Many of these warrant research in their own right.
To maintain focus within the dissertation, the research question is considered
at a conceptual level, which is reflected in the extent of implementation of the
artefacts required.
1.3 Overview of the dissertation
This dissertation commences in Chapter 2 with a description of the research
methods employed to achieve the research aim and dissertation objective.
The dissertation then proceeds describing the application of these research
methods. Chapter 3 introduces the Semantic Web and its associated
architecture and components, and specifically focuses on selection of the
core ontology language components. Chapter 4 introduces the MDA and
discusses its intersection with the Semantic Web. This intersection is
explored through investigation of service-orientated developments to the
MDA. This leads on to the presentation of an integrated development
approach for delivery of the prototype.
Chapters 5 and 6 discuss the development of the specification and design of
the prototype. Chapter 5 reviews existing works to identify component
architectures, and concludes with discussion of their integration into the
architecture for the prototype. Chapter 6 moves on to describe the design and
development of the prototype from the chosen architecture. Design limitations
of the prototype are identified and discussed.
Chapter 7 describes the implementation of Al-Awadhi et al’s elicitation
technique by the prototype. This implementation is evaluated against the
requirements for the prototype developed through chapters 1 to 5. The results
of this evaluation are then taken to assess whether the implementation of
prototype answers the research question. Finally, chapter 8 discusses the
effectiveness of the integrated development approach. This assessment is
then extended to reflect on the effectiveness and limitations of the research
methods used and their application in this dissertation. Chapter 8 concludes
with a presentation of potential areas of future research.
7
Chapter 2 Research Methods
The research methods must support the development of the prototype
software within the context of the research question. They must provide a
mechanism for both developing the approach used and its subsequent
evaluation. This chapter describes the selection and implementation of
appropriate research methods to meet the aim and objective of this
dissertation.
2.1 Selection of research methods
There are a number of research methods available, as demonstrated by
Jarvinen’s (2000) taxonomy provided in Figure 2.1 below.
Figure 2.1 Jarvinen’s taxonomy of research methods
Using above the taxonomy, the underlying research approach for this
dissertation can be classified as ‘Researches stressing utility of artefacts’,
8
and more specifically ‘Artefacts-building approaches’. Jarvinen states that the
research questions behind this approach are likely to be concerned with
whether it is possible to build a certain artefact. In this dissertation, the
possibility of building the software described by Al-Awadhi et al’s (2006)
paper is not in question since the paper describes existing software. What is
in question is whether an integrated development method combining the MDA
and the Semantic Web can be used to provide functional software that meets
the wider requirement of extendibility by users without software development
experience. In this instance, the integrated development method that extends
to runtime will influence whether the artefact can be built.
The specific method used to develop the prototype is ‘systems development’,
as described by Nunamaker et al (1990). In their literature review, they
located the following 5 major research classification schemes
i. Basic and applied research
ii. Scientific and engineering research
iii. Evaluative and developmental research
iv. Research and development
v. Formulative and verificational research
Nunamaker et al identified systems development as falling into the category
of applied science belonging to engineering, developmental and formulative
research. They describe the systems development research methodology as
being composed of the following five stages:
i. Construct a conceptual framework
9
This aspect concerns identifying and justifying the significance of the
research question(s) to be pursued. Wider tasks in this stage include
investigation of the systems functionalities and requirements,
understanding of the systems building process and study of literature
for new approaches and ideas.
ii. Develop a system architecture
This provides the road map for the systems building process. Tasks
include developing an architectural design that is cognisant of factors
such as extendibility and modularity. This stage must clearly define the
requirements of the system so that they are measurable and can be
validated at the systems evaluation stage.
iii. Analyse and design the system
Design involves the understanding of the studied domain. It includes
the application of scientific and technical knowledge for the production
of alternatives that are then synthesised and evaluated. The output
with regards software development is the specification of data
structures, functions and modules. These are furnished with the
decisions made to reach the final design based on evaluation of
alternatives.
iv. Build the system
Implementation of the system demonstrates the feasibility of the design
and usability of the functionalities of the system. The process provides
10
the researcher with insight into advantages and disadvantages of the
chosen design alternatives.
v. Observe and evaluate the system
Once built, the system is evaluated against the requirements and test
plans developed in earlier stages.
Nunamaker et al state that the system development research method should
be combined with software engineering methods and techniques to improve
the quality of both the development process and the research results.
Therefore, it is necessary to select a candidate software engineering
approach and integrate it with the research method. On the basis that
‘software engineering practices are rooted in the notion of a life cycle of
development’ (The Open University M880 (2000)), adoption of a software
engineering approach can be established by the selection of a relevant life-
cycle model.
There are a number of life-cycle models that provide the basic framework for
software engineering. In this dissertation, the requirements can be
established before any design commences. Similarly, architectural design will
precede detail design, which will precede implementation. There is no
iteration over these phases and due to there being only one resource, there
can be no incremental development. Hence, the software engineering
lifecycle model for this work will be predominantly the v-shaped life-cycle
model as described in The Open University M880 (2000). The life-cycle
model is shown in Figure 2.2.
11
Figure 2.2. V-Shaped life-cycle model
Figure 2.3 Implementation of research and software engineering methods
RequirementsElicitation
RequirementsSpecification
PreliminaryDesign
Detail Design
Coding
Unit Testing
IntegrationTesting
System Testing
AcceptanceTestingStatement
Ofrequirements
AcceptanceTest
definition
SoftwareRequirementsSpecification
System testDefinition
PreliminaryDesign
Document
IntegrationTest
Definition
DetailDesign
Documents
UnitTest
Definition
DeliveredSystem
Tested System
TestedSubsystems
TestedUnits
UnitCode
Defines
Defines
Defines
Defines
RequirementsElicitation
RequirementsSpecification
PreliminaryDesign
Detail Design
Coding
Unit Testing
IntegrationTesting
System Testing
AcceptanceTestingStatement
Ofrequirements
AcceptanceTest
definition
SoftwareRequirementsSpecification
System testDefinition
PreliminaryDesign
Document
IntegrationTest
Definition
DetailDesign
Documents
UnitTest
Definition
DeliveredSystem
Tested System
TestedSubsystems
TestedUnits
UnitCode
Defines
Defines
Defines
Defines
ConstructConceptualframework
Buildsystem
Analyseand
design
DevelopSystem
architecture
ObserveAnd
evaluate
Research Method
Software Engineering Method
Elicitation CodingDetailDesign
RequirementsSpecification
UnitTesting
Test Plan Development
Time
PreliminaryDesign
IntegrationTesting
SystemTesting
AcceptanceTesting
ConstructConceptualframework
Buildsystem
Analyseand
design
DevelopSystem
architecture
ObserveAnd
evaluate
Research Method
Software Engineering Method
Elicitation CodingDetailDesign
RequirementsSpecification
UnitTesting
Test Plan Development
Time
PreliminaryDesign
IntegrationTesting
SystemTesting
AcceptanceTesting
12
The lifecycle model provides a generic representation of the software
engineering activities involved with this dissertation. This needs to be
coordinated with the research method in order to ensure the simultaneous
delivery of both. Specifically for this dissertation and the chosen lifecycle,
figure 2.3 shows the respective timeline implementation of the methods.
The nature of the research question requires a high level of literature search
and review to establish the components of the prototype. The intensity of this
is increased by the need to implement a development process that can be
used to design the prototype and also be used to configure the prototype into
a usable system. The high level use of the literature search and review
research method overrides some components of the systems development
research method for the purposes of this dissertation. Specifically, this affects
the amount of options considered during the design phase.
2.2 Application of the research methods
The following subsections consider the implementation of each of Nunamaker
et al’s (1990) five stages. In accordance with figure 2.3, the associated
activities of the v-shaped life-cycle model are discussed within their relevant
research stage.
A large portion of this dissertation is literature search, forming a significant
component of the first three stages of the systems development method.
Literature search has been achieved predominantly through electronic
means. Where possible, journal papers have been used as the basis of the
body of evidence. However, a large portion of the material used has been
13
conference literature. To ensure accuracy, evaluation of literature has been
achieved by triangulation.
2.2.1 Construct the conceptual framework
The first stage of the systems development research method is the
construction of a conceptual framework. A key aspect of this stage is the
identification of the setting and boundaries of the research, which is described
in Chapter 1. The literature search and review provided an overview of the
problem domain, the aim of the project, the research question and the
significance of the project in terms of its contribution to knowledge.
Approaches and technologies for the development of the prototype have been
identified.
The conceptual framework is configured around the concept of integrating
ontology into virtually all aspects of both the development of the prototype
and its end usage and extension. The literature search in this area identifies
currently available ontology languages and a qualitative methodology for
justification of the selection of specific ontology languages. This search
focuses around the work of Gomez-Perez et al (2002). After choosing a
suitable ontology language, a tool for development of ontologies has been
located and selected. These activities are described in chapter 3.
The overriding development process for the prototype is the use of the MDA
approach integrated with principles abstracted from Semantic Web
development. The literature search identified the underlying processes
associated with these approaches. Ontology has been used to describe the
14
MDA deliverables, and the works of Frankel et al (2004), Atkinson (2004),
Timm et al (2005) and Gannod et al (2004) provided the background of how
this is achieved. These aspects are discussed in chapter 4.
The systems functionalities and requirements were developed from a range of
sources. The full requirements specification is presented in Appendix B,
which summarises the requirements for the project derived over the course of
the dissertation. The key requirements are as follows:
• Delivery of Statistical Elicitation Software
• Hybrid MDA and Ontology Development
• Software Agent Architecture (Semantic Web)
• Ontology co-ordination of software components (software agents) to
produce a functional system
• Extendible with low software development experience
The relevant components of the software engineering life-cycle model for this
stage of the research method are requirements elicitation and requirements
specification. This included the domain modelling of the statistical elicitation
technique to be instantiated at runtime by the prototype. The domain
modelling provided the initial conceptual models upon which to derive runtime
artefacts. It also enabled further understanding of the requirements for the
prototype. The domain modelling for the elicitation technique is included in
Appendix A.
The test plan for this stage of the software engineering life-cycle deals with
aspects of validation, producing both the acceptance test definition and
15
system test definition. These are included in Appendix B, and are required in
identifying whether the resulting prototype has met the research aim.
2.2.2 Develop the system architecture
To establish system architecture, the literature search focused on identifying
architectures currently operating within the Semantic Web. Schattkowsky et al
(2005) and Schreiber et al (2001) discuss ontology for generation of user
interfaces. Chen et al (2003) and Aarsten et al (1996) provided a background
to three-tier architecture, with Grundy et al (2004) identifying its commonality.
Dai et al (2005) provided a solution for multi-agent technologies including the
use of databases. Buhler et al (2004) discuss architecture for service
discovery and Barrett et al (2006) described potential distribution patterns.
Blackboard patterns were widely described in papers such as Shaw et al
(1996) and Kung et al (2003). Architectures are evaluated in chapter 5, which
also describes the selection of the prototype’s architecture.
The software engineering life-cycle aspect related to this stage is preliminary
design, incorporating static and behavioural domain modelling of the software
system. The preliminary design document focuses on abstraction of the
architectural properties of the prototype, identifying the key architectural
patterns and components. The preliminary design is included in the
Specification Modelling provided in Appendix C. Appendix C also includes the
integration test definition which is based on the UML interaction diagrams
derived for the prototype’s components and the domain modelling from
Appendix A.
16
2.2.3 Analyse and design the system
During this stage, the conceptual architecture output from the prior stage was
extended to flesh out the individual component architectures of the entire
software system. Based on this extended architecture, the individual
components were designed and specified through UML modelling and
complemented with unit test plans focused on validation.
The prototype is to collate statistical data together with attribute values
providing semantic definition based on an imported ontology. The prototype
imports the ontology ‘schema’ and provides an interface suitable for inputting
observational and graphical data and associated semantic information.
Additionally the prototype integrates expert elicitation with process and
behavioural aspects being described by ontology. The primary purpose of the
prototype is to confirm a functional system can be produced from the
integration of the methods identified and selected from the literature search
and review. The design of the prototype is described in chapter 6, with the full
design and unit tests provided in Appendix D.
2.2.4 Build the system
The preceding research methods provided the specification, design and test
data for the prototype. This stage demonstrates the feasibility of the design
providing insight into the advantages and disadvantages of the design
decisions. The build process was heavily reliant on on-line forums to establish
methods to instantiate the design. These forums were widespread due to the
range of technologies used in the design. The software engineering activity
17
associated with this stage is coding. The code listings are provided in
Appendix F.
2.2.5 Observe and evaluate the system
Abstraction of Al-Awadhi et al’s (2006) statistical elicitation technique
provided the unit test plan designed to assess the extent to which the
software produced matched the aims of the research. This stage of the
research method focused on identifying the success or failure of the resulting
prototype in meeting these aims. Chapter 7 provides this evaluation,
discussing the implementation of the elicitation technique and reviewing the
prototype’s compliance with requirements and test definitions. Where there is
non-compliance, the design decisions have been reviewed to identify either
inherent design deficiencies or compromises made to arrive at an operational
prototype.
2.3 Summary
The research methods for this dissertation have been identified as literature
search and review integrated with systems development. The systems
development research method is complemented by a software engineering v-
shaped life-cycle model. The following chapters describe the implementation
of this method to the dissertation. The first stage of the systems development
method is construction of a conceptual framework. The significance of the
research question and outline requirements and functionality have already
been covered. Chapter 3 commences the wider tasks of this first stage with
18
an overview of Ontology within the Semantic Web and the subsequent
selection of an ontology language for the dissertation.
19
Chapter 3 Ontology and the Semantic Web
The Web is moving towards its third generation and into what is termed the
Semantic Web (Gomez-Perez et al (2002)). Within the realm of the Semantic
Web, the vision is one where an agent can be requested to perform some ad-
hoc service, and then subsequently co-ordinate and collaborate with other
agents to provide that service (Berners-Lee et al (2001)).
'The Semantic Web dream is of a Web where resources are machine
understandable and where both automated agents and humans can
exchange and process information.' van Harmelen et al (2002)
In the Semantic web, these agents exist as software components that
describe the services that they offer. The component used to define their
services and to exchange information is ontology. Various languages exist for
the production of ontologies, and there are tools available for the building and
editing of ontologies (Gomez-Perez et al). For coherence with the Semantic
Web, an ontology language is required for the prototype, and this chapter
presents the selection of a suitable language.
3.1 Ontology language selection
MSN Encarta (2006) provides an historical background to ontology,
describing it as a facet of Metaphysics. Metaphysics is the branch of
philosophy concerned with the nature of ultimate reality, where ontology deals
with the distinct sorts of entities that describe the universe. This combines
with broader metaphysics that is concerned with describing the most general
20
traits of reality. Ontology is focused on the physical world of human
experience. The word ‘ontology’ originated in the Greek language, meaning
‘the study of being’ Wikipedia (2006).
In computer science, Gruber (1993) describes how ontologies were
developed in Artificial Intelligence to facilitate knowledge sharing and re-use.
More recently, ontologies have been integrated into the development of the
Semantic Web. The Semantic Web is concerned with the representation of
Web content in a form that is easily machine-processable and which uses
intelligent techniques to take advantage of these representations (Antoniou
2004).
Within computer science, there are many definitions of ontology with van der
Vet et al (1998) locating seven. For the purposes of this dissertation, the
definition provided by Fensel (2002) will be used, where ontology is ‘a formal,
explicit definition of a shared conceptualization’. A ‘conceptualization’ refers to
an abstract model of some phenomenon in the world that identifies the
relevant concepts of that phenomenon. ‘Explicit’ means that the used
concepts and their constraints should be explicitly described and ‘formal’
means that the ontology should be machine-readable.
3.1.1 Scope of ontology
This dissertation is based around investigation of the potential for integration
of the Semantic Web concept of ontology and the Object Management
Group’s (OMG) Model Driven Architecture (MDA) approach to software
development. The findings of this investigation are used to develop a
21
statistical knowledge elicitation tool whose architecture is described by
ontology and which uses ontology at runtime for delivery of a composite
service provided by collaborating software agents. Atkinson (2004) identifies
the intersection of an ontology-based approach to knowledge management
and a MDA approach to software development. The paper suggests that
unification of the approaches should be through direct extension of the UML
(Unified Modelling Language) model, indirect extension of the UML model or
definition of a new MDA meta-model.
This dissertation is concerned with utilisation of existing ontology languages
for the description of a MDA approach to software development, and is a step
back from Atkinson’s unification approach. This bears close relation to
Gannod et al (2004) who focus on their work in developing a method to allow
Semantic Web services to be described with ontology through development of
a standard UML model. Their goal is to remove the steep learning curve
associated with an ontology language via automatic generation of the
ontology specifications.
The two primary requirements of their work are to incorporate both Web
services and Semantic Web services with the ability to create federations or
applications from compositions of services. Compositions of services are to
be achieved through ontology specifications. Their preferred approach is by
using product-line architecture. In order to achieve a successful outcome, the
ontology language(s) used must be sufficiently elaborate to describe UML.
Conversely, the language must not be too elaborate to be represented by
UML. Briefly summarising from the OMG’s UML Specification, the key
22
component of UML is the concept of an object, that being an instance of a
class. Classes are described by properties and methods, properties
describing the state of an object, and methods defining the behaviour of an
object. UML is a process of modelling software using the following
techniques:
• Use case diagram
• Class diagram
• Behaviour diagrams
o Statechart diagram
o Activity diagram
o Interaction diagrams
Sequence diagram
Collaboration diagram
• Implementation diagrams:
o Component diagram
o Communication diagram
In addition to describing UML, the chosen ontology language must be
sufficient for describing real world concepts, detailing their inter-relationships,
constraints and instances.
3.1.2 Schedule of ontology languages
The literature search and review has located a number of ontology languages
to consider for use by the prototype. The languages fall into two categories,
traditional and Web ontologies (Corcho 2000). Web ontologies utilise W3C’s
23
XML metalanguage as their basis which is easy to parse, has well defined
syntax and is human readable.
3.1.2.1 Traditional ontology specification languages
The literature search has identified the following ‘traditional’ ontology
languages, where traditional is defined as not designed for the web.
• CycL is a declarative language. CycL is used to represent the
knowledge stored in the Cyc Knowledge Base, available from Cycorp
• Ontolingua, the original Ontolingua language, as described in Gruber
(1993), was designed to support the design and specification of
ontologies with clear logical semantics
• F-Logic is a full fledged logic suitable for defining and manipulating a
database schema (Kiferand (1989))
• OCML provides mechanisms for expressing items such as relations,
functions, rules, classes and instances (Motta (1998))
• Telos is an object-centred language for maintaining a software
knowledge base (Mylopoulos (1990))
• LOOM is a high-level programming language and environment
intended for use in constructing expert systems and other intelligent
application programs (Corcho (2000))
3.1.2.2 Web ontology languages
Gomez-Perez et al (2002) and Horrocks et al (2003) identify the following
ontology languages developed for the web:
24
• Ontology Exchange Language (XOL) was designed by the US
bioinformatics community for the exchange of ontology definitions
between heterogeneous software systems. XOL is based on merging
Ontolingua and OML and takes an XML form
• Simple HTML Ontology Extension (SHOE) is an extension of HTML,
incorporating machine-readable semantic knowledge in HTML
documents or other Web documents. SHOE has been adapted into
XML
• Ontology Markup Language (OML) is partially based on SHOE, and
exists in four levels, Core, Simple, Standard and Abbreviated. Simple
OML maps directly to RDF(S)
• Resource Description Framework and RDF Schema (RDF(S)) was
developed by W3C for describing Web resources, and allows
specification of semantics via XML. It has mechanisms for explicit
representation of services, processes and business models
• Ontology Interchange Language (OIL) permits semantic interoperability
between Web resources and Its syntax and semantics are based on
OKBC, XOL, and RDF(S). It provides modelling primitives commonly
used in frame-based approaches (concepts, taxonomies of concepts,
relations, and so on). It incorporates formal semantics and reasoning
support found in description logic
• DARPA Agent Markup Language + OIL (DAML+OIL) originates from a
joint committee composed of US and European members. It has been
developed in the context of DAML based on the OIL language and
allowing interoperability via XML
25
• Web Ontology Language (OWL) has now superseded DAML+OIL as
the W3C recommended ontology language, Horrocks et al (2003).
OWL is designed to retain as much compatibility as possible with
RDF(S), DAML+OIL, SHOE and OIL
3.1.3 Comparison methods for ontology languages
The literature search has identified two methods for comparison of ontology
languages to facilitate the selection process. The next sections describe
these methods and present their findings.
3.1.3.1 Ontology comparison by assessment against criteria
Gomez-Perez et al (2002) provide 5 criteria of Concepts, Taxonomies,
Relations and Functions, Axioms and Instances for comparison of XOL,
SHOE, OML, RDF(S), OIL and DAM+OIL ontology languages. They describe
concepts as anything about which something can be said and indicates that
they are equivalent to object orientated classes. Ontology languages are
classified against their ability to define partitions (sets of disjoint concepts)
and their documentation for a concept. The assessment includes whether the
language provides mechanisms to define Instance, class, local and global
attributes. The final aspects of concepts considered are whether a language
provides predefined facets for default slot value, attribute type, cardinality
constraints, and attribute documentation.
Taxonomies are described as being used to organise ontological knowledge
using generalisation and specialisation relationships. The languages are
assessed for capability for expressing Subclass Of, Disjoint Composition,
26
Exhaustive Subclass Decomposition, and Not Subclass Of relations. The
Relations and Functions aspect considers whether languages can represent
arbitrary n-ary relations (or functions), type and integrity constraints, and
operational definitions.
The method presents axioms as ontology language’s ability to model
sentences that are always true and can be used for purposes such as
verifying correctness or deducting new information. Finally, instances are
assessed which concern the language’s ability to represent actual instances
of a concept, relationships between instances (facts) and assertion of facts
(claims).
The following tables present the results of Gomez-Perez et al ‘s investigation
of the ontology languages for their capability of expressing the 5 criteria set
out above.
Table 3.1 Definition of concepts
27
Table 3.2 Definition of taxonomies
Table 3.3 Definition of relations and functions
Table 3.4 Definition of axioms
Table 3.5 Definition of instances
3.1.3.2 Ontology comparison by semiotic framework
The semiotic framework is described by Lindland (1995) and is based upon
three quality aspects of domain appropriateness, comprehensibility
appropriateness and technical actor interpretation appropriateness. Su (2004)
uses the semiotic framework for evaluating ontology languages consisting of
Ontolingua, F-Logic, OCML, LOOM, Telos, OIL, RDF(S), DAML+OIL, XOL
28
and SHOE. Domain appropriateness is divided into expressive power and
perspectives. Seven perspectives are considered, they being structural (S),
functional (F), behavioural (B), rule (R), object (O), communication (C) and
actor-role (AR).
Comprehensibility Appropriateness concerns making the language
comprehensible to the social actor. The factors considered are the number of
constructs and the abstraction mechanisms (classification (Cla),
generalization (Gen), aggregation (Agg) and association (Ass)). The results of
Su’s evaluation are provided in table 3.6
Table 3.6 Evaluation of ontology languages
3.1.4 Ontology language selection
The selected ontology languages are OWL and OWL-S (OWL services
language). Although neither of the methods presented above consider the
current W3C recommendation of OWL, Antoniou (2005) considers that
conclusions from the Gomez-Perez et al analysis for DAML+OIL are valid for
OWL. Su’s method measures the functional and behavioural perspectives of
29
languages, but identifies functional perspectives as present only in OCML and
Telox languages. Neither of these languages is considered suitable for the
project due to them not being specifically Web compliant. Web compliance
requires an XML base and all traditional languages are ruled out for this same
reason.
OIL and DAML-OIL are no longer being developed and have been effectively
replaced by OWL. OWL has been developed to encompass compatibility with
RDF(S), with RDF(S) being a subset of OWL (Antoniou (2005) ). Neither
XOL nor SHOE provide functional or behavioural perspectives and are
therefore unlikely to be able to express method and behavioural aspects of
UML.
There is recent work in the field of integrating/interfacing UML and Web
Ontology languages. An example is Grønmo et al (2005), who propose a
UML profile for semantic Web services that enables the use of graphical
models as the integration platform for Web services. They describe the
transformation both ways between UML and OWL-S, showing that UML is
sufficiently expressive to support one of the leading semantic Web service
languages. Web services can be reused in combination to realise complex
business processes.
According to Grønmo et al, the most commonly used Web service proposals
for description (WSDL), invocation (SOAP) and composition (BPEL4WS) lack
proper semantic descriptions of services. The benefit of using semantic
descriptions for Web services is that searches for existing services become
more precise and provide the ability to automate the composition of services.
30
Grønmo et al’s technique is to use the MDA for the development of Web
services.
3.2 Ontology tools
Having established OWL as the ontology language to be used, the next step
was to identify and select ontology-editing tools for the production of
ontologies. Denny (2006) produced an ontology tool survey in 2004 that
updated his original survey of tools undertaken in 2002. This is a
comprehensive schedule of tools available at that time and provides a
reference to identify and evaluate potential tools.
3.2.1 Selection criteria
Preferences for software tools can be a matter of personal choice. The
preferences for an ontology tool for this dissertation are as follows:
• Support for OWL including OWL-S
• Support for UML
• Conversion between OWL, OWL-S and UML and vice-versa
• Behavioural modelling of software
• Graphical representation and manipulation of models
3.2.2 Tool selection
Denny’s survey covers approximately 126 ontology-editing tools. 20 tools
either support or planned to support OWL at the time of the survey, and 4 of
these tools support UML. The 4 tools are as follows:
31
• Protégé
• OPCAT (Object Process Case Tool)
• Integrated Ontology Development Environment (IODE)
• WebODE
Literature searches regarding ontology editing tools for the Semantic Web
indicate Protégé as being the most referenced editing tool. OPCAT provides
process animation, which may well be useful in modelling the interaction of
the prototype’s components.
3.3 Discussions and summary
The language comparison methods and their results were not recent enough
to consider the OWL suite of languages. They are, however, suitable for
review of the alternative ontology languages to OWL. Traditional ontology
languages were ruled out on the basis of non-Web compliance with the
possibility of isolating the work from mainstream activity. Other Web
compliant languages were ruled out either due to absence of capability to
express behaviour or due to having been superseded by OWL.
A study of available ontology editing tools resulted in the short-listing of
Protégé and OPCAT. Use of these tools showed Protégé to be the preferred
choice. Protégé offered a more intuitive user interface and investigations
indicated that the tool is in much wider use than the alternative, OPCAT.
Widespread use of the tool had the benefit of providing access to a range of
user groups and on-line resources to assist in its usage.
32
This chapter has demonstrated the grounding of ontology within the Semantic
Web and has resulted in selection of both ontology languages and a tool to
support subsequent work. The next chapter continues with stage one of the
systems development research method, with the study of the MDA and an
investigation into its integration with the Semantic Web.
33
Chapter 4 MDA and the Semantic Web
The purpose of this chapter is to establish the primary approach for the
construction of the prototype and completes stage one of the systems
development research method. In realisation of this goal, this chapter is
structured as follows. In section 4.1 the MDA approach is introduced and
some of the pitfalls within its current level of development are identified.
Section 4.2 discusses the intersection between the Semantic Web and the
MDA. Section 4.3 summarises service-orientated developments to the MDA
approach. Section 4.4 describes the MDA based approach to be used for this
dissertation, and finally Section 4.5 summarises the chapter’s findings.
4.1 MDA
Kleppe et al (2003) describe the MDA approach by reference to the
development of a practical example. The MDA approach is a framework for
software development defined by the OMG. The approach uses UML models
built at decreasing levels of abstraction. Initially these models are platform
independent, and the approach transforms these into platform specific models
and then into code. The outcome is the ability to create software purely from
abstract modelling. At the time of writing, Kleppe et al recognised that a
number of the components required to support the process were unavailable,
the implication being that the MDA cannot be fully implemented.
Meservy et al (2005) state that models are commonly used to flexibly
represent complex systems. Models are used at varying levels of abstraction,
which can be combined to provide intelligible and accurate representations of
34
a system. Many software development experts have long advocated the use
of models to understand systems, yet their tendency for use is limited to only
the initial stages of software development, after which the models tend to be
left behind. In this process, the models are rarely updated with changes to the
system.
They describe the MDA as part of a larger trend within the software industry
to carefully layer models of systems at various levels of abstraction. In this
realm, high-level languages have replaced assembly language. Libraries and
frameworks are replacing isolated code segments in re-use and design
patterns are replacing project specific code. Well-defined rules are used to
convert models into deployed code, although they point out that rules cannot
capture all the details required to achieve complete code and recognise that
this is a common objection to the MDA approach.
The MDA software development lifecycle is presented as a five-step process:
i.Capture requirements in a Computational Independent Model (CIM)
Kleppe et al (2003) define the CIM as a business model. This
corresponds commonly to a domain model, which is abstract from a
software solution. Hence, a CIM models business processes within an
area of interest without specifying any aspect of the business
processes as being integrated within a new software system. However,
parts of the business model may be supported by existing software
systems. Ultimately the CIM is considered to be software independent.
35
ii.Create a Platform Independent Model (PIM)
Kleppe et al state that automatic derivation of PIMs from a CIM is not
possible, as the selection of business processes to be supported by a
software system is always a human activity.
iii.Transform the PIM to Platform Specific Model(s) (PIM), adding
platform specific rules
Kleppe et al describe transformations as being undertaken by
transformation tools in accordance with transformation definitions.
Transformation definitions are a collection of rules that are
unambiguous specifications of the way that aspects of one model can
be used to create aspects of another model. Kleppe et al define the
transformation components as follows:
‘A transformation is the automatic generation of a target model from a
source model, according to a transformation definition
A transformation definition is a set of transformation rules that together
describe how a model in the source language can be transformed into
a model in the target language.
A transformation rule is a description of how one or more constructs in
the source language can be transformed into one or more constructs in
the target language.’ Kleppe et al (2003)
36
Meservy et al (2005) present PIMs as system representations that are
sufficiently general to capture the semantics of a system for
deployment in many different environments, yet precise enough to
eventually support transformation into code
iv. Transform the PSM to code
Meservy et al identify that the MDA has critics for the reliance of the
MDA on UML for automatic code generation. UML is not considered
sufficiently precise to enable complete code generation, as it does not
capture code level semantics. Furthermore, Kum et al (2006) identify
that transformation of MDA structural models has been successfully
applied in practice, but transformation of dynamic models and
pervasive services largely remains as an area for further research.
v.Deploy the system in a specific environment
Meservy et al cite the benefits of MDA as long-term flexibility (to
include changes to PIM without substantial code-writes) and increased
productivity with lower costs. They accept issues with code generation
from UML, but consider that being able to ensure that a system
represents a client’s requirements is sufficiently advantageous to
negate this issue.
The fundamental philosophy behind the MDA is challenged by Thomas
(2004). Thomas takes the view that modelling is distinct from a product and
modelling is undertaken to create partial abstractions of a product.
37
Concerning producing an application from the model he says: ‘the term
executable specification is an oxymoron - if the specification were truly
executable, it would actually be - the thing. Otherwise, it would merely model
'the thing,' which is by definition partial and incomplete’. Thomas’s argument
is quite strong. Programming languages exist at a level of complexity in order
to have the capability to describe the functioning of their products.
It is questionable whether a modelling language at a level of abstraction from
a programming language can have the capacity to be reliably transformed
into that programming language. Less questionable is the ability to model the
interaction of artefacts produced in a programming language that exist a level
of abstraction similar to the modelling language. This is supported by the
Semantic Web, where the interaction of software agents is configured to
provide a service, Berners-Lee et al (2001). In this environment, can the MDA
approach be used to model collaboration between existing artefacts to create
an operational system, and what are the benefits?
4.2 The Semantic Web and the MDA
OWL-S is an ontology language that allows for the automatic discovery and
composition of services. The OWL-S has been officially submitted to and
accepted by the W3C (W3C OWL-S (2004)). OWL-S has three key tasks,
automatic Web service discovery, service invocation, and composition and
interoperation. OWL-S moves ontology from static knowledge to dynamic
behavioural specifications.
38
Timm et al (2005) and Gannod et al (2004) focus their work in developing
methods to allow Semantic Web services to be described with OWL-S
through development of standard UML models. Their goal is to remove the
steep learning curve associated with the OWL-S language. This is achieved
through automatic generation of OWL-S specifications, allowing development
of applications that are based on the use of semantic Web services but
described with UML.
Grønmo et al (2005) describe a procedure for Model-Driven Semantic Web
Service Composition using a method of transferral of UML models to OWL-S
and vice versa. The process captures the aspect of configuring a new service
from a set of existing services that may be composite or atomic.
Interest in transformation to OWL-S is not limited to just the field of UML.
Shen et al (2005) discuss their tool within the E-Business domain for mapping
BPEL4WS (Business Process Execution Language for Web Services) to
OWL-S. Their interest lies in 'once Web services are designed and built by
technical people, business process architects can aggregate them to solve
the business level problems'. They recognise that once the component
artefacts are created, a different set of skills is used to configure the operation
of those artefacts into a business-orientated system. This is consistent with
offering extendibility of systems to domain experts.
UML is a widely used tool that bridges the gap between technical and domain
experts. Therefore, in both the MDA and Semantic Web realms, UML offers a
platform for domain experts to specify the systems through visual models that
can be transformed into artefacts used by existing software component
39
artefacts to provide extendibility of software systems. This is consistent with
Knublauch (2004) who believes:
‘domain models are not only used for code generation, but they are
used as executable artefacts at run-time …. Domain models should not
be regarded as intermediate artefacts that are only used for generating
code and then put safely inside the drawers of a company’s archive.
Instead, domain models can be made executable on their own, and
they can be shared between applications in an open-world setting such
as the Semantic Web. This encourages reuse and inter-operability’
Knublauch (2004)
Frankel et al (2004) state ‘researchers in knowledge representation and
practitioners of the OMG’s Model Driven Architecture (MDA) are beginning to
recognize that there is overlap in these technologies and that there may be
synergies that could be exploited to enable new, breakthrough capabilities in
software engineering’. Frankel et al focus on the ontology aspect of the
Semantic Web, and the advantages of reasoning that ontology can bring to
the MDA for complex heterogeneous systems.
Like Frankel et al, Atkinson (2004) also explores the similarities between
Ontology and the MDA approach. Atkinson identifies the intersection of an
ontology-based approach to knowledge management and the MDA approach
to software development. The paper describes the current position of
unification of the two approaches. The paper suggests that unification of the
approaches should be through either direct extension of the UML model,
indirect extension of the UML model or definition of a new MDA meta-model.
40
The paper considers whether the conceptual variance between the Ontology
and MDA approaches is necessary or just a result of their independent
development. Atkinson believes that ontology is in actual fact a subset of
UML and that UML is already an ontology representation language.
The capability of UML to be used to build ontologies is a key integration
aspect of the MDA and Semantic Web approaches. Transformation of UML
models into the operational context of ontology in the Semantic Web allows
this software engineering method to expand its usage into the field of the
Semantic Web.
4.3 MDA derivatives
In light of the difficulties associated with complete implementation of the MDA
approach, there are a number of examples of modifications to the MDA
approach based around utilisation of service components that exist at a
higher level of abstraction than code. This circumvents the issues surrounding
the ability to produce code from UML, and yet still provides the potential to
create an operational system from models derived at PIM level. A sample of
these approaches is presented below.
4.3.1 Model development and model integration
Davis et al (2005) recognise that MDA has yet to be realised as a proven
concept or as a deployable technology. There is a high degree of scepticism
as to whether MDA will even prove to be worthwhile. Hence, the bulk of MDA
research is motivated to developing the basic technology alternatives for
41
practical application of MDA. Whilst advocating the continuing development of
MDA, they consider that
‘…. the current focus on developmental and technological issues such
as components, reuse and cross platform compatibility will become
obsolete and replaced by the concepts of Model Development and
Model Integration (MI) as the primary focus.’ Davis et al (2005)
They justify this statement on the basis that once MDA is established, the PIM
becomes the only variable in application development. Hence, this will evolve
to editing capability for non-technical users allowing application model
authoring, merging and editing to be achieved by the common user. This will
usher in a new age of accessible and efficient computer usage and
information access.
4.3.2 Model driven distribution pattern design
Barrett et al (2006) state that service based enterprise systems are often
realized by composing a number of Web services. This process is often ad-
hoc without consideration of non-functional requirements and requiring
considerable low level coding for realization. They suggest an approach
combining MDA with a method for achieving decentralized communication
amongst services and a Web serviced based facility for enabling the
deployment of compositions.
Their modelling approach suggests that Web service compositions have three
modelling aspects. Service modelling expresses interfaces and operations.
42
Workflow modelling expresses the control and data flow from one service to
another within the composition. Finally, distribution pattern modelling
expresses how the composed system is to be deployed. Their development
approach is based on MDA, and more specifically on the creation of high-
level models that allow for the auto generation of fully executable systems.
Within the MDA approach, a distribution pattern is comparable to the PIM
model since it is not tied to any specific workflow specification language.
The models created are based on existing Web service interfaces that require
limited intervention from a software architect to define the distribution pattern
for the system. The system’s distribution pattern is generated using a UML
2.0 based Activity Diagram. They state some benefits of their approach to be
isolation from instability of un-standardised Web composition languages as
well as fast and flexible development of compositions. Their modelling
approach breaks down into the 6 steps shown in figure 4.1 below.
Figure 4.1 Distribution pattern modelling approach
The first step takes a number of Web services interfaces as input, and
transforms the interfaces into a UML 2.0 activity diagram. The second step
43
involves the selection of an appropriate distribution pattern and the re-
definition of the sequence of actions to suit. The third step transforms the
model into a Distribution Pattern Language (DPL), which in step four is
validated against the model generated in step two. Step five creates
interaction logic in the target language and interfaces which expose the new
interaction logic processing capability as a wrapper to the existing Web
service functionality of the participant. Step 6 is the final deployment of the
system.
4.3.3 Orchestration and Choreography
Bocchi et al (2005) considers Service Orientated Architecture (SOA) defined
as ‘a set of components which can be invoked, and whose interface
descriptions can be published and discovered’. SOA is constructed from
network addressable service components with well-defined interfaces with
stateless connections using standard communication protocols. Web
Architecture is considered an instance of SOA, where services are Web
servers, interfaces are Web pages and the final user is usually human. Web
Architecture is currently evolving into Web Service Architecture, also an
instance of SOA, where services have well defined interfaces and are
accessible to both human and other software components.
In a Web service scenario, Orchestration and Choreography define the
coordination of activities through the execution and management of business
processes. In this realm, an application, traditionally considered as a
combination of computation and coordination, becomes equivalent to a
workflow defined as a combination of activities and processes.
44
4.3.4 Generating Web applications from process models
Schulz-Hofen et al (2006) state that a shift from separate application
development to customisation of pre-engineered solutions promotes
reductions in time to market and maintenance effort. Application of process
based software product-lines to Web development enables the average
business user to create applications from business models. They describe a
case study intended to verify these statements through development of a
software generator for process-based Web applications.
Figure 4.2 Process model development process
They utilise the concept of software product-lines, promoting the re-use of
artefacts. Manual changes to artefacts are costly and error prone, hence
common sense dictates to split the software engineering process into two
phases, domain engineering and the application engineering. Domain
engineering encompasses the common domain for all software products of an
entire product-line. This encourages the foundation of artefacts common to
45
the product range, with the implementation of re-usable software components
to form new software products within the product-line.
In their approach, application engineers derive a process model based on the
‘process family’ of the product-line, resolving variation points in the ‘family
architecture’ models and freely combining process building blocks. The result
from this exercise is a concrete variant- free process model. The development
process used is depicted in figure 4.2. By using Business Process Modelling
Notation (BPMN), they facilitate their intention to allow business users without
knowledge in software development to undertake the role of application
engineers.
4.3.5 MDA and Semantic Web services
Timm et al (2005) and Gannod et al (2004) independently describe their
combined efforts in development of a semantic Web service approach for
creation of application. This section considers first the work of Timm et al, and
then the work of Gannod et al.
4.3.5.1 MDA for specifying Semantic Web services
Timm et al define a Web service as a loosely coupled component that
exposes functionality to a client over the internet (or intranet), using standards
such as HTTP, XML, SOAP, WDSL and UDDI. They state problems
associated with usage of Web services as including those of specification,
search and discovery, selection, composition and integration. WSDL currently
dominates current practice in Web services in specifying their access, but
note that WSDL lacks the ability to address the stated problems due to lack of
46
semantic constructs. They believe that semantic constructs address issues of
search, discovery, selection, composition and integration.
Timm et al describe an approach to software development that they compare
to MDA on the basis of the use of UML modelling combined with
transformation of models into OWL-S. OWL-S is an ontology broken into
three parts. The Service Profile describes the capabilities of the service. The
Service Model describes how the service works internally. Finally, the Service
Grounding describes how to access the service. As such, it is concluded that
the OWL-S ontology provides a uniform mechanism for describing the
semantics of a Web service.
The benefit of their is approach is stated as mitigating the difficulties of the
steep learning curve associated with OWL-S by allowing the use of UML, a
language with a wide user base, and thus facilitating the adoption of Semantic
Web approaches. Due to OWL-S’s ontology background, Timm et al
compare, and consider similar, the modelling of ontologies and domain
modelling within a software engineering context. Through this analogy, they
believe that ‘development of applications that are based on the use of
Semantic Web services should not require knowledge beyond the use of the
UML modelling language’.
In realisation of their approach, two primary requirements are identified:
‘R1 The approach should be able to incorporate the use of both Web
services (e.g., services with WSDL specifications only) and semantic
Web services (e.g., services with semantic descriptions)
47
R2 The approach should facilitate composition of services to form
applications or federations.’ Timm et al (2005)
Here the second requirement encapsulates their philosophy of integrating
Web services into composite services through the generation of OWL-S
specifications via the use of MDA. In their approach, creation of an UML
model corresponds to the MDA PIM, and subsequent generation of OWL-S
groundings corresponds to creation of a PSM in the sense that the
transformation provides information specific to creating a specific executable
implementation of a semantic service.
4.3.5.2 Product-line, MDA and OWL-S
Gannod et al’s (2004) approach is one of using a product-line strategy to
facilitate service composition. The approach is based on the development a
common set of core assets, which through re-use, achieve product
differentiation and personalisation by configuration into the product family.
The context of the approach is shown in figure 4.3.
Figure 4.3 Product-line approach
48
The process begins with a domain expert and a software architect working
together to develop a number of artefacts based on requirements for a
product-line. Artefacts include an ontology, workflows, architecture and list of
services that meet the requirements of various parts of the product-line. In
this context, all components are implemented by services that are either local
or distributed. MDA concepts are integrated into the approach to facilitate the
creation of OWL-S specifications.
Using output from the software architect and software domain expert,
software developers create the software needed to enable a production
capability for the product-line by developing infrastructure and the software
needed to map between the different services in the product-line architecture.
These mappings are dependent only on the ontologies for the domain and the
collaborations between services. Once a product-line framework or generator
is developed, a domain developer creates new products. In this scenario a
domain developer is not required to possess programming knowledge as the
act of product development is an activity of configuration of existing services.
4.3.6 Transformations between UML and OWL-S
Grønmo et al (2005) adopt the MDA strategy for developing compositions of
semantic Web services, and attempt to answer the question ‘How can the
new Semantic Web service proposals be utilized within a model-driven Web
service composition methodology?’. In response to this question, they
develop a UML profile for semantic Web services and transformations both
ways between UML and OWL-S. In support of these tools, they put forward
the following three-step approach derived from that of MDA.
49
Step one involves the specification of a new Web service composition in
UML, detailing a model defining the control and dataflow between tasks, each
having inputs and outputs. The UML model is semantically annotated using
appropriate domain ontologies. Based on these ontologies, step two is based
on locating services matching the semantic descriptions of those required.
Finally, step three involves the selection of the services to be used and
produces the concrete composition model for the newly composed service.
4.4 Integrated approach for prototype development
The MDA approach is based around the automated production of an
executable artefact through the process of modelling at increasingly finer
levels. As pointed out by Meservy et al (2005), UML is insufficiently rich for
the production of complete code. However, by utilisation of existing artefacts
described at a higher level of abstraction than code, the MDA approach has
been used to model composites of Web services to affectively produce
software artefacts through the generation of executable composite service
descriptions. In the light of this, and based on the examples presented above,
the following MDA based approach will be used for the production of the
prototype for this dissertation.
Step 1: Domain analysis will produce a series of structural and
dynamic UML representations of the problem domain that will reflect
the CIM defined in MDA
50
Step 2: The CIM will be taken and re-modelled within a software realm
to create a model reflective of the PIM within MDA. This model will
focus on the interaction of high-level software service components.
Step 3: Software will be developed to undertake the control and
dataflow between services, as defined by OWL-S specifications. The
software will be capable of interpreting OWL-S for this purpose.
Step 4: Individual component services will be manually built in
accordance with semantic descriptions output from step 2.
Step 5: The PIM will be transformed into OWL and OWL-S
specifications that are executable by the software developed in Step 3.
By adopting a product-line ethos behind the prototype, it is anticipated that
within a live environment, the development process would shift to that
described by Gannod et al, where ‘new’ software can be developed by
domain experts without the need of programming knowledge. Programming
knowledge would only be required in areas where new Web services are
required in support of the broader product-line.
4.5 Discussions and summary
This chapter has summarised the MDA and described current work
associated with integration of the MDA into a Semantic Web environment.
Based on current practice, a development process has been presented that
integrates the MDA with the Semantic Web for the purposes of building a
statistical elicitation tool. A number of predominantly conference and
51
workshop sources have been considered and a process of triangulation has
been used in order to provide a sound basis for the creation of a development
process.
Davis et al (2005) recognise that MDA is not yet deployable technology, and
Thomas (2004) fundamentally doubts its foundation. Frankel et al (2004) state
the benefit of integration of MDA with the Semantic Web. Timm et al (2005),
Gannod et al (2004) and Grønmo et al (2005) all corroborate one another on
the principle of transformation of UML into ontology languages, specifically
with OWL-S. Shen et al (2005) concur with the benefits of usage on the OWL-
S language through their work on transformation of BPEL4WS. Shen et al
(2005) and Knublauch (2004) both state the benefits of using people skilled in
the target domain to create systems from existing components. Schulz-Hofen
et al (2006) describe mechanisms to allow business users to create systems.
This chapter along with chapter 3 construct the conceptual framework of
stage one of the systems development research method described in chapter
2. The software engineering components for the conceptual framework stage
are requirements elicitation and requirements specification. These
components are documented in Appendix B together with the acceptance test
definition and system test definition. Appendix B pulls together all the
requirements developed through Chapters 1 to 4. With requirements
elicitation and requirements specification in place, chapter 5 moves forward
into development of a systems architecture and stage two of the systems
development research method.
52
Chapter 5 Development of System Architecture
5.1 Introduction
This chapter covers stage two of the systems development research method
and presents the investigation and selection of a systems architecture that
supports the integration of the Semantic Web and the MDA. The Semantic
Web encompasses a number of incumbent architectural properties that assist
in the selection of architectural components for the prototype. In compliance
with the Semantic Web, software agents or Web services will interact in a
manner specified in advance and detailed in the ontology language OWL-S.
These ontology process specifications will be an artefact used at runtime to
configure and instantiate a system in real time. Persistent domain data
required for the operation of the system will be similarly captured by ontology
specified using OWL.
The following sections review existing works to identify component
architectures and their integration to create the architecture for the prototype.
5.2 Three-tier architecture
The prototype will provide a series of user interfaces combining to create
persistent data. Three-tier architecture is a widely used pattern for this
scenario. Chen et al (2003) describe the three-tier architecture as a popular
method to achieve system robustness, flexibility and resistance to change.
The architecture consists of a user interface layer, an application logic layer
and a database layer as shown in Figure 5.1.
53
Figure 5.1 Three-tier architecture
Aarsten et al (1996) provides a pattern for the three-tier architecture. The
pattern’s context is development of large business applications, with many
users sharing data and operations on that data. The architecture is extremely
common, with technologies such as Java 2 Enterprise Edition and Microsoft™
.NET supporting the implementation of systems using the architecture
(Grundy et al (2004)). The popularity and support for this architecture
provides justification for its integration into this prototype. The concept of a
Web service for the prototype is one where each Web service will interact
with the user to manipulate data associated with the semantically defined task
delivered by the Web service component. This architecture therefore sits at
the very core of the prototype and is the fundamental architectural building
block for the prototype’s components.
5.3 Semantic Web architecture
Dai et al (2005) present an architectural solution for the use of multi-agent
technologies on Semantic Web resources. Agents are defined as
programmes that have both autonomous and social natures, with the ability to
act autonomously and proactively in order to accomplish tasks and process
requests. Within a multi-agent system, control of tasks and the tasks
54
themselves are distributed amongst agents. Antoniou (2004) describes the
components in a user’s interaction with the Semantic Web as depicted in
figure 5.2.
Figure 5.2 Semantic Web components
Antoniou (2004) describes a personal agent as receiving a request from a
user and subsequently distributing that request to a collection of intelligent
services that collaborate in answering the request through interaction with
Web resources. In this environment, the personal agent acts as a co-ordinator
for the collaboration of a selection of suitable agents to provide a composite
service capable of responding to the user’s request. Dai et al’s architectural
solution is comparative to Antonio’s components, and also exhibits influences
from of a three-tier architecture. A mapping of components of Dai et al’s
architectural solution to a three-tier architecture is shown in Figure 5.3.
55
Dai et al’s components are defined as follows. The Interface agent receives
user input and passes it to the coordination agent. The coordination agent
manages the user requests by breaking the request into tasks that are
allocated to the domain agents for execution in a planned order. The domain
agents receive instructions from the coordination agent and pass
queries/instructions to the Jena agent. The Jena agent and Jena middleware
combine to produce a system similar in context to a database management
system, with Jena utilising MySQL.
Figure 5.3 Transformation of Dai et al’s components to a three-tier
architecture
Dai et al’s websites and ontologies are external data resources and are not
mapped in Figure 5.3. The client component of the three-tier architecture
encapsulates the interface agent, which is responsible for presenting a
graphical user interface to the user. The application logic encapsulates the
coordination and domain agents and the Jena components are encapsulated
within the database server component of the three-tier architecture.
Client
Interface Agent
Coordination Agent
Application Logic
DomainAgent
DomainAgent
DomainAgent
Database Server
Jena Agent
Jena Middleware
Client
Interface Agent
Coordination Agent
Application Logic
DomainAgent
DomainAgent
DomainAgent
Database Server
Jena Agent
Jena Middleware
56
A key aspect of agent usage is one of service discovery, where the initial user
request, which has been broken down into component sub tasks, is then
matched to agents capable of delivering the sub tasks. With reference to
figure 5.3, this relates to the coordination agent selecting domain agents.
Research shows that the architecture for service discovery is reasonably
static. Buhler et al (2004) describe the architecture as consisting of three
basic components. A service broker maintains registers of semantically
described service advertisements. A service provider (Web Service/Agent)
offers a service that is advertised with a broker. Finally, a service requester
interrogates a broker to discover services matching the desired service
specifications and retrieves information from the broker that allows binding to
the providers. This architecture is depicted in figure 5.4.
Figure 5.4 Service discovery architecture
5.4 Distribution pattern
The use of Web services or agents implies a distributed architectural
environment. Barrett et al (2006) describes four examples of distribution
patterns, depicted in figure 5.5 and summarised below:
57
Figure 5.5 Example distribution patterns
• The hierarchical pattern is suitable for implementation in tiered
organisations where control hubs can be placed within tier levels
allowing delegation of processes to distinct sub trees. This pattern
is scalable through additional hubs but also exhibits a single point
of failure at the root hub
• The centralised pattern manages its composition through a single
location. This is the most widespread pattern, which is easy to
implement with low deployment overhead but suffers
communication bottlenecks at the central controller. The centralised
pattern is stated as most appropriate for a single enterprise
• The peer-to-peer pattern exhibits good scalability, availability and
performance but deployment overheads are high as is complexity
• The ring pattern enhances the centralised pattern through
introduction of clustering providing load balancing and high
58
availability where each participant provides exactly the same
functionality
The semantic Web architecture depicted in figure 5.3 shows likeness to the
centralised distribution pattern, with the controller agent undertaking the role
of the central controller. Similarly, the service discovery architecture in figure
5.4 also appears demonstrative of a centralised pattern, with the service
broker undertaking the central role. However, it would appear that the Web is
modelled on a peer-to-peer pattern, with heterogeneous services distributed
at a number of locations, all integrating to a service provided seamlessly in a
Web browser.
The distribution pattern of the Semantic Web architecture in figure 5.3 shows
the components at the point of collaboration, with one central component
clearly coordinating the remaining components. However, each component
when implemented within a Web environment is autonomous and
independently controlled, and only subject to a centralised pattern when
collaborating with other components to create a composite service. In this
manner the Semantic Web architecture demonstrates a hybrid peer-to-peer
model (Milojicic et al (2002)) which will be similarly incorporated into the
prototype.
5.5 Blackboard pattern
An issue with regards implementation of the Semantic Web architecture
depicted in figure 5.3 is one of communication between Web services. This
arises in terms of both data transferral from one Web service to another and
59
also storage of persistent data. Dai et al address the issue of persistence by
using a central database component. This is analogous to a blackboard
pattern where ‘sources make changes to the blackboard that lead
incrementally to a solution to the problem’ Shaw et al (1996). Kung et al
(2003) describe the blackboard mechanism as a useful way of sharing
information between agents, with the blackboard acting as a shared memory
between the agents. Yu et al (2004) further suggest that blackboards offer a
solution to the coordination problem between distributed agents, and
Helsinger et al (2004) describe the integration of a blackboard architecture
into Cougaar, a scalable, distributed multi-agent architecture.
Silva et al (2002) state that ‘the blackboard architectural pattern has been
widely used as a useful metaphor for communication and coordination of
heterogeneous and separately designed agent organizations’. Silva et al
believe that the blackboard pattern does not specify explicitly how the
controller component deals with distinct control strategies to manage the
blackboard. Furthermore, the pattern does not separate control strategies
from the application agents and data, leading to multi-agent architectures that
are difficult to maintain, understand and reuse. Therefore, they suggest an
integration of the Blackboard pattern with the Reflection pattern to create the
Reflective Blackboard pattern as depicted in figure 5.6.
In the Semantic Web architecture in figure 5.3, Silva et al’s pattern
components integrate as shown in figure 5.7. The figure shows Silva et al’s
Controller and MOP (Meta-Object Protocol) integrated into the coordination
agent.
60
Figure 5.6 Reflective Blackboard pattern
Figure 5.7 Semantic Web architecture with Reflective Blackboard pattern
5.6 Model View Controller pattern
The component coordination and domain agents associated with the
prototype will be required to interact with the human user, and therefore their
design needs to encapsulate a graphical user interface integrated with their
service offering. da Silva et al (2005) describe the use of the Model View
Controller (MVC) pattern within WebMode, a framework for developing
customisable educational Web applications. Both da Silva et al and Chen et
Client
Interface Agent
Coordination Agent
Application Logic
DomainAgent
DomainAgent
DomainAgent
Data
Blackboard
Client
Interface Agent
Coordination Agent
Application Logic
DomainAgent
DomainAgent
DomainAgent
Data
Blackboard
61
al (2002) identify the roots of the MVC in the Smalltalk language. MVC is
adopted by the Swing control, which is the foundation of all visual controls in
the Java 2 platform. The MVC architecture is also implemented in Microsoft™
.NET (Selfa et al (2006))
Chen et al describe the MVC architecture as composed of three elements, the
model, the view and the controller. The model represents the domain
information with which the application is concerned. The view encapsulates
the data to show to users and the controller deals with how the user interacts
with the view and the underlying model. The MVC pattern is depicted in figure
5.8.
Figure 5.8 MVC architecture
5.7 Integrated architecture for the prototype
Based on the selection of architectures above and in accordance with the
primary three-tier architecture, the components of the prototype will be as
follows:
62
The coordination and domain agents will each be based on an MVC pattern
incorporated into a three-tier architecture of presentation, business logic and
data layers. The data layers of the domain and coordination agents will be a
blackboard. The user will control the composite service (i.e. the statistical
elicitation tool) via the presentation layer of the coordination agent, which will
act as a portal wrapper to the domain agents’ presentation layer. This will be
achieved by integrating an html Iframe into the coordinating agent’s html
portal page as depicted in figure 5.9.
Figure 5.9 Presentation layer of the coordination agent
The business logic layer of the coordination agent will communicate with a
Web service broker to identify and bind to domain agents. Communication
with and hence control of agents will be via a blackboard. The blackboard will
manage both control and persistent data, storing the data in ontologies and
acting as the data layer of the overall three-tier architecture.
The prototype will exhibit a hybrid distribution pattern, with each component
capable of being hosted on separate servers.
User interaction frame component, incorporating import of OWL and OWL-S artefacts and process navigation
Iframe to encapsulate agent’s presentation layers
63
5.8 Summary
A key output from this stage of the systems development research method is
clearly defined requirements. The requirements for the system have evolved
over the course of preceding chapters and are laid out in Appendix B. This
chapter adds further requirements in terms of the architectural components of
the prototype. These are integrated with the requirements in Appendix B to
provide the requirements presented in table 5.1 below.
Table 5.1 Schedule of requirements for prototype
64
These requirements form the basis of validation of the software during the
evaluation of the prototype in chapter 7. The next step before evaluation is
the design of the system and this aspect is presented in the next chapter.
65
Chapter 6 Overview of System Design
This chapter presents the design activities undertaken in association with
stage three of the systems development research method. The input to this
stage constitutes the schedule of requirements, the architecture from chapter
5 and the prior activities of Domain Modelling and Specification Modelling
described in Appendices A and C. In accordance with the software
engineering approach, design is the elaboration of the Specification
Modelling.
Design commenced with the evaluation UML, OWL and OWL-S for the
purpose of transformation of the MDA’s platform independent models into
runtime artefacts. The next objective was to design the prototype’s
components defined in the Specification Model in a manner that supports the
integrated MDA approach described in Chapter 4. The overall design was
achieved via the following six-stage process:
• Stage One: Transformation of UML to OWL
• Stage Two: Transformation of UML to OWL-S
• Stage Three: Design Of Core OWL Classes
• Stage Four: Design of Core OWL-S Classes
• Stage Five: Database Design for Ontology Definitions and Instances
• Stage Six: Design Of Transformation Classes
• Stage Seven: Software Component (Agent) Design
These stages are described in the following sections.
66
6.1 Transformation of UML to OWL
Gaševic et al (2004) provided the basis for UML to OWL transformations.
Their work describes the use of extensible stylesheet language
transformation (XSLT) to transform a UML model in XMI (XML Metadata
Interchange) format into OWL. To achieve this they created an Ontology UML
Profile (OUP) and used it to produce models using the extensions to UML
defined by the OUP to create ontologies. They describe this process as
conforming to the MDA, as the OUP is compliant with the OMG’s MOF (Meta
Object Facility). MOF provides the facility to produce meta-models, which
describe models. Hence, the MOF is used to define UML, which is then
subsequently used to define the OUP.
The use of the OUP model constructs ensures that models resulting from its
use are composed of constructs that can be mapped to the target language,
OWL. By subsequently exporting the models to XMI format, the relevant OWL
constructs are in place to then employ XSLT to transform the models directly
into OWL artefacts. To undertake the XMI transformation, Gaševic et al used
the Poseidon UML modelling tool. The results of this exercise have been
inspected however they have not been replicated as Poseidon is a licensed
tool and no funding was available for its purchase.
Without Poseidon, Gaševic et al’s method could not be directly used for the
prototype. The static models were therefore created manually in Protégé,
which provides the facility to create static models similar to UML but directly
within an OWL development environment. The Jambalaya plug-in to Protégé
allowed the models to be viewed in a manner not too dissimilar from a UML
67
modelling tool such as Microsoft Visio. In practice, the UML static models
were created using Microsoft Visio and then transferred into Protégé by hand.
This was a reasonably simple exercise.
As with Gaševic et al, this manual mapping method required the production of
a UML profile for OWL to ensure that the modelling constructs used would
subsequently be supported in the manual mapping. Furthermore, complete
implementation of all the OWL constructs by the prototype would have been
too larger an undertaking for this dissertation. To resolve this, the strategy
developed was the definition of the components of OWL that would be
supported by the transformation process. By defining a restricted set of
constructs, the scope of class implementation to support OWL within the
prototype was subsequently reduced.
To establish the set of OWL constructs that the prototype would support
required the creation of UML static diagrams and their subsequent transferral
into Protégé to produce the OWL ontologies. Inspection of the resulting OWL
constructs provided the definition of which constructs would require support.
This was an iterative process that began with fairly simplistic UML models
and concluded with the transformation into OWL of the static UML model from
the Domain Modelling provided in Appendix A.
As with Gaševic et al, a UML meta-model, or profile, of the supported features
of OWL was produced, and this is presented in figure 6.1. This is adapted
from Brockmans et al (2004) with the inclusion of the class Schema and the
IsSubclassOf association. The Schema class allows references to classes in
external OWL ontologies to be made. The IsSubClassOf association allows
68
generalisations of classes to be expressed and the cardinalities allow
consistency checks to be made on instantiations of ontologies. The UML
meta-model forms the base class structure required to instantiate the OWL
ontologies in the target implementation language for the prototype, C#.
-ClassName : stringOWLClass
-functionalPropertyName : string-type : string
FunctionalProperty
-objectPropertyName : stringObjectProperty
1
*HasDomain
1
*
IsSubClassOf
-schemaName : stringSchema
1
*
HasClasses
-minCardinality : int-maxCardinality : int
HasRange
1 *DatatypeProperty
DataRange
1
*
Range
Figure 6.1 UML Profile of supported OWL constructs
6.2 Transformation of UML to OWL-S
With OWL-S being a more recent development than OWL, practical examples
of transformation of UML to OWL-S were somewhat more difficult to locate.
Timm et al (2005) and Gannod et al (2004) both describe a method for
transformation similar to Gaševic et al (2004). They again use UML profiles to
model various OWL-S constructs in conjunction with the UML static diagram.
On this basis, a similar method has been used for the prototype that complies
with the method described for OWL above.
69
The same strategy of defining supported OWL-S constructs was used,
facilitated by the Protégé tool. Initially a familiarisation exercise was
undertaken. This comprised of developing some fairly simplistic OWL-S
process descriptions and reviewing the resultant OWL-S artefacts produced.
These were related back to the OWL-S specification. This process identified
that the relationship between OWL and OWL-S is similar to the MDA’s MOF
and UML.
OWL provides a series of constructs and OWL-S uses these to define a meta-
model capable of describing behavioural processes. Once this was realised
the ‘Process’ OWL ontology, which provides partial specification of OWL-S,
was analysed to identify the OWL-S constructs that would require
implementation in the prototype to support the elicitation method. These were
constructed into a UML static diagram as shown in figure 6.2. The supported
OWL-S constructs allow the definition of a single composite process based on
the integration of a sequence of atomic processes, which matches the
complexity of the intended implementation of the prototype. The diagram
provides a UML profile for OWL-S allowing the definition of processes to be
described using a UML static diagram.
6.3 Design of core OWL classes
With the supported OWL and OWL-S constructs in place, work continued with
the design of software classes for their instantiation. This commenced with
development of the design for the OWL classes. The UML static diagram
provided in figure 6.3 shows the configuration of classes, attributes and
methods to support the selected OWL constructs. The classes are designed
70
to allow an ontology definition described by an OWL artefact to be parsed into
a series of runtime objects reflective of the ontology schema.
-ID : stringProcess
-ID : stringControlConstruct
AtomicProcess
-ID : string-toParam : Parameter-valueSource : ValueOf
Binding
-ID : string-type : string
Parameter
-ID : string-theVar : Parameter-fromProcess : Perform
ValueOf
-first : ControlConstruct-rest : ControlConstructList
ControlConstructList
-ID : stringList
-process : ProcessPerform
-composedOf : ControlConstructCompositeProcess
-first : ControlConstruct-rest : ControlConstructBag
ControlConstructBag
Input Output
InputBinding OutputBinding
Produce
-components : ControlConstructListSequence
*
1
HasParameter
1*
HasOutput1
*
HasInput
1
*
HasDataFrom
1
*
HasOutpuBindings
Figure 6.2 UML Profile of supported OWL-S constructs
With OWL being an XML based language, the design process recognised that
a series of builder classes would be required to instantiate the core OWL
schema classes. In accordance with the blackboard architecture, the
prototype loads the ontology schema into persistent storage provided by a
database management system (DBMS). The classes associated with
achieving this are described in section 6.6.
71
Figure 6.3 UML static diagram of OWL Schema classes
6.4 Design of core OWL-S classes
As with the OWL, the design for the OWL-S core classes to instantiate and
OWL-S specification were developed based on the UML profile for OWL-S
developed above. The resultant UML static diagram for the classes, attributes
and methods is presented in figure 6.4.
72
+AddParameter() : void+AddInput() : void+AddOutput() : void+GetParameterList() : ArrayList+GetInstanceList() : ArrayList+GetOuputList() : ArrayList
-ID : string-hasParameter : ArrayList-hasInput : ArrayList-hasOutput : ArrayList
OWLS_Classes::Process
C# Helper::ArrayList
+GetID() : string-ID : stringOWLS_Classes::ControlConstruct
OWLS_Classes::AtomicProcess
+SetToParam() : void+SetValueOf() : void+GetID() : string+GetToParam() : Parameter+GetValueSource() : ValueOf
-ID : string-toParam : Parameter-valueSource : ValueOf
OWLS_Classes::Binding
+GetID() : string+SetParameterID() : void+GetParameterType() : string+SetParameterType() : void
-ID : string-type : string
OWLS_Classes::Parameter
+SetFromProcess() : void+SetTheVar() : void+GetFromProcess() : Perform+GetTheVar() : Parameter+GetID() : void
-ID : string-theVar : Parameter-fromProcess : Perform
OWLS_Classes::ValueOf
+SetFirst() : void+SetRest() : void+GetFirst() : ControlConstruct+GetRest() : ControlConstructList
-first : ControlConstruct-rest : ControlConstructList
OWLS_Classes::ControlConstructList
+GetID() : string-ID : stringOWLS_Classes::List
+AddHasDataFrom() : void+GetHasDataFrom() : ArrayList+GetProcess() : Process+SetProcess() : void
-process : Process-hasDataFrom : ArrayList
OWLS_Classes::Perform
+SetComposedOf() : void+GetComposedOf() : ControlConstruct
-composedOf : ControlConstructOWLS_Classes::CompositeProcess
+SetFirst() : void+SetRest() : void+GetFirst() : ControlConstruct+GetRest() : ControlConstructBag
-first : ControlConstruct-rest : ControlConstructBag
OWLS_Classes::ControlConstructBag
OWLS_Classes::InputOWLS_Classes::Output
OWLS_Classes::InputBinding
OWLS_Classes::OutputBinding
+GetOutputBindings() : ArrayList+AddOutputBinding() : void
-outputBindings : ArrayListOWLS_Classes::Produce
+SetComponents() : void+GetComponents() : ControlConstructList
-components : ControlConstructListOWLS_Classes::Sequence
+SetComponents() : void+GetComponents() : ControlConstructBag
-components : ControlConstructBagOWLS_Classes::SplitJoin
Figure 6.4 UML static diagram of OWL-S schema classes
6.5 Database design for ontology definitions and instances
In accordance with the Blackboard architecture, a DBMS was selected as the
preferred means of persistent data storage. This decision is compliant with
the system architecture as DBMS’s exhibit three-tier architecture. Within a
Web environment, instances of classes are not themselves persistent. When
calling a Web page, instances of classes are only created for the duration that
73
the Web server takes to provide the page request. A DBMS provides a
popular method of recreating class instances on Web page requests.
The database had to be capable of accepting any ontology schema described
in OWL within the boundaries of the supported constructs. With the supported
OWL-S profile being a profile of supported OWL, the OWL-S schema
inherently has the capacity to be stored in the DBMS as any other OWL
ontology schema. The database schema in support of the OWL profile is
provided in figure 6.5.
Figure 6.5 DBMS schema supporting OWL Profile
Having established a storage mechanism for OWL schemas, a generic design
was required for the storage of instances of those schemas. With OWL, this
refers to say the storage of book titles in a manner described by a book
ontology. In relation to OWL-S, this refers to the storage of specific composite
74
processes, atomic processes and other aspects specific to a particular
instantiated process. The database schema allowing storage of instances
data from any supported OWL or OWL-S artefact is provided in figure 6.6.
Figure 6.6 DBMS schema for storage of instance data
6.6 Design of transformation classes
The prototype needs to instantiate the OWL and OWL-S classes defined in
sections 6.3 and 6.4 from OWL and OWL-S artefacts created from the
transformation from UML static diagrams. With OWL and OWL-S both being
XML based languages, this requires the parsing of XML into objects
instantiated from these classes. Supporting this process requires a series of
helper classes to allow the objects created to be persistently stored in the
75
DBMS. Furthermore, a series of classes are required to facilitate capture of
instance data and its subsequent storage in the DBMS.
The design of this aspect has been split between OWL and OWL-S, with
unique supporting classes designed for each. OWL provides the simpler
design and is considered first. A UML static diagram of the classes
associated with the OWL transformation is provided in figure 6.7. Here the
class OWLParser handles the parsing of OWL artefacts, instantiating objects
based on the core OWL classes as it proceeds. References to the objects
created are stored in collection attributes associated with the OWLParser
class.
The BuildSQLSchema class instantiates the OWLParser class. The
BuildSQLSchema creates objects from the SQL classes. The SQL classes
reflect the OWL core classes and instantiate the OWL schema components
as persistent objects in the DBMS. Each object created from these SQL
classes is referenced by collection attributes associated with the
BuildSQLSchema class. This provides the facility to map the objects created
from the core OWL classes to their SQL counterparts.
The class structure for the implementation of OWL-S is significantly more
complex in order to support the OWL profile for OWL-S. Here, individual build
classes are created for each OWL-S concept, each responsible for parsing an
OWL-S artefact for the components of a specific OWL-S class. The UML
static model for the resultant classes is provided in figure 6.8.
76
+OWLParser() : OWLParser+GetSchemaName() : void-BuildOWLClasses() : void-BuildOWLSubClasses() : void-AddOWLClass() : void-AddRemoteOWLClass() : void-AddOWLSubClass() : void-BuildObjectProperties() : void-AddObjectProperty() : void-BuildFunctionalProperties() : void+AddFunctionalProperty() : void+BuildCardinalities() : void+GetOwlClasses() : Hashtable+GetObjectProperties() : Hashtable+GetFunctionalProperties() : Hashtable+GetFunctionalProperty() : FunctionalProperty+GetObjectProperty() : ObjectProperty+GetOWLClass() : OWLClass
-owlClasses : Hashtable-functionalProperties : Hashtable-objectProperties : Hashtable-schemaName : string
OWLParser
+BuildSQLSchema() : BuildSQLSchema+GetSqlOwlClasses() : Hashtable-SetSqlOwlClasses() : void+SetSqlFunctionalProperties() : void+SetSqlObjectProperties() : void+SetSqlHasDomains() : void+SetSqlHasRanges() : void
-owlParser : OWLParser-owlClasses : Hashtable-functionalProperties : Hashtable-objectProperties : Hashtable-sqlSchema : SQLSchema-sqlOWLClasses : Hashtable-sqlFunctionalProperties : Hashtable-sqlObjectProperties : Hashtable-sqlHasDomains : Hashtable-sqlHasRanges : Hashtable
BuildSQLSchema
+SQLSchema() : SQLSchema+GetID() : int+GetSchemaName() : string+SetID() : void+SetSchemaName() : void
-ID : int-schemaName : string
SQLSchema
1
1HasOWLParser
+SQLEntity() : SQLEntity
-connection : SQLConnection-command : SQLCommand
SQLEntity
SQLConnection SQLCommand
+SQLFunctionalProperty() : SQLFunctionalProperty+GetID() : int+GetFunctionalPropertyName() : string+GetDomainOwlClass() : string+GetFPType() : string+GetRange() : string+GetRangeSchemaName() : string+SetID() : void+SetFunctionalPropertyName() : string+SetDomainOwlClass() : string+SetType() : void+SetRange() : void+SetRangeSchemaName() : void
-ID : int-functionalPropertyName : string-domainOWLClass : int-type : string-range : string-rangeSchemaName : string
SQLFunctionalProperty
+SQLHasDomain() : SQLHasDomain+GetID() : int+GetObjectPropertyID() : int+GetDomainClassID() : int+SetID() : void+SetObjectPropertyID() : void+SetDomainClassID() : void
-ID : int-objectPropertyID : int-domainClassID : int
SQLHasDomain
+SQLHasRange() : SQLHasRange+GetID() : int+GetSchemaName() : string+GetObjectProperty() : string+GetRangeClass() : string+GetRangeSchemaName() : string+GetMinCardinality() : int+GetMaxCardinality() : int+SetID() : void+SetSchemaName() : void+SetObjectProperty() : void+SetRangeClass() : void+SetRangeSchemaName() : void+SetMinCardinality() : void+SetMaxCardinality() : void
-ID : int-schemaName : string-objectProperty : string-rangeClass : string-rangeSchemaName : string-minCardinality : int-maxCardinality : int
SQLHasRange
+SQLObjectProperty() : SQLObjectProperty+GetID() : int+GetObjectPropertyName() : string+SetID() : void+SetObjectPropertName() : void
-ID : int-objectPropertyName : string-schemaName : string
SQLObjectProperty
+SQLOWLClass() : SQLOWLClass+GetID() : int+GetOwlClassName() : int+SetID() : void+SetOwlClassName() : void
-ID : int-owlClassName : string-schemaName : string
SQLOWLClass
*
1
*
1
*
1
*
1
*
1
*
1
Figure 6.7 OWL Instantiation and DBMS classes
77
+BuildClass()+MoveToTargetClassNode() : void+GetActualNode() : void+GetNodeName() : string+AddParentReleationship() : void
-builtClasses : OWLSCollection-mainNav : XPathNavigator-targetNav : XPathNavigator-tempNav : XPathNavigator-myXPathDocument : XPathDocument-fullName : string-targetName : string-gotNode : bool-ID : string-type : string
OWLS_Build::BuildClass
C# Helper::XPathNavigator
OWLS_Classes::OWLSCollection
C# Helper::XPathDocument
+AtomicProcessBuild()+GetInstance() : AtomicProcess
-atomicProcess : AtomicProcess-hasInput : InputBuild-hasOutput : OutputBuild
OWLS_Build::AtomicProcessBuild
+InputBuild()+GetInstance() : Input
-input : InputOWLS_Build::InputBuild
+OutputBuild()+GetInstance() : Output
-output : OutputOWLS_Build::OutputBuild
+CompositeProcessBuild()+GetInstance() : CompositeProcess
-hasInput : InputBuild-hasOutput : OutputBuild-sequenceBuild : SequenceBuild-performBuild : PerformBuild
OWLS_Build::CompositeProcessBuild
+ControlConstructBagBuild()+GetInstance() : ControlConstructBag
-ccb : ControlConstructBag-first : ControlConstruct-rest : List-ccbB : ControlConstructBagBuild-cclB : ControlConstructListBuild-sequenceBuild : SequenceBuild-performBuild : PerformBuild
OWLS_Build::ControlConstructBagBuild
+ControlConstructListBuild()+GetInstance() : ControlConstructList
-ccl : ControlConstructList-first : ControlConstruct-rest : ControlConstructList-ccbB : ControlConstructBagBuild-cclB : ControlConstructListBuild-sequenceBuild : SequenceBuild-performBuild : PerformBuild
OWLS_Build::ControlConstructListBuild
+InputBindingBuild()+GetInstance() : InputBinding
-inputBinding : InputBinding-inputBuild : InputBuild-valueOfBuild : ValueOfBuild
OWLS_Build::InputBindingBuild
+OutputBindingBuild()+GetInstance() : Output
-outputBinding : OutputBinding-outputBuild : OutputBuild-valueOfBuild : ValueOfBuild
OWLS_Build::OutputBindingBuild
+ParameterBuild()+GetInstance() : Parameter
-parameter : ParameterOWLS_Build::ParameterBuild
+PerformBuild()+GetInstance() : Perform
-perform : Perform-cpb : CompositeProcessBuild-apb : AtomicProcessBuild-ipb : InputBindingBuild
OWLS_Build::PerformBuild
+ProduceBuild()+GetInstance() : Produce
-produce : Produce-opbb : OutputBindingBuild
OWLS_Build::ProduceBuild
+SequenceBuild()+GetInstance() : Sequence
-sequence : Sequence-cclb : ControlConstructListBuild
OWLS_Build::SequenceBuild
+SplitJoinBuild()+GetInstance() : SplitJoin
-splitJoin : SplitJoin-ccbb : ControlConstructBagBuild
OWLS_Build::SplitJoinBuild
+ValueOfBuild()+GetInstance() : ValueOf
-valueOf : ValueOf-fromProcessBuild : PerformBuild-theVarInBuild : InputBuild-theVarOutBuild : OutputBuild
OWLS_Build::ValueOfBuild
+OWLSParser() : OWLSParser-owlsCollection : OWLSCollection
OWLS_Build::OWLSParser
1
1
+SQLOWLSBuild() : SQLOWLSBuild+CreateOWLSSQLInstances() : void
OWLS_Build::SQLOWLSBuild
Figure 6.8 OWL-S instantiation classes
The OWLSParser class initiates an XML navigator to locate either the first
instance of a CompositeProcess, or if none exists then the first instance of an
AtomicProcess. Once located, the relevant build class is instantiated. Each
build class inherits from the superclass BuildClass which contains methods
for parsing the OWL-S artefact. Each build class is specialised to handle the
instantiation of each OWL-S concept, calling other build classes as necessary
78
to instantiate its OWL-S core properties. The build classes maintain a single
collection of OWL-S core classes to allow access to all the instantiated OWL-
S core objects. This collection is accessed by the SQLOWLSBuild class
responsible for instantiating the OWL-S core objects on the DBMS.
6.7 Software component (Agent) design
This section describes the design of the six Web service components derived
from Chapter 5, which collaborate together to create the functionality of the
prototype. In addition to these components, there are some additional design
concepts that facilitate their collaboration and the integrated use of OWL-S at
runtime. The first of these concepts is communication. With a prototype
already integrating closely with ontology, a shared ontology for
communication has been designed. This is presented in figure 6.9
-agentName : string-Process : string-isReady : bool-isStarted : bool-isComplete : bool
Communication
+AddParameter() : void+AddInput() : void+AddOutput() : void+GetParameterList() : <unspecified>+GetInstanceList() : <unspecified>+GetOuputList() : <unspecified>
-ID : string-hasParameter-hasInput-hasOutput
Process
1 0..1
SupportsProcess
Figure 6.9 Communication ontology
The objective of the Communication classes is to manage the services of
each prototype Web service. All communication between agents is routed via
the blackboard agent. When the agent registers with the blackboard, an
instance of the communication class is created for that agent and persisted
on the DBMS. Each agent contains a class to manage this communication
instance.
79
The second design concept is introduced to support OWL-S. OWL-S requires
inputs to and outputs from processes to be encapsulated by instances of
classes. This requires the development of helper ontologies that encapsulate
the required input and output classes for each OWL-S process. These helper
ontologies provide the benefit of allowing semantic consistency checks to be
made on objects instantiated by processes. These checks evaluate
successful completion of individual processes.
With these two design concepts in place, the design of the Web services is
now discussed. Not all the Web services have been implemented for the
prototype, with only those necessary to demonstrate the integrated MDA
approach being created. Those Web services not implemented have either
been replaced by stubs or, in the case of the graphical data agent, replaced
by an alternative agent.
6.7.1 Service Broker
The service broker is designed as a stub. The stub returns the URL of a Web
service when passed a process name. In the Semantic Web, the Service
Broker would not only maintain a directory of Web services but also provide
some form of matchmaking service. This agent is required for a fully
implemented system, but it does not affect the integrated MDA approach
being assessed.
6.7.2 Blackboard
The blackboard agent provides an interface to the DBMS, presenting
methods for communication and data transfer. The blackboard agent
80
implements all the OWL and OWL-S classes described in sections 6.3
through to 6.6, and is based on three-tier architecture. The blackboard
provides a wrapper to a database Web service that exposes the DBMS’s
stored procedures for access via SOAP calls. The blackboard includes
classes for communication with agents and also for checking consistency of
instance data instantiated in the DBMS. The classes, attributes and methods
for this component are provided in figure 6.10.
6.7.3 Coordination Agent
The coordination agent is inherently based on the MVC architecture, as the
target implementation platform is ASP.NET. The agent also exhibits three-tier
architecture. The coordination agent provides an IFrame for presentation of
other agents’ user interfaces to the system user. The coordination agent
includes the OWL-S classes from section 6.4. The remaining classes,
attributes and methods for this component are provided in figure 6.11.
6.7.4 Ontology Data Agent
The ontology data agent handles the creation of instances within ontologies.
The agent demonstrates both MVC and three-tier architectures. The agent
presents an interface to the user that is configured at runtime to reflect the
ontology class’s defined attributes for capture of an instance of the class. The
agent allows create, read, update and delete activities to be performed. The
agent permits the user to advise when data collation activities are complete.
The classes, attributes and methods for this component are provided in figure
6.12.
81
Figure 6.10 UML static diagram of top-level Blackboard classes
+GetOWLClassCollection() : DataSet+GetOWLClassCollectionParam() : DataSet+GetClassCollection() : DataSet+GetClassCollectionParam() : DataSet+GetEntityCollection() : DataSet+GetEntityCollectionParam() : DataSet+GetInstanceCollection() : DataSet+GetInstanceCollectionParam() : DataSet+DeleteInstance() : DataSet+AddInstance() : DataSet+AddInstanceAssociation() : DataSet+GetParentCollection() : DataSet+GetParentCollectionParam() : DataSet+GetSchemaCollection() : DataSet+GetValueTypeCollection() : DataSet+GetValueTypeCollectionParam() : DataSet+LoadOWL() : void+LoadOWLS() : void+GetClassSchemaParam() : DataSet+GetOWLSItem() : string+GetOWLSPerform() : string+CheckComplete() : bool+Register() : void+CompleteService() : bool+QuitSession() : void
Blackboard
C# Helper::DataSet
+OWLSProcess()+GetProcessDescription() : string+ControlConstruct() : void+Perform() : void+InputBinding() : void+ValueOf() : void+OutputBinding() : void+Parameter() : void+Input() : void+Output() : void+AtomicProcess() : void+CompositeProcess() : void+Sequence() : void+Produce() : void+ControlConstructList() : void+ControlConstructBag() : void+GetPerform() : int+GetPerforms() : Hashtable
-resultText : short-comp-htb : Hashtable-performCount : int
Process::OWLSProcess
+OWLSParser() : OWLSParser+GetOWLSCollection() : OWLSCollection+GetCompositeProcess() : CompositeProcess
-owlsCollection : OWLSCollection-comp : CompositeProcess
Parser::OWLSParser
DBEntityCollection
+ClassCollection()
Instances::ClassCollection
+ClassSchema()
Instances::ClassSchema
+EntityCollection()
Instances::EntityCollection
+InstanceCollection()
Instances::InstanceCollection
+OWLClassCollection()
Instances::OWLClassCollection
+ParentCollection()
Instances::ParentCollection
+SchemaCollection()
Instances::SchemaCollection
+ValueTypeCollection()
Instances::ValueTypeCollection
+SQLInstance()+GetUniqueId() : int+SetUniqueId() : void+GetParentID() : int+SetParentID() : void+GetSchemaID() : int+SetSchemaID() : void+GetEntity() : string+SetEntity() : void+GetSchemaDomainName() : string+SetSchemaDomainName() : void+GetMvalue() : string+SetMvalue() : void+GetValueType() : string+SetValueType() : void+Delete() : bool+Save() : bool
-uniqueId : int-parentID : int-schemaID : int-entity : string-schemaDomainName : string-mvalue : string-valueType : string
SQLIndividual::SQLInstance
+SQLInstanceAssociation()+GetID() : int+SetID() : void+GetParentID() : int+SetParentID() : void+GetChildID() : int+SetChildID() : void+Delete() : bool+Save() : bool
-id : int-childID : int-parentID : int
SQLIndividual::SQLInstanceAssociation
+SQLEntity() : SQLEntity
-connection : SQLConnection-command : SQLCommand
SQLIndividual::SQLEntity
+BuildSQLSchema() : BuildSQLSchema+GetSqlOwlClasses() : Hashtable-SetSqlOwlClasses() : void+SetSqlFunctionalProperties() : void+SetSqlObjectProperties() : void+SetSqlHasDomains() : void+SetSqlHasRanges() : void
-owlParser : OWLParser-owlClasses : Hashtable-functionalProperties : Hashtable-objectProperties : Hashtable-sqlSchema : SQLSchema-sqlOWLClasses : Hashtable-sqlFunctionalProperties : Hashtable-sqlObjectProperties : Hashtable-sqlHasDomains : Hashtable-sqlHasRanges : Hashtable
Builds::BuildSQLSchema
82
Figure 6.11 UML static diagram of Coordination Agent classes
6.7.5 Graphical Data Agent
The graphical agent is a key component in Proposed M801 Topic (2005).
However, in the context of the integrated MDA approach the graphical data
agent merely replicates the configuration for data capture provided by the
ontology data agent. The agent is replaced during implementation with a copy
of the ontology data agent.
6.7.6 Statistical Agent
Statistical analysis is a key component of Al-Awadhi et al’s (2006) statistical
elicitation technique. For the purposes of the prototype however, the
statistical agent is implemented as a stub. When requested to undertake a
process, the agent provides an html page stating the process is complete.
-Page_Load() : void-btnRegister_Click() : void-btnOWL_Click() : void-btnStart_Click() : void-btnOWLS_Click() : void-btnNext_Click() : void-btnQuit_Click() : void
-strBlackboard : string-session : string-agent : string-url : string-service : string-currentProcess : string
CoordinationAgent
83
Figure 6.12 UML static diagram of Ontology Data Agent classes
+WSClassCollection()+GetrtDS() : DataSet
-rtDS : DataSetWSClassCollection
C# Helper::DataSet
+Page_Load() : void+btnAddTextBox_PreRender() : void+btnAddTextBox_Click() : void+CreateTextBoxControls() : void+btnSubmitButton_Click() : void+btnSubmitButton_PreRender() : void+btnReset_Click() : void+ddlparentID_SelectedIndexChanged() : void+ddlSchema_SelectedIndexChanged() : void+SetParents() : void+SetSchema() : void+GetPropertyName() : string+GetPropertyType() : string+GetPropertyControl() : string+GetPropertyCount() : int+GetInstanceDS() : DataSet+SaveInstance() : int+SaveInstanceAssociation() : void+ddlClassName_SelectedIndexChanged() : void+dgEntries_PageIndexChanged() : void+dgEntries_ItemCommand() : void+btnComplete_Click() : void
-ds : DataSet-strBlackboard : string-session : string-agent : string-url : string-service : string
DataAgent::DataAgent
+WSClassSchema()+GetrtDS() : DataSet
-rtDS : DataSetWSClassSchema
+WSInstance()+ID()+ParentID()+SchemaID()+Entity()+SchemaDomainName()+Mvalue()+ValueType()+Save()
-id : int-parentID : int-schemaID : int-entity : string-schemaDomainName : string-mvalue : string-valueType : string-rtDS : DataSet
WSInstance
+WSInstanceAssociation()+ID()+ParentID()+ChildID()+Save()
-id : int-parentID : int-childID : int
WSInstanceAssociation
+WSInstanceCollection()+GetrtDS() : DataSet
-rtDS : DataSetWSInstanceCollection
+WSParentCollection()+GetrtDS() : DataSet
-rtDS : DataSetWSParentCollection
+WSSchemaCollection()+GetrtDS() : DataSet
-rtDS : DataSetWSSchemaCollection
84
6.8 Summary
This chapter has provided an overview of the design based on the output
from the development of the system architecture from chapter 5. Where
appropriate, deviation by the design from both the architecture and the
integrated MDA approach has been identified. The full design is presented in
Appendix D. After design, the prototype was implemented, and chapter 7
continues with the evaluation of the result.
85
Chapter 7 Results
This chapter reviews the prototype against the requirements developed over
chapters 1 to 5. Firstly, the deployment of the Al-Awadhi et al’s (2006)
elicitation method within the prototype is described. The deployment is then
evaluated against each requirement in turn and the results from this exercise
are used to establish to what extent the prototype answers the research
question. A qualitative approach is used.
7.1 Deployment of elicitation method
The coordination, data, service broker, statistical and blackboard agents were
uploaded onto a Web server and the database instantiated on the DBMS.
Three separate Web sites were created using the data agent. Each of these
corresponded with a separate atomic process. The service broker was
configured to retrieve the relevant agent’s URL on request of the name of an
atomic process.
The UML Static domain model for survey specification, data capture and
elicitation was elaborated into two static UML diagrams. The first of these
constituted specification and data collection, the second the process of
elicitation. These artefacts were manually transformed into OWL using the
Protégé tool, with the resultant models verified against the UML models using
Protégé’s Jambalaya plug-in. By splitting the schemas in two, the prototype’s
capability to reference between ontology schemas was verified.
86
An ancillary UML static diagram was created in support of the inputs and
outputs from each of the atomic processes designed for the elicitation
process. The OWL file was created as above. The OWL-S specification for
the elicitation process was also created using Protégé (figure 7.1). The
resultant OWL and OWL-S files were uploaded onto a Web server. With
these runtime artefacts in place, the coordination agent was accessed to
manage the collaboration of agents in undertaking the elicitation process.
Figure 7.1 OWL-S Elicitation process
87
In the first instance, the user registered the coordination agent with the
blackboard agent. The coordination agent provides a user interface for
entering URLs of both OWL ontologies and OWL-S process specifications
(figure 7.2). The user provided each of the OWL ontology URLs for data
collection, elicitation and inputs/outputs for the atomic processes to the
coordination agent. These were passed to the blackboard agent, which
accessed and parsed the files into the DBMS. Then the URL for the OWL-S
process specification was provided to the coordination agent, which was
passed to the blackboard agent for processing in the same manner.
Figure 7.2 Coordination agent interface
88
The blackboard agent abstracted the process from the OWL-S specification
and passed a textural representation of the process back to the coordination
agent. The user then started the OWL-S process from the ‘Start’ button. This
action retrieved the first atomic process name from the blackboard which was
passed to the service broker to retrieve the URL of the relevant data agent.
The coordination agent loaded the data agent into its Iframe by passing the
data agent a URL with parameters. The parameters passed included the
name of the atomic process to be processed and the URL of the blackboard
agent. On opening, the data agent registered with the blackboard using the
URL parameter passed to it.
The data collation agent communicated with the blackboard agent to retrieve
class specifications for building its user interface controls to capture each
required object. The user entered data to instantiate objects of each required
class (figure 7.3). The data ontology agent passed the class objects to the
blackboard agent to instantiate them within the database. The data ontology
agent handled the user’s requests to create, read, update and delete
instances of the survey ontology by communication with the blackboard
agent.
When complete, the user clicked the ‘Click When Complete’ button on the
data agent. This would allow for the blackboard agent to undertake schema
consistency checks and verify that the atomic process is complete. The user
then clicked the ‘Next Process’ button on the coordination agent. The
coordination agent verified the current atomic process status as complete via
the blackboard agent and retrieved the name of the next atomic process. This
89
was passed to the service broker, which responded with the URL of the next
required data agent. The coordination agent loaded the relevant data agent,
which subsequently registered with the blackboard agent. The user then
proceeded to enter survey collation data.
Figure 7.3 Data agent interface
This process was repeated for all the cycles of data gathering. Once data
gathering was complete, the coordination agent retrieved the URL of the
statistical agent and presented it in its Iframe. The statistical agent,
implemented as a stub, informed the user that the elicitation was complete.
7.2 Conformity to requirements
This section evaluates the prototype against the requirements developed over
the course of the dissertation.
90
7.2.1 Collection of data described by any UML static diagram
Chapter 6 provided a UML profile for OWL that allows transformation of UML
diagrams based on the profile to be transformed into OWL artefacts. This
profile limits the constructs that are supported both within UML and in OWL
itself. Therefore, the prototype is not capable of collecting data from ‘any’
UML static diagram. In addition to this, there is a further complication. The
use of the UML profile for OWL constrains a user by having to create UML
diagrams in a manner suited to OWL. This requires the user to have some
knowledge of the OWL constructs in order to produce compliant diagrams.
In practice a method was adopted where UML diagrams were developed
without using the profile, with diagrams limited to the following UML
constructs:
• Classes. Classes are fully supported
• Generalisation. Generalisation is supported
• Attributes. Attributes are supported
• Binary Associations. Associations are partially supported within the
constraints of multiplicity
• Multiplicity. Multiplicity is supported in 0.1: * associations
• Association Classes. The require elaboration to binary associations
Within these limitations, the prototype is highly flexible in its capacity to
handle wide ranges of data ontologies and was configurable within the
constraints of the supported OWL constructs.
91
7.2.2 Specification of system behaviour by UML
The prototype was again limited by the depth of OWL-S constructs supported,
which provided only sequential implementation of atomic processes. The
UML to OWL-S issues were significantly more apparent than for UML to
OWL. The UML OWL-S profile developed was based on UML static diagrams
that are somewhat abstract from behavioural modelling. This put even more
emphasis on the user to understand the OWL-S language, and the usage of
the UML OWL-S profile was dropped. In practice the OWL-S process
specifications were developed directly in OWL-S using the Protégé tool.
7.2.3 Extendible by new components
All the agents aside from the coordination agent were integrated to create a
system at runtime. The system did not require knowledge of any component
before system instantiation. Therefore, the prototype can cater for being
extended with new components.
7.2.4 Interpretation of OWL schemas for instantiation of instances
Within the constraints of the supported OWL constructs, the prototype
provided the ability to parse an OWL file to instantiate its schema within a
DBMS. The data ontology agent was able to read the incumbent class
specifications and permit instantiation of instance of classes through a
dynamic user interface configured in accordance with OWL schemas at
runtime.
92
7.2.5 Interpretation of OWL-S process specifications at runtime
Again, within the constraints of the supported OWL-S constructs, the
prototype demonstrated the capability to interpret OWL-S process
specifications at runtime. Furthermore, the prototype showed the ability to
instantiate the processes by coordinating the collaboration of agents in order
to undertake the described process.
7.2.6 Compliance to the integrated MDA approach
i. Step 1: Domain analysis will produce a series of structural and
dynamic UML representations of the problem domain that will reflect
the CIM defined in MDA
Domain analysis was undertaken with both structural and dynamic
UML diagrams produced describing the problem domain. These are
included in Appendix A.
ii. Step 2: The CIM will be taken and re-modelled within a software realm
to create a model reflective of the PIM within MDA. This model will
focus on the interaction of high-level software service components
together their semantic descriptions.
Specification modelling was undertaken which took the domain
modelling as its input and resulted in the creation of UML models
reflecting the interaction of high-level software service components.
However, the components are not semantically described using OWL
or OWL-S.
93
iii. Step 3: Software will be developed to undertake the control and
dataflow between services, as defined by OWL-S specifications. The
software will be capable of interpreting OWL-S for this purpose.
As described above, this aspect has been achieved within the
constraints of the OWL-S supported constructs.
iv. Step 4: Individual component services will be manually built in
accordance with semantic descriptions output from step 2.
An overview of the design is provided in chapter 7 supported by detail
design information provided in Appendix D. The prototype’s component
services were built in accordance with these documents.
v. Step 5: The PIM will be transformed into OWL and OWL-S
specifications that are executable by the software developed in Step 3.
This aspect was only partially achieved. UML PIM models were
created but their automated transformation to OWL and OWL-S were
not. An XLST transformation process was located through the literature
search and review process, however the software required was outside
of the resources available for this dissertation. Moreover, the UML
OWL and UML OWL-S profiles developed to allow the XLST
transformation would have made the UML modelling complex.
Therefore, the opportunity for transformable UML models to be created
by domain experts is not realistic within the boundaries of their
exposure to mainstream UML modelling.
94
7.3 Research Question
The component aspects of the research question are considered individually
for evaluation against the integrated development method and the prototype
as follows.
Can the Object Management Group's Model-Driven Architecture approach be
integrated with Semantic Web ontology languages?
Whilst problems were experienced with transformation of UML models to
ontology languages, the methodology used still supports the philosophy
behind the MDA approach. Using the Protégé tool, OWL and OWL-S
artefacts can be modelled, and these transformed models became artefacts
used by the prototype at runtime to instantiate a system. Therefore, although
model transformation does not result in coded artefacts, by using components
at a higher level of abstraction than code, such as Semantic Web agents, a
system can be created purely from modelling.
Can the combined approach produce a tool based on collaborating software
agents that captures observational data described by ontologies?
The prototype demonstrates that this aspect is achievable. Appendix E
provides the output from the deployment of the elicitation process and
provides evidence of the prototype’s capability to capture observational data
described by ontologies. Also included within this appendix is the schema
data abstracted from OWL files. This demonstrates the prototypes capability
to capture entity relationship schemas, specified by ontology, at runtime for
the purposes of recording data. Therefore, within the constraints of the OWL
95
constructs used, the prototype can capture observational data described by
ontologies.
Can the tool produced support expert knowledge elicitation through
extendible statistical elicitation techniques?
The prototype does support expert knowledge elicitation and is highly
extendible by users with familiarity of the Protégé tool and the limitations of
the supported OWL constructs.
7.4 Summary
The evaluation of the prototype has demonstrated some limitations in
achieving the requirements developed over the course of the dissertation.
The UML transformation approach derived from Gaševic (2004), Gannod et al
(2004) and Timm et al (2005) fall short of allowing domain experts to model
systems on the basis that the required UML modelling is bespoke to creation
of OWL and OWL-S artefacts. This aspect of specialisation moves this activity
away from the ‘mainstream’ UML modelling to which domain experts may
likely have been exposed.
However, in principle the prototype demonstrates that an MDA approach can
be integrated with the semantic Web to produce operational software without
resorting to code production. The artefacts produced from the adopted MDA
approach can be used directly by the semantic Web based software
components to establish a system whose process and data is specified purely
from modelling.
96
Chapter 8 Conclusions and Future Research
8.1 Limitations of work
The primary limitations of this work concern the level of implementation of the
Semantic Web architecture, the extent of supported constructs for the
ontology languages and the relatively simple process model used for the
elicitation process. The aspects of agent groundings and service profiles were
not considered which prevented the implementation of service discovery.
Processes for composite services were limited to sequential, non-iterative
constructs. Hence, usage of expressions in a logical language is not catered
for. Furthermore, functionality has only been included for atomic and
composite processes. Implementation of the OWL language was limited to
permitting definition of classes, generalisation, attributes, binary associations,
multiplicity and association classes.
Secondary limitations are that only one elicitation process was used to assess
the software and approach. Assessment of the versatility of the software
would benefit from abstraction of more elicitation techniques to better
measure the capability of the approach. Finally, when undertaking the
elicitation process, checks for completeness of data were reliant on the user.
This could be improved by inclusion of integrity checks of input data against
the OWL schemas for the data.
8.2 Comparison of results with the body of knowledge
In accordance with Frankel et al (2004), synergies were located between
mainstream software engineering and the semantic web. Through utilisation
97
of the concept of modelling encompassed by UML, a method was developed
that captured the MDA steps of creation of computational independent
models (CIMS), creation of platform independent models (PIMs) and
transformation of PIMs, Kleppe et al (2003). The transformation of PIMs was
carried out manually due to lack of resource for suitable software such as
Poseidon. However, in compliance with Gaševic el al (2004) and Atkinson
(2004), a UML profile has been produced forming the basis of a direct XSLT
transformation from UML to OWL.
Similar transformations from UML behavioural models to OWL-S were not
achieved. As an alternative route, following Grønmo et al (2005) and Timm et
al (2005), a UML profile for OWL-S was created and forms the basis of an
XLST transformation. This required the behavioural process to be modelled
by OWL-S orientated UML static diagrams which provides a detrimental layer
of complexity. This aspect concurs with Kum et al (2006) who identified that
whilst the MDA transformation of structural models has been successfully
applied in practice, dynamic models remain an area for further research.
Following on with Kleppe et al’s MDA steps, transformation to code was not
required. In accordance with Knublauch (2004), the preceding MDA step
provided platform specific models in the form of OWL and OWL-S artefacts
that could be used directly by software agents. By achieving the ability to
specify and implement software systems at this higher level, Davis et al’s
(2005) belief that application model authoring, merging and editing in the
future may be undertaken by the common user is partially validated. It is not
98
fully validated as the modelling requirements for transformation of behavioural
aspects remains complex.
This shift to creation of operational systems directly from earlier stages of the
MDA process was achieved by adoption of Semantic Web architecture. In
accordance with Schulz-Hofen et al’s (2006) and Gannod et al’s (2004)
concepts of software product lines, agents were produced with the capability
for re-use in alternative configurations. The ability of the data and blackboard
agents to configure and record data against ad-hoc OWL specified data
schemas was a key contributor to this.
8.3 Conclusions
Despite the limitations of the prototype, several conclusions can still be
drawn. The MDA approach has been integrated with Semantic Web ontology
languages to produce a tool based on collaborating software agents. The
adoption of OWL as a runtime artefact provides for data capture based on
flexible data schema designs. Usage of OWL-S allows for orchestrating the
software agents for alternative purposes. The combination of these aspects
provides a flexible method of extendibility.
Thomas (2004) provides some scepticism to the ability to fully realise the
MDA due to modelling always being distinct from reality. By increasing the
abstraction of the modelled components, this dissertation has demonstrated
that its prototype can be instantiated into a system through modelling and the
subsequent creation of runtime artefacts. Therefore, by using the Semantic
99
Web’s machine-readable ontologies, the MDA approach has been partially
realised by this dissertation’s prototype.
The dissertation did not achieve transformation of UML models to OWL and
OWL-S artefacts. This aspect was considered a route to allow users with
expert domain knowledge to construct systems out of software components.
Whilst this transformation has been assessed as achievable, the UML profiles
required for this process define a bespoke implementation of UML that
require domains to be modelled in the context of OWL and OWL-S. This
makes the modelling activity more specialised and than ‘traditional’ UML
modelling. Exposure to the Protégé tool with its Jambalaya plug-in indicates
that direct modelling within an OWL environment may be preferable to using a
combination of UML and transformation.
8.4 Future research
The primary area for research identified during the dissertation is activities
associated with bringing the MDA and the Semantic Web closer together. A
tool capable of transforming a UML static diagram via a UML OWL profile into
OWL would increase the accessibility of this prototype to domain users. A
similar exercise for conversion of UML behavioural diagrams into OWL-S
would also be highly beneficial.
This dissertation has focused on merging the MDA and the Semantic Web at
a conceptual level. The prototype’s extendibility has not been fully
investigated. A potential area of research is extending the OWL and OWL-S
100
supported constructs and then measuring the resulting tools flexibility to
deliver extendible data capture.
101
Appendix A Domain modelling of the statistical knowledge elicitation technique A1. Introduction
This appendix describes the domain modelling in relation to Al-Awadhi et al’s
(2006) paper. The aim is to provide the core background of the environment
for which the prototype has been developed. The objective of domain
modelling is to understand the key concepts of a system and to familiarise
with the vocabulary of the system. Domain modelling does not describe any
software developed to support the system. This aspect is addressed in
specification modelling which takes the domain models as input and
establishes software system boundaries within the domain.
The techniques for the domain modelling are based on those described in
Unit 4 from M878 OO Software Development, and the output from the
exercise is described as follows. Section 2 presents an abstract of the
experimental process described in Al-Awadhi et al’s (2006) paper upon which
a grammatical parse is undertaken to identify nouns and noun phrases for
candidate concepts. Section 3 presents the domain modelling based on the
abstract contained in section 2, providing a static diagram, use case diagram
and state chart diagrams for the domain. These are presented in UML.
A2. The Experimental Process
The following description is derived directly from Al-Awadhi et al’s (2006)
paper. (Noun & noun phrases are underlined)
102
A2.1 Background
Regional survey data has been collated, and takes the form of attributes
measured against variables and factors.
VARIABLES: Rain in driest quarter; rain in wettest quarter; elevation; slope;
aspect; average winter temperature; average summer temperature; degree of
canopy cover.
Continuous variables and their ranges
FACTORS: Slope position (3); forest structure (3); presence of road (2);
grazing (2); vegetation type (20); land zone class (8); fire disturbance (3);
logging disturbance (4).
103
Factors and their levels
A2.2 Assessment Tasks
A2.2.1 Variable Selection And Optimal Values
Expert selects relevant variables (attributes) to consider for species. For
continuous random variable attributes:
104
• Establish range where species can be found
• Establish optimum value of attribute for species
For factor attributes
• Establish values suitable for species
• Rank the values from optimum to worst (grade 1,2,3 …)
A2.2.2 Assessments At The At Optimum For an undefined selection of sites, each with attributes at optimum levels:
• Establish median estimate where the true proportion is equally likely to
be greater or smaller
• Establish the lower and upper quartiles where there is equal chance of
all the proportions occurring
A2.2.3 Median Assessments For each variable, assuming optimum values for other variables:
• Plot the optimum estimate and range from 2.2.1, and the median
probability of presence from 2.2.2
• Split the lower and upper sections of the graph into 3 equal segments,
drawing vertical lines
• Click the probability of presence points on each vertical line, and draw
lines between each vertical line point
• Allow previous variable graphs to be compared
105
Median assessments for a continuous variable
For Factors, using a bar chart:
• Plot vertical bars for each relevant factor value (from 2.2) with the
optimum factor value on the left with a height at the median probability
of presence from 2.3
• Click the probability of presence value for each subsequent factor
value, relative to one another
Median assessments for a factor
106
A2.2.4 Variance Assessments
For this exercise, values are estimated in advance of the expert assessments,
which are then adjusted by the expert.
Upper and lower quartiles are estimated on the vertical axis for each
probability of presence.
For Variables:
• The expert gives upper & lower quartile assessments at one point
either side of the median
• Upper and lower quartiles for the remaining points are suggested on
behalf of the expert and joined up by lines
• The suggested points are adjusted by mouse click by the expert
• The expert assumes the median point and the points next to the
median are correct and gives upper and lower quartiles at the points
next to them
• Upper and lower quartiles are suggested for the remaining points
• These point are adjusted by the expert by mouse click
• This process is repeated again
The figure below represents one half of the exercise, with one step left to
complete.
107
Eliciting quartiles for a continuous variable
For Factors:
• Expert assumes first bar median is correct and provides either an
upper or lower median on the remaining bars
• Missing upper or lower bar is provided by symmetry
• Expert adjusts provided values as required
• Expert assumes first 2 median bars are correct and repeats process
for remaining bars
• Process is repeated, each time assuming that one more bar is
accurate
108
Eliciting quartiles for a factor
A3 Conceptual Modelling
The method for conceptual modelling is based upon that described in Unit 4
from M878 OO Software development. The process consists of a grammatical
parse to identify nouns and noun phrases, each potentially a concept. These
potential concepts are then rationalised into a final set of concepts to be
modelled with UML.
A3.1 Grammatical Parse
A grammatical parse of section 2 above provides the following nouns and
noun phrases that are potential candidate concepts within the domain:
109
Concept Discussion UML Class Survey Collation of data Survey Attribute Too general - Expert - Expert Species - Species Variable Two types of attribute data are collated VariableAttribute Range Concept Attribute - Factor Two types of attribute data are collated FactorAttribute Level Factors have individual levels associated with them that
are relevant to specific measured conditions FactorLevel
Relevant variables (attributes) to consider for species
Experts associate variables to species as relevant to their existence
RelevantVariable
(Ditto) For factor attributes Experts associate factor levels to species as relevant to their existence
RelevantAspect (super-concept)
Establish range where species can be found
Range of relevant variable in which species can exist – attributes to relevant variables
-
Establish optimum value of attribute for species
Attribute to RelevantVariable
Establish values suitable for species
Levels for a factor where an expert believes a species may be present
RelevantFactorLevel
Rank the values from optimum to worst
Sequence of best order for factor levels for species existence assessed by expert – same as RelevantFactorLevel
An undefined selection of sites Used for assessment of optimums SiteCondition Establish median estimate where the true proportion is equally likely to be greater or smaller
Attribute of SiteCondition -
Establish the lower and upper quartiles where there is equal chance of all the proportions occurring
Attributes of SiteCondition
Split the lower and upper sections of the graph into 3 equal segments, drawing vertical lines
Segments associated with variables, distributed from the optimum
SegmentVariable
The probability of presence points on each vertical line
Attribute of SegmentVariable -
Probability of presence value for each subsequent factor value
Attribute of RelevantFactorLevel
Upper and lower quartiles are estimated on the vertical axis for each probability of presence
Aspect of variance assessments, where each segment is assumed correct in turn and upper & lower probability of presence estimates are made for each remaining segment
SegmentVariableVariance
First bar median is correct and provides either an upper or lower median on the remaining bars
Similar as above but for Factors SegmentFactorVariance
Regional Survey Data Site where survey undertaken Site Regional Survey Data Variable data for survey at a site SurveyVariableData Regional Survey Data Factor data for a survey at a site SurveyFactorData
Candidate concepts
110
UML static diagram
FaunaSurvey::Survey
-name : String-minimum : Double-maximium : Double-description : String-unit : String
FaunaSurvey::VariableAttribute
-name : String-description : String
FaunaSurvey::FactorAttribute1* HasFactor
1
*
HasVariable
-relevantAspectsFaunaSurvey::Species FaunaSurvey::Expert
-expert : Expert-species : Species-minimumValue : Double-optimumValue : Double-maximumValue : Double-optimumProbability : Double
FaunaSurvey::RelevantVariable
FaunaSurvey::RelevantAspect
1
1..*
HasContributingAspect
1..* 0..1
AssessesSpecies-lowerEstimate : Double-medianEstimate : Double-upperEstimate : Double
FaunaSurvey::SiteCondition
-segmentValue : Double-segmentProbabilityOfPresence : Double-position : Double
FaunaSurvey::SegmentVariable
1
6
HasSegmentVariable
1
1
HasProbabilityOfPresence
0..1
1
IsRelevantVariable
-level : Integer-levelName : String
FaunaSurvey::FactorLevel
1
1..*
HasLevel
-expert : Expert-species : Species-rank : Integer-rankProbability : Double
FaunaSurvey::RelevantFactorLevel
0..1
1
IsRelevantFactor
0..1
1
HasFixedVarSegment
-fixedSegment : SegmentVariable-rangeSegment : SegmentVariable-sequence : Integer-upperMedian : Double-lowerMedian : Double
FaunaSurvey::SegmentVariableVariance
-fixedSegment : RelevantFactorLevel-rngeSegment : RelevantFactorLevel-sequence : Integer-upperMedian : Double-lowerMedian : Double
FaunaSurvey::SegmentFactorVariance
1
0..1
HasFixedSegment
*
0..1
HasRangeSegment
*
0..1
HasRangeVarSegment
-varableValue : DoubleFaunaSurvey::SurveyVariableData
*1
HasVariableData
-level : IntegerFaunaSurvey::SurveyFactorData
1
*
HasFactorData
-name : StringFaunaSurvey::Site
1
*
HasSurveyedFactorData
1*
HasSurveyVariableData
111
A3.1.1 Glossary Stereotype Name Description Constraint Concept Expert Domain Expert Concept Species Denotes Species Concept Survey Survey undertaken with
common measurable aspects over many locations
Concept FactorAttribute Measurable factor associated with a survey
Attribute FactorAttribute .name Name of FactorAttribute String Attribute FactorAttribute .description Description of FactorAttribute String Concept FactorLevel Specific levels associated with a
FactorAttribute
Attribute FactorLevel.level Integer Attribute FactorLevel.levelName String Concept VariableAttribute Measurable variable associated
with a survey
Attribute VariableAttribute.name Name of VariableAttribute String Attribute VariableAttribute.minimum Minimum range of
VariableAttribute Double
Attribute VariableAttribute.maximum Maximum range of VariableAttribute
Double
Attribute VariableAttribute.description Description of VariableAttribute String Attribute VariableAttribute.unit Unit of measure for
VariableAttribute String
Concept RelevantAspect Generalisation of a Factor or Variable which an expert considers relevant to the existence of a species
Concept SiteCondition A theoretical site with perfect conditions in terms of RelevantFactorLevel and RelevantVariable
Attribute SiteCondition.lowerEstimate Expert’s assessment of the lower quartile probability of presence at the ‘perfect’ site
Double
Attribute SiteCondition.medianEstimate Expert’s assessment of the median probability of presence at the ‘perfect’ site
Double
Attribute SiteCondition.upperEstimate Expert’s assessment of the upper quartile probability of presence at the ‘perfect’ site
Double
Concept RelevantFactorLevel A level of a factor deemed by an Expert to influence the existence of a Species
Sub-Concept of RelevantAspect
Attribute RelevantFactorLevel.rank Ranking order of a factor level by an Expert in consideration of the levels impact on a Species
Integer
Attribute RelevantFactorLevel.rankProbability Given other perfect conditions, an Experts assessment of the probability of presence for a Species given this RelevantFactorLevel
Double
Concept RelevantVariable A VariableAttribute deemed by an Expert to impact the existence of a species
Attribute RelevantVariable.optimumValue Expert’s opinion of the optimum value for a variable given other conditions as ‘perfect’
Double
Attribute RelevantVariable.minimumValue Expert’s opinion of the minimum value for a variable given other conditions as ‘perfect’
Double
Attribute RelevantVariable.maximumValue Expert’s opinion of the maximum value for a variable given other conditions as ‘perfect’
Double
Attribute RelevantVariable.optimumProbability Expert’s opinion of the probability of presence at the optimum variable value given other conditions as ‘perfect’
Double
Concept SegmentFactorVariance For a fixed factor level probability of presence, the
112
Expert’s assessment of upper and lower quartile probability of presences at a remaining factor level
Attribute SegmentFactorVariance.fixedSegment The fixed factor level RelevantFactorLevel <> SegmentFactorVariance. rangeSegment
Attribute SegmentFactorVariance.rangeSegment A RelevantFactorLevel being assessed for upper and lower median probability of presences
RelevantFactorLevel <> SegmentFactorVariance. fixedSegment
Attribute SegmentFactorVariance.sequence Integer referencing sequence of RelevantFactorLevel from the fixed RelevantFactorLevel
Integer
Attribute SegmentFactorVariance.upperMedian Upper median probability of presence
Double
Attribute SegmentFactorVariance.lowerMedian Lower median probability of presence
Double
Concept SegmentVariable Segments associated with RelevantVariable, distributed from the optimum
Attribute SegmentVariable.segmentValue Location of Segment within the variable range
Double
Attribute SegmentVariable. segmentProbabilityOfPresence
Probability of Species presence at segment SegmentVariable.segmentValue
Double
SegmentVariable.position Order of segment within the collection of SegmentVariables associated with a RelevantVariable
Integer
Concept SegmentVariableVariance For a variable ‘segment’ probability of presence, the Expert’s assessment of upper and lower quartile probability of presences at a remaining variable ‘segment’
Attribute SegmentVariableVariance. fixedSegment
The fixed SegmentVariable to which the SegmentVariableVariance. RangeSegment is referenced
SegmentVariable
Attribute SegmentVariableVariance. rangeSegment
The SegmentVariable assessed against the SegmentVariableVariance. fixedSegment
SegmentVariable
Attribute SegmentVariableVariance.sequence The order of SegmentVariableVariance within the collection of SegmentVariableVariance for the SegmentVariableVariance. fixedSegment
Integer
Attribute SegmentVariableVariance. UpperMedian
Upper median probability of presence for SegmentVariableVariance. rangeSegment
Double
Attribute SegmentVariableVariance. LowerMedian
Lower median probability of presence for SegmentVariableVariance. rangeSegment
Double
Association HasVariable A Survey has one or more VariableAttribute associated with it
Association HasFactor A Survey has one or more FactorAttribute associated with it
Association HasLevel A FactorAttribute has one or more FactorLevels associated with it
Association IsRelevantVariable A VariableAttribute is a RelevantVariable or is not
Association IsRelevantFactor A FactorLevel is a RelevantFactorLevel or is not
Association HasRelevantAspect A Species has one or more RelevantAspects for existence of a Species in the opinion of an Expert
113
Association AssessesSpecies An Expert asseses a Species as reliant on one or more RelevantAspects
Association HasProbabilityOfPresence In Expert’s opinion, a Species has a SiteCondition of probability of presence
Association HasSegmentVariable A RelevantVariable has 6 SegmentVariables associated with it
Association HasFixedSegment A RelevantFactorLevel can be fixed as a reference point for assessment of median probability of presences at other RelevantFactorLevels that have a lower rank
Association HasRangeSegment A RelevantFactorLevel assessed for median probability of presences against fixed RelevantFactorLevels that have a higher rank
Association HasFixedVarSegment A SegmentVariable can be fixed as a reference point for assessment of median probability of presences at other SegmentVariable that have a lower rank
Association HasFixedVarSegment A SegmentVariable assessed for median probability of presences against fixed SegmentVariable that have a higher rank
Concept SurveyVariableData Data collated for a survey site for variables
Attribute VariableValue Value of surveyed variable item Double Concept SurveyFactorData Data collated for a survey site
for factors
Attribute Level Value of surveyed factor item Integer Concept Site A location where survey data is
collated
Attribute Name Name of a survey location String Association HasVariableData A VariableAttribute has data
collated against it
Association HasFactorData A FactorLevel has data collated against it
Association HasSurveyVariableData A Site has variable data collated against it
Association HasSurveyFactorData A Site has factor data collated against it
Glossary
A3.2 Use Case Modelling
This section develops the use case diagrams, again using a grammatical
parse to identify the key processes/use cases of the system.
A3.2.1 Grammatical Parse
A grammatical parse of the verb and verb phrases associated with the paper
identifies the following candidate use cases.
114
ID Use Case Description UC01 Gather Range Process for establishing variable range ontology UC02 Gather Factor Process for establishing factor ontology UC03 Gather Range Data Process for accumulating survey data associated with ranges UC04 Gather Factor Data Process for accumulating survey data associated with ranges UC05 Assess Optimum Range
Value Process for eliciting optimum range value and limits for a species, includes identifying non-contributory survey data ranges
UC06 Assess Optimum Factor Value
Process for eliciting optimum factor value for a species, includes identifying non-contributory survey data
UC07 Assess Optimum Median POP
Process to elicit the median probability of presence for a species, given that all factors and variables are at their optimum
UC08 Assess Optimum Quartile POP
Process to elicit the upper and lower quartiles associated with the median probability of presence for a species, given that all factors and variables are at their optimum
UC09 Assess Variable Medians
Process to elicit the median probability of presence values for each variable, across equally split upper and lower sections from median to maximum and minimum assessed potential values.
UC10 Overlay Graph Process for overlaying graphs for alternative variables/factors UC11 Assess Factor Medians Process to elicit the median probability of presence values for each factor,
across their elicited ranked values. UC12 Assess Variable Median
Variance Assessment of conditional quartiles at the elicited medians
UC13 Assess Factor Median Variance
Assessment of conditional quartiles at the elicited medians
UC14 Run Analysis Run the statistical analysis
Candidate use cases
A3.2.2 Use Cases
Use Case Diagram
115
A3.2.2.1 Gather Range Name: Enter Range Goal: Variable range added to ontology Precondition: Ontology for range exists Trigger: enterRange(survey, name, minimum, maximum,
description, unit) associated with Surveyor Description: Ranges stored to reference instance data Concepts: VariableAttribute A3.2.2.2 Gather Factor Name: Enter Factor Goal: Factor added to ontology Precondition: Ontology factor collation exists Trigger: enterFactor(F.name, F.description, Vector(L.level,
L.levelName)) Description: Factors stored to reference instance data Concepts: FactorAttribute (F), FactorLevel (L) A3.2.2.3 Gather Range Data Name: Gather Range Data Goal: Instances of ontology created Precondition: Ontology for data collation exists, Variable ranges entered Trigger: gatherRangeData(survey, site, variableAttribute,
variableValue) Description: Range data collated at geographical locations is collected
as instances of an ontology structured to accept data Concepts: SurveyVariableData A3.2.2.4 Gather Factor Data Name: Gather Factor Data Goal: Instances of ontology created, Factors entered Precondition: Ontology for data collation exists Trigger: gatherFactorData(survey, site, factorLevel, level) Description: Factor data collated at geographical locations is collected
as instances of an ontology structured to accept data Concepts: SurveyFactorData
116
A3.2.2.5 Assess Optimum Range Value Name: Assess Optimum Range Value Goal: Optimum, minimum and maximum range values for
expert/species is stored Precondition: Ontology for data collation exists, with instance data Trigger: assessOptimumRangeValue(expert, species,
minimumValue, maximumValue, optimumValue) Description: Experts opinion of optimum, minimum and maximum
range values for a species is elicited and stored Concepts: RelevantVariable A3.2.2.6 Assess Optimum Factor Value Name: Assess Optimum Factor Value Goal: Ranked factor values for expert/species are stored Precondition: Ontology for data collation exists, with instance data Trigger: assessOptimumFactorValue(expert, species, rank) Description: Experts opinion of factor ranking for a species is elicited
and stored Concepts: ReleventFactorLevel A3.2.2.7 Assess Optimum Median POP Name: Assess Optimum Median POP Goal: Expert/species median probability of presence stored Precondition: Ontology for data collation exists, with instance data,
optimum, maximum and minimum values stored Trigger: assessOptimumMedianPOP(expert, species,
medianEstimate) Description: Capture experts opinion of median probability of presence
for a species, given all other variables are at optimum, identifying a probability where the expert believes there is an equal chance of a species either existing or not existing
Concepts: SiteLocation A3.2.2.8 Assess Optimum Quartile POP Name: Assess Optimum Quartile POP Goal: Expert/species quartile probability of presence stored Precondition: Ontology for data collation exists, with instance data,
optimum, maximum and minimum values and median at optimum stored
Trigger: assessOptimumQuartilePOP(expert, species, lowerEstimate, upperEstimate)
Description: Capture experts opinions of the quartile probability of presences for a species, given all variables are at optimum. Each probability of presence quartile range has
117
an equal chance of occurring. Concepts: SiteLocation A3.2.2.9 Assess Variable Medians Name: Assess Variable Medians Goal: Range values segment medians stored Precondition: Ontology for data collation exists, with instance data,
optimum, maximum and minimum values and median at optimum stored
Trigger: assessVariableMedians(segmentValue) Description: The Optimum to lower ranges and the optimum to
maximum ranges are divided into 3 equal segments. The expert provides their median assessment for the probability of presence for the species at each segment boundary, assuming all other variables are at optimum
Concepts: SegmentVariable A3.2.2.10 Assess Factor Medians Name: Assess Factor Medians Goal: Probability of presence stored for each ranked factor
value for a factor Precondition: Ontology for data collation exists, with instance data,
ranked factor values and the median at optimum are stored
Trigger: assessFactorMedians(expert, species, rankProbability) Description: The expert provides their median assessment for the
probability of presence for a species at each ranked value for a factor, assuming all other variables are at optimum
Concepts: RelevantFactorLevel A3.2.2.11 Overlay Graph Name: Overlay Graph Goal: Graph for previously assessed factor or range variable
overlaid on current assessment Precondition: Graphs exist Trigger: overlayGraph() Description: Concepts:
118
A3.2.2.12 Assess Variable Median Variance Name: Assess Variable Median Variance Goal: Quartile median probability of presence values stored for
each lower or upper range segments based on each segment boundary being assumed as correct, commencing with the boundary at the range optimum
Precondition: Median probability of presence stored at each range segment boundary
Trigger: assessVariableMedianVariance(fixedSegement, rangeSegment, sequence, upperMedian, lowerMedian)
Description: Using the boundary assessments stored from assessVariableMedians(), each boundary is taken in turn and the quartile median probability of presence values at the remaining boundaries are assessed and stored, starting with the boundary at the optimum
Concepts: SegmentVariableVariance A3.2.2.13 Assess Factor Median Variance Name: Assess Factor Median Variance Goal: Quartile median probability of presence values stored for
each ranked based on ranked factor median being assumed as correct, commencing with the highest ranked factor
Precondition: Median probability of presence stored at each ranked factor
Trigger: assessFactorMedianVariance(fixedSegement, rangeSegment, sequence, upperMedian, lowerMedian)
Description: Using the ranked factor assessments stored from assessFactorMedians(), each ranked factor is taken in turn and the quartile median probability of presence values at the remaining ranked factors are assessed and stored, starting highest ranked factor
Concepts: SegmentFactorVariance A3.2.2.14 Run Analysis Name: Run Analysis Goal: Analysis data stored Precondition: All other use cases complete Trigger: runAnalysis(Survey) Description: Undertakes statistical analysis of data Concepts:
119
A3.3 Statechart Diagram The following statechart shows the overall state transition for the elicitation technique
Statechart for elicitation technique
Waiting for Range Details Input Range Details
Waiting for Factor Details Input Factor Details
Waiting for Range Data Input Factor Data
Waiting for Factor Data Input Factor Data
Waiting for Range Details
Expert Eliciation
120
The following statechart shows the state transition for the Expert Elicitation
state.
Waiting for Expert Variable Segement Median Data Input Expert Variable Segement Median Data
Waiting for Expert Optimum POP Input Expert Optimum POP
Waiting for Variable min, max, optimum Input Variable min, max, optimum
Waiting for Expert Quartile POPs Input Expert Quartile POPs
Waiting for Expert Factor Rank Median Data Input Expert Expert Factor Rank Median Data
Waiting for Expert Variable Segement Median Quartile Data Input Expert Variable Segement Median Quartile Data
Waiting for Expert Factor Rank Median Quartile Data Input Expert Expert Factor Rank Median Quartile Data
Statechart for expert elicitation
121
Appendix B Requirements Elicitation and Specification
B1 Introduction
The requirements for the prototype are multifaceted and are built from the
integration of a number of components. The requirements go beyond purely
the creation of a prototype for statistical elicitation and focus more on the
environment and development methods devised for the creation of the
prototype. This Appendix pulls together all the requirements developed
through Chapters 1 to 4 and Appendix A.
Appendix A describes a domain model for a specific implementation of the
prototype. Chapter 1 presents a discussion of the wider problem domain,
introducing the concepts of the MDA and Semantic Web. It also provides
further requirements for the prototype such as extendibility. Chapters 3 and 4
present requirements, associated with the Semantic Web and the MDA
respectively, which are concerned with the target environment and
development approach.
The following sections discuss the amalgamation of these requirements to
provide the Requirements Specification defining acceptance and system test
definitions.
B2 Requirements Elicitation
Appendix A provides a domain model for a specific implementation of the
prototype. The Proposed M801 Topic (2005) states that the tool must be
extendible by users with little software development experience. From this it is
122
interpreted that the prototype must be highly configurable without resorting to
code production. Furthermore, configuration must be presented in a manner
that reflects the skills and professional background of the user. A method of
achieving this is seen as providing a prototype closely tied to the MDA. The
advantage of this is that the prototype can be configured based on artefacts
at some level of abstraction from the software itself and more closely tied to
the domain of implementation. The user should be fully conversant with the
domain within which the prototype is to be deployed, and therefore
configuration of the prototype is much more accessible if presented in this
realm.
UML is a tool used within software development to present models of
software systems in a manner that can be understood by their users. On this
basis, it is assumed that users can develop sufficient skills to develop their
own models of systems using UML. With users having the ability to model
systems at this high level of abstraction, the MDA can then be used to
produce operational software. The MDA is not currently in a position where
coded artefacts can be produced seamlessly from this process. Modelling the
interaction of existing software components overcomes this issue and allows
users to model systems in UML. These models can then be transformed into
runtime specifications for a software system.
The World Wide Web is taken as the target environment for the prototype as
this is considered to be the longer-term direction that software development
will take. A current initiative on the Web is the development of what is termed
the Semantic Web. The Semantic Web is closely tied to the concept of
123
structuring information on the Web in machine-readable ontologies and the
usage of Software Agents collaborating to achieve certain tasks. These
aspects make the Semantic Web a highly inviting arena for the prototype,
which is also conducive to the implementation of the MDA.
B3 Requirements Specification
Requirements for the prototype are subdivided into two sets. The first
represents the requirements that define the acceptance test definition for the
prototype. These are concerned with properties of the system that must be
operational for release to users within the problem domain. These
requirements are presented in the table below.
Primary Requirement
Description
PR1
The software must be configurable to collect data described by any UML Static diagram or combination of UML static diagrams
PR2
It must be possible to specify the behaviour of the system by transforming UML Use Cases and behavioural diagrams into artefacts used by the prototype at runtime
PR3
The system must be further extendible through the integration of new software components or agents whose functionality can be similarly integrated into new systems through exercising requirements PR1 and PR2
Acceptance test definition
The second set of requirements define the system test definitions, and more
broadly describe the high level requirements of the properties of the software
124
that must be in place for delivery of the system to the user. These
requirements are presented in the table below.
System Requirement
Description
SR1
The software must interpret class schemas described by OWL and allow instances of the classes to be created
SR2
The system must implement the collaboration of software components by interpretation of OWL-S specifications at runtime
SR3
The system must exhibit the capability to support the following development technique based on the MDA:
Step 1: Domain analysis will produce a series of structural and dynamic UML representations of the problem domain that will reflect the CIM defined in MDA Step 2: The CIM will be taken and re-modelled within a software realm to create a model reflective of the PIM within MDA. This model will focus on the interaction of high-level software service components together their semantic descriptions. Step 3: Software will be developed to undertake the control and dataflow between services, as defined by OWL-S specifications. The software will be capable of interpreting OWL-S for this purpose. Step 4: Individual component services will be manually built in accordance with semantic descriptions output from step 2. Step 5: The PIM will be transformed into an OWL-S specification that is executable by the software developed in Step 3.
System test definition
125
Appendix C Specification Modelling
C1 Introduction
This section considers the application of the selected architecture from
Chapter 5 to the prototype system. The process begins with specification of
the architectural components of the system. The domain model is then
reviewed against these components and restructured to suit the system
architecture. The behavioural models for the system and the individual
components are then developed.
C2 Components
The components of the system based on the architecture discussed in
Chapter 5 are as follows:
C2.1 Service Broker The service broker is responsible for:
• Maintaining a directory of agents detailing the service they offer and
their location
• Matching directory information to requests for service provision by
agents, returning their location
C2.2 Blackboard The blackboard is responsible for
• Routing Communications between collaborating agents
126
• Storage of dynamic data for re-instantiation of agents
• Storage of persistent data associated with the composite service
• Publishing of persistent data
C2.3 Agent
Agents collaborate together to realise the required composite service. Agents
share the same core responsibilities:
• Registration of their services with service brokers
• Instantiation of their services for the purpose of delivering a composite
service
• Communicating with a blackboard
C.2.3.1 Coordination Agent The coordination agent is responsible for
• Retrieving suitable agents from the service broker for delivery of the
composite service
• Initialising an agent to collaborate within the composite service
• Monitoring progress of the composite service
• Passing instructions for agents to the blackboard
• Responding to user instructions
C2.3.2 Ontology Data Agent The ontology data agent is responsible for:
127
• Create, read, update and delete of data associated with an ontology
via user interaction
C2.3.3 Graphical Agent
The graphical agent provides a graphical interface to a user and is
responsible for:
• Create, read, update and delete of data associated with an ontology
via user interaction
C2.3.4 Statistical Agent The statistical agent is responsible for:
• Running a statistical analysis against data stored in an ontology
C3 Modifications to Domain Model
The static domain model provided in Appendix A considered Al-Awadhi et al’s
(2006) elicitation technique independent of implementation by a software
system. Specification modelling seeks to identify a software system as the
method of delivery and transforms the domain models into an environment
based on the architecture of the proposed system. This transformation is a
process of establishing system boundaries, allocation of the models to
specific architectural components and elaboration of the models in
accordance with the requirements of the architectural components.
128
C3.1 System Boundaries
The system boundary is that of the Domain Model.
C3.2 Static Model Allocation to Components Ontology Data Agent
• RelevantVariable
• RelevantFactorLevel
• SiteCondition
Graphical Agent
• SegmentVariable
• SegmentVariableVariance
• SegmentFactorVariance
C3.3 Behavioural Model - System Sequence Diagram
A simplified sequence diagram showing the intent of the system is provided
below. The diagram does not consider the user, nor does it consider iterative
uses of the same agent. The diagram captures the message sequences
starting with the coordination agent identifying then registering with the
blackboard. It proceeds with identifying an agent from the broker, and that
agent’s registration with the blackboard. Communication between the agents
is then via the blackboard.
129
CoordinationAgent Agent BlackboardBroker
requestBlackboard
nameBlackboardregisterWithBlackboard
agentComplete
agentComplete
requestAgent
nameAgent
startAgent
registerWithBlackboard
isAgentComplete
High Level Sequence Diagram
130
Appendix D Design Modelling
D1 Introduction
This section describes the design of the prototype. This commences with a
revisit of the domain model from the domain analysis, and its elaboration to
the entity relationship diagram for implementation of the elicitation technique.
The design of the prototype is then considered.
D2 Entity Relationship Diagram for the Elicitation Technique
The entity relationship diagram from the domain modelling is partitioned and
elaborated as follows:
• The model is split between definition of the survey and definition of the
elicitation technique. This provides the opportunity to develop OWL
specifications for each that match the stages of the elicitation process
to the prototype’s agents
• An additional entity relationship diagram is developed to allow for the
capture of the survey and elicitation process. This is an enhancement
specific for the prototype and allows entities to be collated together for
specific stages of the prototype’s operation
The survey static diagram is provided below:
131
Survey static UML diagram
Protégé Jambalaya view of survey schema
-surveyName : stringFaunaSurvey::Survey
-name : String-minimum : Double-maximium : Double-description : String-unit : String
FaunaSurvey::VariableAttribute
-name : String-description : String
FaunaSurvey::FactorAttribute
1*
HasFactor
1
*HasVariable
-level : Integer-levelName : String
FaunaSurvey::FactorLevel
1
1..* HasLevel
-varableValue : DoubleFaunaSurvey::SurveyVariableData
*
1
HasVariableData
-level : IntegerFaunaSurvey::SurveyFactorData
1
*
HasFactorData
-name : StringFaunaSurvey::Site
1
*
HasSurveyedFactorData
1
*
HasSurveyVariableData
132
Elicitation technique static UML diagram
Protégé Jambalaya view of elicitation technique schema
-minimumValue : double-optimumValue : double-maximumValue : double-optimumProbability : double
FaunaSurvey::RelevantVariable
-relevantAspectName : string-species : string-expert : string
FaunaSurvey::RelevantAspect
-lowerEstimate : double-medianEstimate : double-upperEstimate : double
FaunaSurvey::SiteCondition
-segmentVariableName : string-segmentValue : double-segmentProbabilityOfPresence : double-position : double
FaunaSurvey::SegmentVariable
1
7
HasSegmentVariable
1..*
1
HasRelevantAspect
-rank : int-rankProbability : double
FaunaSurvey::RelevantFactorLevel
0..1
1
HasFixedVarSegment
-segmentVariableVarianceName : string-fixedSegment : SegmentVariable-rangeSegment : SegmentVariable-sequence : int-upperMedian : double-lowerMedian : double
FaunaSurvey::SegmentVariableVariance
-segmentFactorVarianceName : string-fixedSegmentf : RelevantFactorLevel-rangeSegmentf : RelevantFactorLevel-sequencef : int-upperMedianf : double-lowerMedianf : double
FaunaSurvey::SegmentFactorVariance
1
0..1
HasFixedSegment
*
0..1
HasRangeSegment
*
0..1HasRangeVarSegment
FaunaSurvey::Expert FaunaSurvey::Species
0..1 *
AssessesSpecies
1 1
HasProbabilityOfPresence
133
The final UML static diagram provides a vehicle for the prototype to monitor
data collation against. Here, a specific class of object is defined whose
relations to the survey and elicitation diagrams allows the creation of related
objects to be captured in accordance to the phased operation of the
prototype. This is named the Survey Schema, and the UML static diagram is
presented below:
Site
SurveyFactorData
SurveyVariableData
GatherSurveyData
0..1
*
HasSurveyVariableData
0..1 *
HasSurveyFactorData
0..1
*
HasSite
Elicitation
Expert
RelevantAspect
SegmentFactorVariance
SegmentVariable
SegmentVariableVariance
SiteCondition
-relevantAspectsSpecies
1
* HasSpecies
1
* HasRelevantAspect
1
*
HasSectorFactorVariance
1
*
HasSiteCondition
1
*
HasSegementVariableVariance
1
*
HasSegementVariable1
1
HasExpert
InstantiateSurveySchema FactorAttribute
1 *
HasFactorAttributes
FactorLevel
1
*
HasFactorLevels
Survey
1
1 HasSurvey
VariableAttribute
1
*HasVariableAttributes
Survey Schema UML static diagram
134
Protégé Jambalaya view of Survey Schema
135
D3 Behavioural Diagrams for Elicitation Technique
The generic sequence diagram for communication between agents is shown
below:
CoordinationAgent Agent BlackboardBroker
requestBlackboard
nameBlackboardregisterWithBlackboard
agentComplete
agentComplete
requestAgent
nameAgent
startAgent
registerWithBlackboard
isAgentComplete
Sequence diagram for agent communication
The Activity Diagram for the elicitation technique is as follows
CreateSurveySchema CreateSurveyData CreateEliciation CreateStatistics
Activity diagram for elicitation technique
136
The CreateSurveySchema activity is associated with adding the metadata to
the survey schema against which survey data is recorded. The output from
this activity is an object of the class InstantiateSurveySchema. The
CreateSurveyData activity provides for collation of survey data. The output
from this activity is an object of the class GatherSurveyData. The
CreateEllicitation activity is concerned with collation of data elicited from
experts. The output from this activity is an object of the class Elicitation. The
create statistics activity is concerned with running the statistical analysis on
the data. The OWL-S specification produced in accordance with this activity
diagram is as follows, presented in the graphical representation of the OWL-S
process from Protégé provided below:
OWL-S process for elicitation
137
D4 Design of Agents
D4.1 Blackboard Agent
OWL classes
+GetID() : string+GetProperties() : Hashtable+GetDomainObjects() : Hashtable+GetRangeObjects() : Hashtable+AddProperty() : void+AddDomain() : void+AddRange() : void
-domainObjects : Hashtable-rangeObjects : Hashtable-properties : Hashtable-ID : string
Individual::OWLClass
C# Helper::Hashtable
+GetID() : string+GetDomain() : OWLClass+GetRange() : string+GetFPType() : string+SetDomain() : void+SetType() : void+SetRange() : void
-domain : OWLClass-type : string-range : string-ID : string
Individual::FunctionalProperty
+GetID() : string+SetDomain() : void+SetRange() : void+GetDomain() : OWLClass+GetRange() : OWLClass
-domain : OWLClass-range : OWLClass-ID : string
Individual::ObjectProperty
1
*
HasProperties
*1
HasDomain
*
1
HasRange
1
*
IsSubClassOf
-ID : stringIndividual::Schema1
*
HasClasses
138
Classes to instantiate instances on the DBMS
+GetID() : string+GetProperties() : Hashtable+GetDomainObjects() : Hashtable+GetRangeObjects() : Hashtable+AddProperty() : void+AddDomain() : void+AddRange() : void
-domainObjects : Hashtable-rangeObjects : Hashtable-properties : Hashtable-ID : string
Individual::OWLClass
C# Helper::Hashtable
+GetID() : string+GetDomain() : OWLClass+GetRange() : string+GetFPType() : string+SetDomain() : void+SetType() : void+SetRange() : void
-domain : OWLClass-type : string-range : string-ID : string
Individual::FunctionalProperty
+GetID() : string+SetDomain() : void+SetRange() : void+GetDomain() : OWLClass+GetRange() : OWLClass
-domain : OWLClass-range : OWLClass-ID : string
Individual::ObjectProperty
1
*
HasProperties
*1
HasDomain
*
1
HasRange
1
*
IsSubClassOf
-ID : stringIndividual::Schema1
*
HasClasses
139
140
OWLS build classes
+BuildClass()+MoveToTargetClassNode() : void+GetActualNode() : void+GetNodeName() : string+AddParentReleationship() : void
-builtClasses : OWLSCollection-mainNav : XPathNavigator-targetNav : XPathNavigator-tempNav : XPathNavigator-myXPathDocument : XPathDocument-fullName : string-targetName : string-gotNode : bool-ID : string-type : string
Builds::BuildClass
C# Helper::XPathNavigator
+OWLSCollection()+ContainsKey() : bool+GetOwlsInstances() : ArrayList+Add() : void+GetInstanceDescriptorCollection() : Hashtable+GetType() : string+GetInstance() : object+AddClass() : void+GetName() : string+GetLatestEntry() : string+GetPriorCompositeProcess() : string+GetParent() : string+GetPriorAtomicProcess() : string+AddChildParent() : void
-owlsCollection : Hashtable-theClasses : Hashtable-childParentCollection : Hashtable-lastCompositeProcess : string-lastAtomicProcess : string
Collection::OWLSCollection
C# Helper::XPathDocument
+AtomicProcessBuild()+GetInstance() : <unspecified>
-atomicProcess : AtomicProcess-hasInput : InputBuild-hasOutput : OutputBuild
Builds::AtomicProcessBuild
+InputBuild()+GetInstance() : <unspecified>
-input : InputBuilds::InputBuild
+OutputBuild()+GetInstance() : <unspecified>
-output : OutputBuilds::OutputBuild
+CompositeProcessBuild()+GetInstance() : <unspecified>
-hasInput : InputBuild-hasOutput : OutputBuild-sequenceBuild : SequenceBuild-performBuild : PerformBuild
Builds::CompositeProcessBuild
+ControlConstructBagBuild()+GetInstance() : <unspecified>
-ccb : ControlConstructBag-first : ControlConstruct-rest : List-ccbB : ControlConstructBagBuild-cclB : ControlConstructListBuild-sequenceBuild : SequenceBuild-performBuild : PerformBuild
Builds::ControlConstructBagBuild
+ControlConstructListBuild()+GetInstance() : <unspecified>
-ccl : ControlConstructList-first : ControlConstruct-rest : ControlConstructList-ccbB : ControlConstructBagBuild-cclB : ControlConstructListBuild-sequenceBuild : SequenceBuild-performBuild : PerformBuild
Builds::ControlConstructListBuild
+InputBindingBuild()+GetInstance() : <unspecified>
-inputBinding : InputBinding-inputBuild : InputBuild-valueOfBuild : ValueOfBuild
Builds::InputBindingBuild
+OutputBindingBuild()+GetInstance() : Output
-outputBinding : OutputBinding-outputBuild : OutputBuild-valueOfBuild : ValueOfBuild
Builds::OutputBindingBuild
+ParameterBuild()+GetInstance() : Parameter
-parameter : ParameterBuilds::ParameterBuild
+PerformBuild()+GetInstance() : Perform
-perform : Perform-cpb : CompositeProcessBuild-apb : AtomicProcessBuild-ipb : InputBindingBuild
Builds::PerformBuild
+ProduceBuild()+GetInstance() : Produce
-produce : Produce-opbb : OutputBindingBuild
Builds::ProduceBuild
+SequenceBuild()+GetInstance() : <unspecified>
-sequence : Sequence-cclb : ControlConstructListBuild
Builds::SequenceBuild
+SplitJoinBuild()+GetInstance() : SplitJoin
-splitJoin : SplitJoin-ccbb : ControlConstructBagBuild
Builds::SplitJoinBuild
+ValueOfBuild()+GetInstance() : <unspecified>
-valueOf : ValueOf-fromProcessBuild : PerformBuild-theVarInBuild : InputBuild-theVarOutBuild : OutputBuild
Builds::ValueOfBuild
+OWLSParser() : OWLSParser+GetOWLSCollection() : OWLSCollection+GetCompositeProcess() : CompositeProcess
-owlsCollection : OWLSCollection-comp : CompositeProcess
Parser::OWLSParser
1
1
+SQLOWLSBuild() : SQLOWLSBuild+CreateOWLSSQLInstances() : void
Builds::SQLOWLSBuild
141
142
143
Core OWLS classes
+AddParameter() : void+AddInput() : void+AddOutput() : void+GetParameterList() : ArrayList+GetInstanceList() : ArrayList+GetOuputList() : ArrayList
-ID : string-hasParameter : ArrayList-hasInput : ArrayList-hasOutput : ArrayList
Individual::Process
C# Helper::ArrayList
+GetID() : string-ID : stringIndividual::ControlConstruct
Individual::AtomicProcess
+SetToParam() : void+SetValueOf() : void+GetID() : string+GetToParam() : Parameter+GetValueSource() : ValueOf
-ID : string-toParam : Parameter-valueSource : ValueOf
Individual::Binding
+GetID() : string+SetParameterID() : void+GetParameterType() : string+SetParameterType() : void
-ID : string-type : string
Individual::Parameter
+SetFromProcess() : void+SetTheVar() : void+GetFromProcess() : Perform+GetTheVar() : Parameter+GetID() : void
-ID : string-theVar : Parameter-fromProcess : Perform
Individual::ValueOf
+SetFirst() : void+SetRest() : void+GetFirst() : ControlConstruct+GetRest() : ControlConstructList
-first : ControlConstruct-rest : ControlConstructList
Individual::ControlConstructList
+GetID() : string-ID : stringIndividual::List
+AddHasDataFrom() : void+GetHasDataFrom() : ArrayList+GetProcess() : Process+SetProcess() : void
-process : Process-hasDataFrom : ArrayList
Individual::Perform
+SetComposedOf() : void+GetComposedOf() : ControlConstruct
-composedOf : ControlConstructIndividual::CompositeProcess
+SetFirst() : void+SetRest() : void+GetFirst() : ControlConstruct+GetRest() : ControlConstructBag
-first : ControlConstruct-rest : ControlConstructBag
Individual::ControlConstructBag
Individual::Input Individual::Output
Individual::InputBinding Individual::OutputBinding
+GetOutputBindings() : ArrayList+AddOutputBinding() : void
-outputBindings : ArrayListIndividual::Produce
+SetComponents() : void+GetComponents() : ControlConstructList
-components : ControlConstructListIndividual::Sequence
+SetComponents() : void+GetComponents() : ControlConstructBag
-components : ControlConstructBagIndividual::SplitJoin
144
145
146
OWL build classes
+OWLParser() : OWLParser+GetSchemaName() : void-BuildOWLClasses() : void-BuildOWLSubClasses() : void-AddOWLClass() : void-AddRemoteOWLClass() : void-AddOWLSubClass() : void-BuildObjectProperties() : void-AddObjectProperty() : void-BuildFunctionalProperties() : void+AddFunctionalProperty() : void+BuildCardinalities() : void+GetOwlClasses() : Hashtable+GetObjectProperties() : Hashtable+GetFunctionalProperties() : Hashtable+GetFunctionalProperty() : FunctionalProperty+GetObjectProperty() : ObjectProperty+GetOWLClass() : OWLClass
-owlClasses : Hashtable-functionalProperties : Hashtable-objectProperties : Hashtable-schemaName : string
Parser::OWLParser
+BuildSQLSchema() : BuildSQLSchema+GetSqlOwlClasses() : Hashtable-SetSqlOwlClasses() : void+SetSqlFunctionalProperties() : void+SetSqlObjectProperties() : void+SetSqlHasDomains() : void+SetSqlHasRanges() : void
-owlParser : OWLParser-owlClasses : Hashtable-functionalProperties : Hashtable-objectProperties : Hashtable-sqlSchema : SQLSchema-sqlOWLClasses : Hashtable-sqlFunctionalProperties : Hashtable-sqlObjectProperties : Hashtable-sqlHasDomains : Hashtable-sqlHasRanges : Hashtable
Builds::BuildSQLSchema
+SQLSchema() : SQLSchema+GetID() : int+GetSchemaName() : string+SetID() : void+SetSchemaName() : void
-ID : int-schemaName : string
SQLIndividual::SQLSchema
1
1HasOWLParser
+SQLEntity() : SQLEntity
-connection : SQLConnection-command : SQLCommand
SQLIndividual::SQLEntity
C# Helper::SQLConnection
C# Helper::SQLCommand
+SQLFunctionalProperty() : SQLFunctionalProperty+GetID() : int+GetFunctionalPropertyName() : string+GetDomainOwlClass() : string+GetFPType() : string+GetRange() : string+GetRangeSchemaName() : string+SetID() : void+SetFunctionalPropertyName() : string+SetDomainOwlClass() : string+SetType() : void+SetRange() : void+SetRangeSchemaName() : void
-ID : int-functionalPropertyName : string-domainOWLClass : int-type : string-range : string-rangeSchemaName : string
SQLIndividual::SQLFunctionalProperty
+SQLHasDomain() : SQLHasDomain+GetID() : int+GetObjectPropertyID() : int+GetDomainClassID() : int+SetID() : void+SetObjectPropertyID() : void+SetDomainClassID() : void
-ID : int-objectPropertyID : int-domainClassID : int
SQLIndividual::SQLHasDomain
+SQLHasRange() : SQLHasRange+GetID() : int+GetSchemaName() : string+GetObjectProperty() : string+GetRangeClass() : string+GetRangeSchemaName() : string+GetMinCardinality() : int+GetMaxCardinality() : int+SetID() : void+SetSchemaName() : void+SetObjectProperty() : void+SetRangeClass() : void+SetRangeSchemaName() : void+SetMinCardinality() : void+SetMaxCardinality() : void
-ID : int-schemaName : string-objectProperty : string-rangeClass : string-rangeSchemaName : string-minCardinality : int-maxCardinality : int
SQLIndividual::SQLHasRange
+SQLObjectProperty() : SQLObjectProperty+GetID() : int+GetObjectPropertyName() : string+SetID() : void+SetObjectPropertName() : void
-ID : int-objectPropertyName : string-schemaName : string
SQLIndividual::SQLObjectProperty
+SQLOWLClass() : SQLOWLClass+GetID() : int+GetOwlClassName() : int+SetID() : void+SetOwlClassName() : void
-ID : int-owlClassName : string-schemaName : string
SQLIndividual::SQLOWLClass
*
1
*
1
*
1* 1
*1
*
1
147
148
149
150
151
Top level classes
+GetOWLClassCollection() : DataSet+GetOWLClassCollectionParam() : DataSet+GetClassCollection() : DataSet+GetClassCollectionParam() : DataSet+GetEntityCollection() : DataSet+GetEntityCollectionParam() : DataSet+GetInstanceCollection() : DataSet+GetInstanceCollectionParam() : DataSet+DeleteInstance() : DataSet+AddInstance() : DataSet+AddInstanceAssociation() : DataSet+GetParentCollection() : DataSet+GetParentCollectionParam() : DataSet+GetSchemaCollection() : DataSet+GetValueTypeCollection() : DataSet+GetValueTypeCollectionParam() : DataSet+LoadOWL() : void+LoadOWLS() : void+GetClassSchemaParam() : DataSet+GetOWLSItem() : string+GetOWLSPerform() : string+CheckComplete() : bool+Register() : void+CompleteService() : bool+QuitSession() : void
Blackboard
C# Helper::DataSet
+OWLSProcess()+GetProcessDescription() : string+ControlConstruct() : void+Perform() : void+InputBinding() : void+ValueOf() : void+OutputBinding() : void+Parameter() : void+Input() : void+Output() : void+AtomicProcess() : void+CompositeProcess() : void+Sequence() : void+Produce() : void+ControlConstructList() : void+ControlConstructBag() : void+GetPerform() : int+GetPerforms() : Hashtable
-resultText : short-comp-htb : Hashtable-performCount : int
Process::OWLSProcess
+OWLSParser() : OWLSParser+GetOWLSCollection() : OWLSCollection+GetCompositeProcess() : CompositeProcess
-owlsCollection : OWLSCollection-comp : CompositeProcess
Parser::OWLSParser
DBEntityCollection
+ClassCollection()
Instances::ClassCollection
+ClassSchema()
Instances::ClassSchema
+EntityCollection()
Instances::EntityCollection
+InstanceCollection()
Instances::InstanceCollection
+OWLClassCollection()
Instances::OWLClassCollection
+ParentCollection()
Instances::ParentCollection
+SchemaCollection()
Instances::SchemaCollection
+ValueTypeCollection()
Instances::ValueTypeCollection
+SQLInstance()+GetUniqueId() : int+SetUniqueId() : void+GetParentID() : int+SetParentID() : void+GetSchemaID() : int+SetSchemaID() : void+GetEntity() : string+SetEntity() : void+GetSchemaDomainName() : string+SetSchemaDomainName() : void+GetMvalue() : string+SetMvalue() : void+GetValueType() : string+SetValueType() : void+Delete() : bool+Save() : bool
-uniqueId : int-parentID : int-schemaID : int-entity : string-schemaDomainName : string-mvalue : string-valueType : string
SQLIndividual::SQLInstance
+SQLInstanceAssociation()+GetID() : int+SetID() : void+GetParentID() : int+SetParentID() : void+GetChildID() : int+SetChildID() : void+Delete() : bool+Save() : bool
-id : int-childID : int-parentID : int
SQLIndividual::SQLInstanceAssociation
+SQLEntity() : SQLEntity
-connection : SQLConnection-command : SQLCommand
SQLIndividual::SQLEntity
+BuildSQLSchema() : BuildSQLSchema+GetSqlOwlClasses() : Hashtable-SetSqlOwlClasses() : void+SetSqlFunctionalProperties() : void+SetSqlObjectProperties() : void+SetSqlHasDomains() : void+SetSqlHasRanges() : void
-owlParser : OWLParser-owlClasses : Hashtable-functionalProperties : Hashtable-objectProperties : Hashtable-sqlSchema : SQLSchema-sqlOWLClasses : Hashtable-sqlFunctionalProperties : Hashtable-sqlObjectProperties : Hashtable-sqlHasDomains : Hashtable-sqlHasRanges : Hashtable
Builds::BuildSQLSchema
152
153
154
155
156
157
158
159
D4.2 Coordination Agent
Coordination agent class
D4.3 Data Agent
-Page_Load() : void-btnRegister_Click() : void-btnOWL_Click() : void-btnStart_Click() : void-btnOWLS_Click() : void-btnNext_Click() : void-btnQuit_Click() : void
-strBlackboard : string-session : string-agent : string-url : string-service : string-currentProcess : string
CoordinationAgent
160
Data agent classes
+WSClassCollection()+GetrtDS() : DataSet
-rtDS : DataSetWSClassCollection
C# Helper::DataSet
+Page_Load() : void+btnAddTextBox_PreRender() : void+btnAddTextBox_Click() : void+CreateTextBoxControls() : void+btnSubmitButton_Click() : void+btnSubmitButton_PreRender() : void+btnReset_Click() : void+ddlparentID_SelectedIndexChanged() : void+ddlSchema_SelectedIndexChanged() : void+SetParents() : void+SetSchema() : void+GetPropertyName() : string+GetPropertyType() : string+GetPropertyControl() : string+GetPropertyCount() : int+GetInstanceDS() : DataSet+SaveInstance() : int+SaveInstanceAssociation() : void+ddlClassName_SelectedIndexChanged() : void+dgEntries_PageIndexChanged() : void+dgEntries_ItemCommand() : void+btnComplete_Click() : void
-ds : DataSet-strBlackboard : string-session : string-agent : string-url : string-service : string
DataAgent::DataAgent
+WSClassSchema()+GetrtDS() : DataSet
-rtDS : DataSetWSClassSchema
+WSInstance()+ID()+ParentID()+SchemaID()+Entity()+SchemaDomainName()+Mvalue()+ValueType()+Save()
-id : int-parentID : int-schemaID : int-entity : string-schemaDomainName : string-mvalue : string-valueType : string-rtDS : DataSet
WSInstance
+WSInstanceAssociation()+ID()+ParentID()+ChildID()+Save()
-id : int-parentID : int-childID : int
WSInstanceAssociation
+WSInstanceCollection()+GetrtDS() : DataSet
-rtDS : DataSetWSInstanceCollection
+WSParentCollection()+GetrtDS() : DataSet
-rtDS : DataSetWSParentCollection
+WSSchemaCollection()+GetrtDS() : DataSet
-rtDS : DataSetWSSchemaCollection
161
162
163
D4.4 Service Broker
Service broker class
+ServiceBroker()+GetAgent()
ServiceBroker
164
D4.5 Statistics Agent
165
Appendix E Elicitation Results
Imported Schema
HasSiteCondition ObjectProperty Elicitation http://localhost/SurveySchema.owl
Class Name: SiteCondition
HasSite ObjectProperty GatherSurveyData http://localhost/SurveySchema.owl
Class Name: Site
HasSegmentVariableVariance ObjectProperty Elicitation http://localhost/SurveySchema.owl
Class Name: SegmentVariableVariance
HasSegmentVariable ObjectProperty Elicitation http://localhost/SurveySchema.owl
Class Name: SegmentVariable
HasSegmentFactorVariance ObjectProperty Elicitation http://localhost/SurveySchema.owl
Class Name: SegmentFactorVariance
HasRelevantAspect ObjectProperty Elicitation http://localhost/SurveySchema.owl
HasRelevantAspect ObjectProperty Elicitation http://localhost/SurveySchema.owl
HasRelevantAspect ObjectProperty Elicitation http://localhost/SurveySchema.owl
Class Name: RelevantAspect
InstantiateSurveySchema OWLClass String
Class Name: InstantiateSurveySchema
GatherSurveyData OWLClass String
Class Name: GatherSurveyData
HasFactorLevels ObjectProperty InstantiateSurveySchema http://localhost/SurveySchema.owl
Class Name: FactorLevel
HasFactorAttributes ObjectProperty InstantiateSurveySchema http://localhost/SurveySchema.owl
Class Name: FactorAttribute
HasExpert ObjectProperty Elicitation http://localhost/SurveySchema.owl
Class Name: Expert
Elicitation OWLClass String
Class Name: Elicitation
Schema Name: http://localhost/SurveySchema.owl
property name type range range schema name
Imported Schema
maximumValue DatatypeProperty float http://www.w3.org/2001/XMLSchema
IsRelevantVariable ObjectProperty VariableAttribute http://localhost/SurveyData.owl
RelevantVariable OWLClass String
minimumValue DatatypeProperty float http://www.w3.org/2001/XMLSchema
Class Name: RelevantVariable
IsRelevantFactor ObjectProperty FactorAttribute http://localhost/SurveyData.owl
HasFixedSegment ObjectProperty SegmentFactorVariance http://localhost/Elicitation.owl
RelevantFactorLevel OWLClass String
IsRelevantFactorLevel ObjectProperty FactorLevel http://localhost/SurveyData.owl
rankProbability DatatypeProperty float http://www.w3.org/2001/XMLSchema
rank DatatypeProperty int http://www.w3.org/2001/XMLSchema
Class Name: RelevantFactorLevel
HasRelevantAspect ObjectProperty Species http://localhost/Elicitation.owl
HasRelevantAspect ObjectProperty Species http://localhost/Elicitation.owl
RelevantAspect OWLClass String
HasRelevantAspect ObjectProperty Species http://localhost/Elicitation.owl
Class Name: RelevantAspect
Expert OWLClass String
Class Name: Expert
Schema Name: http://localhost/Elicitation.owl
HasVariableAttributes ObjectProperty InstantiateSurveySchema http://localhost/SurveySchema.owl
Class Name: VariableAttribute
HasSurveyVariableData ObjectProperty GatherSurveyData http://localhost/SurveySchema.owl
Class Name: SurveyVariableData
HasSurveyFactorData ObjectProperty GatherSurveyData http://localhost/SurveySchema.owl
Class Name: SurveyFactorData
HasSurvey ObjectProperty InstantiateSurveySchema http://localhost/SurveySchema.owl
Class Name: Survey
HasSpecies ObjectProperty Elicitation http://localhost/SurveySchema.owl
Class Name: Species
property name type range range schema name
Imported Schema
Species OWLClass String
AssessesSpecies ObjectProperty Expert http://localhost/Elicitation.owl
Class Name: Species
lowerEstimate DatatypeProperty float http://www.w3.org/2001/XMLSchema
HasProbabilityOfPresence ObjectProperty Species http://localhost/Elicitation.owl
SiteCondition OWLClass String
upperEstimate DatatypeProperty float http://www.w3.org/2001/XMLSchema
medianEstimate DatatypeProperty float http://www.w3.org/2001/XMLSchema
Class Name: SiteCondition
HasRangeVarSegment ObjectProperty SegmentVariable http://localhost/Elicitation.owl
rangeSegment ObjectProperty SegmentVariable http://localhost/Elicitation.owl
SegmentVariableVariance OWLClass String
fixedSegment ObjectProperty SegmentVariable http://localhost/Elicitation.owl
upperMedian DatatypeProperty float http://www.w3.org/2001/XMLSchema
sequence DatatypeProperty int http://www.w3.org/2001/XMLSchema
lowerMedian DatatypeProperty float http://www.w3.org/2001/XMLSchema
Class Name: SegmentVariableVariance
HasSegmentVariable ObjectProperty RelevantVariable http://localhost/Elicitation.owl
HasFixedVarSegment ObjectProperty SegmentVariableVariance http://localhost/Elicitation.owl
SegmentVariable OWLClass String
position DatatypeProperty int http://www.w3.org/2001/XMLSchema
segmentValue DatatypeProperty float http://www.w3.org/2001/XMLSchema
segmentProbabilityOfPresence DatatypeProperty float http://www.w3.org/2001/XMLSchema
Class Name: SegmentVariable
HasRangeSegment ObjectProperty RelevantFactorLevel http://localhost/Elicitation.owl
rangeSegmentf ObjectProperty RelevantFactorLevel http://localhost/Elicitation.owl
SegmentFactorVariance OWLClass String
fixedSegmentf ObjectProperty RelevantFactorLevel http://localhost/Elicitation.owl
upperMedianf DatatypeProperty float http://www.w3.org/2001/XMLSchema
sequencef DatatypeProperty string http://www.w3.org/2001/XMLSchema
lowerMedianf DatatypeProperty float http://www.w3.org/2001/XMLSchema
Class Name: SegmentFactorVariance
optimumProbability DatatypeProperty float http://www.w3.org/2001/XMLSchema
optimumValue DatatypeProperty float http://www.w3.org/2001/XMLSchema
property name type range range schema name
Imported Schema
HasSurveyVariableData ObjectProperty Site http://localhost/SurveyData.owl
SurveyVariableData OWLClass String
Class Name: SurveyVariableData
HasFactorData ObjectProperty FactorLevel http://localhost/SurveyData.owl
SurveyFactorData OWLClass String
HasSurveyedFactorData ObjectProperty Site http://localhost/SurveyData.owl
levelValue DatatypeProperty int http://www.w3.org/2001/XMLSchema
Class Name: SurveyFactorData
Survey OWLClass String
surveyName DatatypeProperty string http://www.w3.org/2001/XMLSchema
Class Name: Survey
string OWLClass String
Class Name: string
Site OWLClass String
siteName DatatypeProperty string http://www.w3.org/2001/XMLSchema
Class Name: Site
int OWLClass String
Class Name: int
float OWLClass String
Class Name: float
HasLevel ObjectProperty FactorAttribute http://localhost/SurveyData.owl
FactorLevel OWLClass String
level DatatypeProperty int http://www.w3.org/2001/XMLSchema
levelName DatatypeProperty string http://www.w3.org/2001/XMLSchema
Class Name: FactorLevel
HasFactor ObjectProperty Survey http://localhost/SurveyData.owl
FactorAttribute OWLClass String
factorDescription DatatypeProperty string http://www.w3.org/2001/XMLSchema
factorName DatatypeProperty string http://www.w3.org/2001/XMLSchema
Class Name: FactorAttribute
Schema Name: http://localhost/SurveyData.owl
property name type range range schema name
Imported Schema
minimum DatatypeProperty float http://www.w3.org/2001/XMLSchema
maximum DatatypeProperty float http://www.w3.org/2001/XMLSchema
HasVariable ObjectProperty Survey http://localhost/SurveyData.owl
variableName DatatypeProperty string http://www.w3.org/2001/XMLSchema
variableDescription DatatypeProperty string http://www.w3.org/2001/XMLSchema
unit DatatypeProperty string http://www.w3.org/2001/XMLSchema
VariableAttribute OWLClass String
Class Name: VariableAttribute
HasVariableData ObjectProperty VariableAttribute http://localhost/SurveyData.owl
variableValue DatatypeProperty float http://www.w3.org/2001/XMLSchema
property name type range range schema name
M801 - Suvey Data
Class: Elicitation
functional Property Name type range value
Elicitation OWLClass String M801 Sample Elicitation
Class: Expert
Expert OWLClass String M801 Sample Expert
HasExpert ObjectProperty Elicitation M801 Sample Elicitation
Class: FactorAttribute
FactorAttribute OWLClass String Slope position
HasFactor ObjectProperty Survey M801 Fauna Survey
HasFactorAttributes ObjectProperty InstantiateSurveySchema M801 OWL/S Statistics Exercise
factorDescription DatatypeProperty string Slope position
factorName DatatypeProperty string Slope position
FactorAttribute OWLClass String Forest Structure
HasFactor ObjectProperty Survey M801 Fauna Survey
HasFactorAttributes ObjectProperty InstantiateSurveySchema M801 OWL/S Statistics Exercise
factorDescription DatatypeProperty string Forest Structure
factorName DatatypeProperty string Forest Structure
FactorAttribute OWLClass String Present of Road
HasFactor ObjectProperty Survey M801 Fauna Survey
HasFactorAttributes ObjectProperty InstantiateSurveySchema M801 OWL/S Statistics Exercise
factorDescription DatatypeProperty string Present of Road
factorName DatatypeProperty string Present of Road
FactorAttribute OWLClass String Grazing
HasFactor ObjectProperty Survey M801 Fauna Survey
HasFactorAttributes ObjectProperty InstantiateSurveySchema M801 OWL/S Statistics Exercise
M801 - Suvey Data
Class: FactorAttribute
functional Property Name type range value
factorDescription DatatypeProperty string Grazing
factorName DatatypeProperty string Grazing
FactorAttribute OWLClass String Vegetation Type
HasFactor ObjectProperty Survey M801 Fauna Survey
HasFactorAttributes ObjectProperty InstantiateSurveySchema M801 OWL/S Statistics Exercise
factorDescription DatatypeProperty string Vegetation Type
factorName DatatypeProperty string Vegetation Type
FactorAttribute OWLClass String Land Zone Classes
HasFactor ObjectProperty Survey M801 Fauna Survey
HasFactorAttributes ObjectProperty InstantiateSurveySchema M801 OWL/S Statistics Exercise
factorDescription DatatypeProperty string Land Zone Classes
factorName DatatypeProperty string Land Zone Classes
FactorAttribute OWLClass String Fire Disturbance
HasFactor ObjectProperty Survey M801 Fauna Survey
HasFactorAttributes ObjectProperty InstantiateSurveySchema M801 OWL/S Statistics Exercise
factorDescription DatatypeProperty string Fire Disturbance
factorName DatatypeProperty string Fire Disturbance
FactorAttribute OWLClass String Logging Disturbance
HasFactor ObjectProperty Survey M801 Fauna Survey
HasFactorAttributes ObjectProperty InstantiateSurveySchema M801 OWL/S Statistics Exercise
factorDescription DatatypeProperty string Logging Disturbance
factorName DatatypeProperty string Logging Disturbance
Class: FactorLevel
FactorLevel OWLClass String 1 : Ridge;
HasFactorLevels ObjectProperty InstantiateSurveySchema M801 OWL/S Statistics Exercise
HasLevel ObjectProperty FactorAttribute Slope position
M801 - Suvey Data
Class: FactorLevel
functional Property Name type range value
level DatatypeProperty int 1
levelName DatatypeProperty string 1 : Ridge;
FactorLevel OWLClass String 2: Mid;
HasFactorLevels ObjectProperty InstantiateSurveySchema M801 OWL/S Statistics Exercise
HasLevel ObjectProperty FactorAttribute Slope position
level DatatypeProperty int 2
levelName DatatypeProperty string 2: Mid;
FactorLevel OWLClass String 3: Gulley.
HasFactorLevels ObjectProperty InstantiateSurveySchema M801 OWL/S Statistics Exercise
HasLevel ObjectProperty FactorAttribute Slope position
level DatatypeProperty int 3
levelName DatatypeProperty string 3: Gulley.
FactorLevel OWLClass String 1 : senescent;
HasFactorLevels ObjectProperty InstantiateSurveySchema M801 OWL/S Statistics Exercise
HasLevel ObjectProperty FactorAttribute Forest Structure
level DatatypeProperty int 1
levelName DatatypeProperty string 1 : senescent;
FactorLevel OWLClass String 2 : mature;
HasFactorLevels ObjectProperty InstantiateSurveySchema M801 OWL/S Statistics Exercise
HasLevel ObjectProperty FactorAttribute Forest Structure
level DatatypeProperty int 2
levelName DatatypeProperty string 2 : mature;
FactorLevel OWLClass String 3 : regenerate.
HasFactorLevels ObjectProperty InstantiateSurveySchema M801 OWL/S Statistics Exercise
HasLevel ObjectProperty FactorAttribute Forest Structure
level DatatypeProperty int 3
M801 - Suvey Data
Class: FactorLevel
functional Property Name type range value
levelName DatatypeProperty string 3 : regenerate.
FactorLevel OWLClass String 1 : present;
HasFactorLevels ObjectProperty InstantiateSurveySchema M801 OWL/S Statistics Exercise
HasLevel ObjectProperty FactorAttribute Present of Road
level DatatypeProperty int 1
levelName DatatypeProperty string 1 : present;
FactorLevel OWLClass String 0 : absent.
HasFactorLevels ObjectProperty InstantiateSurveySchema M801 OWL/S Statistics Exercise
HasLevel ObjectProperty FactorAttribute Present of Road
level DatatypeProperty int 0
levelName DatatypeProperty string 0 : absent.
FactorLevel OWLClass String 1 : no grazing;
HasFactorLevels ObjectProperty InstantiateSurveySchema M801 OWL/S Statistics Exercise
HasLevel ObjectProperty FactorAttribute Grazing
level DatatypeProperty int 1
levelName DatatypeProperty string 1 : no grazing;
FactorLevel OWLClass String 0 : grazing.
HasFactorLevels ObjectProperty InstantiateSurveySchema M801 OWL/S Statistics Exercise
HasLevel ObjectProperty FactorAttribute Grazing
level DatatypeProperty int 0
levelName DatatypeProperty string 0 : grazing.
FactorLevel OWLClass String 1a: wet forest with E.saligna, E. microcorys, E.cl
HasFactorLevels ObjectProperty InstantiateSurveySchema M801 OWL/S Statistics Exercise
HasLevel ObjectProperty FactorAttribute Vegetation Type
level DatatypeProperty int 1a
levelName DatatypeProperty string 1a: wet forest with E.saligna, E. microcorys, E.cl
M801 - Suvey Data
Class: FactorLevel
functional Property Name type range value
FactorLevel OWLClass String 1b: E.saligna, dominated by wet forest;
HasFactorLevels ObjectProperty InstantiateSurveySchema M801 OWL/S Statistics Exercise
HasLevel ObjectProperty FactorAttribute Vegetation Type
level DatatypeProperty int 1b
levelName DatatypeProperty string 1b: E.saligna, dominated by wet forest;
FactorLevel OWLClass String 2 : wet to mix dominated by E. piluralis;
HasFactorLevels ObjectProperty InstantiateSurveySchema M801 OWL/S Statistics Exercise
HasLevel ObjectProperty FactorAttribute Vegetation Type
level DatatypeProperty int 2
levelName DatatypeProperty string 2 : wet to mix dominated by E. piluralis;
FactorLevel OWLClass String 3a: higher quality dry forests dominated by C.citr
HasFactorLevels ObjectProperty InstantiateSurveySchema M801 OWL/S Statistics Exercise
HasLevel ObjectProperty FactorAttribute Vegetation Type
level DatatypeProperty int 3a
levelName DatatypeProperty string 3a: higher quality dry forests dominated by C.citr
FactorLevel OWLClass String 3b: lower quality dry forest dominated by C. citri
HasFactorLevels ObjectProperty InstantiateSurveySchema M801 OWL/S Statistics Exercise
HasLevel ObjectProperty FactorAttribute Vegetation Type
level DatatypeProperty int 3b
levelName DatatypeProperty string 3b: lower quality dry forest dominated by C. citri
FactorLevel OWLClass String 4a: mixed dry forest with E.siderophloia, E.propin
HasFactorLevels ObjectProperty InstantiateSurveySchema M801 OWL/S Statistics Exercise
HasLevel ObjectProperty FactorAttribute Vegetation Type
level DatatypeProperty int 4a
levelName DatatypeProperty string 4a: mixed dry forest with E.siderophloia, E.propin
FactorLevel OWLClass String 4: E. tereticomis on alluvial lowlands;
M801 - Suvey Data
Class: FactorLevel
functional Property Name type range value
HasFactorLevels ObjectProperty InstantiateSurveySchema M801 OWL/S Statistics Exercise
HasLevel ObjectProperty FactorAttribute Vegetation Type
level DatatypeProperty int 4
levelName DatatypeProperty string 4: E. tereticomis on alluvial lowlands;
FactorLevel OWLClass String 5a: coast dry eucalypt forest dominated by E. race
HasFactorLevels ObjectProperty InstantiateSurveySchema M801 OWL/S Statistics Exercise
HasLevel ObjectProperty FactorAttribute Vegetation Type
level DatatypeProperty int 5a
levelName DatatypeProperty string 5a: coast dry eucalypt forest dominated by E. race
FactorLevel OWLClass String 5b: dry western forests including ironbark forest
HasFactorLevels ObjectProperty InstantiateSurveySchema M801 OWL/S Statistics Exercise
HasLevel ObjectProperty FactorAttribute Vegetation Type
level DatatypeProperty int 5b
levelName DatatypeProperty string 5b: dry western forests including ironbark forest
FactorLevel OWLClass String 6a: upland cool rainforest;
HasFactorLevels ObjectProperty InstantiateSurveySchema M801 OWL/S Statistics Exercise
HasLevel ObjectProperty FactorAttribute Vegetation Type
level DatatypeProperty int 6a
levelName DatatypeProperty string 6a: upland cool rainforest;
FactorLevel OWLClass String 6b: lowland cool rainforest;
HasFactorLevels ObjectProperty InstantiateSurveySchema M801 OWL/S Statistics Exercise
HasLevel ObjectProperty FactorAttribute Vegetation Type
level DatatypeProperty int 6b
levelName DatatypeProperty string 6b: lowland cool rainforest;
FactorLevel OWLClass String 6c: auraucaria dominated rainforest;
HasFactorLevels ObjectProperty InstantiateSurveySchema M801 OWL/S Statistics Exercise
HasLevel ObjectProperty FactorAttribute Vegetation Type
M801 - Suvey Data
Class: FactorLevel
functional Property Name type range value
level DatatypeProperty int 6c
levelName DatatypeProperty string 6c: auraucaria dominated rainforest;
FactorLevel OWLClass String 6d: vine forest;
HasFactorLevels ObjectProperty InstantiateSurveySchema M801 OWL/S Statistics Exercise
HasLevel ObjectProperty FactorAttribute Vegetation Type
level DatatypeProperty int 6d
levelName DatatypeProperty string 6d: vine forest;
FactorLevel OWLClass String 7: rain forest with eucalypt;
HasFactorLevels ObjectProperty InstantiateSurveySchema M801 OWL/S Statistics Exercise
HasLevel ObjectProperty FactorAttribute Vegetation Type
level DatatypeProperty int 7
levelName DatatypeProperty string 7: rain forest with eucalypt;
FactorLevel OWLClass String 8a: melaleuca woodlands;
HasFactorLevels ObjectProperty InstantiateSurveySchema M801 OWL/S Statistics Exercise
HasLevel ObjectProperty FactorAttribute Vegetation Type
level DatatypeProperty int 8a
levelName DatatypeProperty string 8a: melaleuca woodlands;
FactorLevel OWLClass String 8b: other non-eucalypt dominated by forest and
HasFactorLevels ObjectProperty InstantiateSurveySchema M801 OWL/S Statistics Exercise
HasLevel ObjectProperty FactorAttribute Vegetation Type
level DatatypeProperty int 8b
levelName DatatypeProperty string 8b: other non-eucalypt dominated by forest and
FactorLevel OWLClass String 9: non-eucalypt non-forest vegetation (healthland,
HasFactorLevels ObjectProperty InstantiateSurveySchema M801 OWL/S Statistics Exercise
HasLevel ObjectProperty FactorAttribute Vegetation Type
level DatatypeProperty int 9
M801 - Suvey Data
Class: FactorLevel
functional Property Name type range value
levelName DatatypeProperty string 9: non-eucalypt non-forest vegetation (healthland,
FactorLevel OWLClass String 10: non-vegetarian (sand-blows, water bodies, clea
HasFactorLevels ObjectProperty InstantiateSurveySchema M801 OWL/S Statistics Exercise
HasLevel ObjectProperty FactorAttribute Vegetation Type
level DatatypeProperty int 10
levelName DatatypeProperty string 10: non-vegetarian (sand-blows, water bodies, clea
FactorLevel OWLClass String 11: plantations (hoop and exotic);
HasFactorLevels ObjectProperty InstantiateSurveySchema M801 OWL/S Statistics Exercise
HasLevel ObjectProperty FactorAttribute Vegetation Type
level DatatypeProperty int 11
levelName DatatypeProperty string 11: plantations (hoop and exotic);
FactorLevel OWLClass String 12: mixed eucalypts;
HasFactorLevels ObjectProperty InstantiateSurveySchema M801 OWL/S Statistics Exercise
HasLevel ObjectProperty FactorAttribute Vegetation Type
level DatatypeProperty int 12
levelName DatatypeProperty string 12: mixed eucalypts;
FactorLevel OWLClass String 13: others.
HasFactorLevels ObjectProperty InstantiateSurveySchema M801 OWL/S Statistics Exercise
HasLevel ObjectProperty FactorAttribute Vegetation Type
level DatatypeProperty int 13
levelName DatatypeProperty string 13: others.
FactorLevel OWLClass String 1: quartenary saline alluvial;
HasFactorLevels ObjectProperty InstantiateSurveySchema M801 OWL/S Statistics Exercise
HasLevel ObjectProperty FactorAttribute Land Zone Classes
level DatatypeProperty int 1
levelName DatatypeProperty string 1: quartenary saline alluvial;
M801 - Suvey Data
Class: FactorLevel
functional Property Name type range value
FactorLevel OWLClass String 2: quarterly dune sands and coastal sediments;
HasFactorLevels ObjectProperty InstantiateSurveySchema M801 OWL/S Statistics Exercise
HasLevel ObjectProperty FactorAttribute Land Zone Classes
level DatatypeProperty int 2
levelName DatatypeProperty string 2: quarterly dune sands and coastal sediments;
FactorLevel OWLClass String 3: alluvial plains;
HasFactorLevels ObjectProperty InstantiateSurveySchema M801 OWL/S Statistics Exercise
HasLevel ObjectProperty FactorAttribute Land Zone Classes
level DatatypeProperty int 3
levelName DatatypeProperty string 3: alluvial plains;
FactorLevel OWLClass String 5: Cainozoic sand plains and remnant surfaces with
HasFactorLevels ObjectProperty InstantiateSurveySchema M801 OWL/S Statistics Exercise
HasLevel ObjectProperty FactorAttribute Land Zone Classes
level DatatypeProperty int 5
levelName DatatypeProperty string 5: Cainozoic sand plains and remnant surfaces with
FactorLevel OWLClass String 8: Cainozoic igneous rocks; some limited valley ba
HasFactorLevels ObjectProperty InstantiateSurveySchema M801 OWL/S Statistics Exercise
HasLevel ObjectProperty FactorAttribute Land Zone Classes
level DatatypeProperty int 8
levelName DatatypeProperty string 8: Cainozoic igneous rocks; some limited valley ba
FactorLevel OWLClass String 9/10: coarse and fine grained sedimentary rocks
HasFactorLevels ObjectProperty InstantiateSurveySchema M801 OWL/S Statistics Exercise
HasLevel ObjectProperty FactorAttribute Land Zone Classes
level DatatypeProperty int 9
levelName DatatypeProperty string 9/10: coarse and fine grained sedimentary rocks
FactorLevel OWLClass String 11: Permian age and older sedimentary rocks that h
M801 - Suvey Data
Class: FactorLevel
functional Property Name type range value
HasFactorLevels ObjectProperty InstantiateSurveySchema M801 OWL/S Statistics Exercise
HasLevel ObjectProperty FactorAttribute Land Zone Classes
level DatatypeProperty int 11
levelName DatatypeProperty string 11: Permian age and older sedimentary rocks that h
FactorLevel OWLClass String 12: pre-Cainozoic igneous rocks;
HasFactorLevels ObjectProperty InstantiateSurveySchema M801 OWL/S Statistics Exercise
HasLevel ObjectProperty FactorAttribute Land Zone Classes
level DatatypeProperty int 12
levelName DatatypeProperty string 12: pre-Cainozoic igneous rocks;
FactorLevel OWLClass String 13: others.;
HasFactorLevels ObjectProperty InstantiateSurveySchema M801 OWL/S Statistics Exercise
HasLevel ObjectProperty FactorAttribute Land Zone Classes
level DatatypeProperty int 13
levelName DatatypeProperty string 13: others.
FactorLevel OWLClass String 1: wild fire;
HasFactorLevels ObjectProperty InstantiateSurveySchema M801 OWL/S Statistics Exercise
HasLevel ObjectProperty FactorAttribute Fire Disturbance
level DatatypeProperty int 1
levelName DatatypeProperty string 1: wild fire;
FactorLevel OWLClass String 2: controlled burn;
HasFactorLevels ObjectProperty InstantiateSurveySchema M801 OWL/S Statistics Exercise
HasLevel ObjectProperty FactorAttribute Fire Disturbance
level DatatypeProperty int 2
levelName DatatypeProperty string 2: controlled burn;
FactorLevel OWLClass String 3: no recent fire.
HasFactorLevels ObjectProperty InstantiateSurveySchema M801 OWL/S Statistics Exercise
HasLevel ObjectProperty FactorAttribute Fire Disturbance
M801 - Suvey Data
Class: FactorLevel
functional Property Name type range value
level DatatypeProperty int 3
levelName DatatypeProperty string 3: no recent fire.
FactorLevel OWLClass String 1: virgin;
HasFactorLevels ObjectProperty InstantiateSurveySchema M801 OWL/S Statistics Exercise
HasLevel ObjectProperty FactorAttribute Logging Disturbance
level DatatypeProperty int 1
levelName DatatypeProperty string 1: virgin;
FactorLevel OWLClass String 2: nothing since 1950;;
HasFactorLevels ObjectProperty InstantiateSurveySchema M801 OWL/S Statistics Exercise
HasLevel ObjectProperty FactorAttribute Logging Disturbance
level DatatypeProperty int 2
levelName DatatypeProperty string 2: nothing since 1950;;
FactorLevel OWLClass String 3: saw logging;
HasFactorLevels ObjectProperty InstantiateSurveySchema M801 OWL/S Statistics Exercise
HasLevel ObjectProperty FactorAttribute Logging Disturbance
level DatatypeProperty int 3
levelName DatatypeProperty string 3: saw logging;
FactorLevel OWLClass String 4: other logging.;
HasFactorLevels ObjectProperty InstantiateSurveySchema M801 OWL/S Statistics Exercise
HasLevel ObjectProperty FactorAttribute Logging Disturbance
level DatatypeProperty int 4
levelName DatatypeProperty string 4: other logging.
Class: GatherSurveyData
GatherSurveyData OWLClass String M801 Sample Survey Data
M801 - Suvey Data
Class: InstantiateSurveySchema
functional Property Name type range value
InstantiateSurveySchema OWLClass String M801 OWL/S Statistics Exercise
Class: RelevantFactorLevel
RelevantFactorLevel OWLClass String Species A Slope 1
HasRelevantAspect ObjectProperty Elicitation M801 Sample Elicitation
HasRelevantAspect ObjectProperty Species Species A
IsRelevantFactor ObjectProperty FactorAttribute Slope position
IsRelevantFactorLevel ObjectProperty FactorLevel 1 : Ridge;
rank DatatypeProperty int 1
rankProbability DatatypeProperty float 24
RelevantFactorLevel OWLClass String Species A Slope 2
HasRelevantAspect ObjectProperty Elicitation M801 Sample Elicitation
HasRelevantAspect ObjectProperty Species Species A
IsRelevantFactor ObjectProperty FactorAttribute Slope position
IsRelevantFactorLevel ObjectProperty FactorLevel 2: Mid;
rank DatatypeProperty int 1
rankProbability DatatypeProperty float 12
RelevantFactorLevel OWLClass String Species A Slope 3
HasRelevantAspect ObjectProperty Elicitation M801 Sample Elicitation
HasRelevantAspect ObjectProperty Species Species A
IsRelevantFactor ObjectProperty FactorAttribute Slope position
IsRelevantFactorLevel ObjectProperty FactorLevel 3: Gulley.
rank DatatypeProperty int 3
rankProbability DatatypeProperty float 2
Class: RelevantVariable
RelevantVariable OWLClass String Species A Rain in Driest Quarter
HasRelevantAspect ObjectProperty Elicitation M801 Sample Elicitation
M801 - Suvey Data
Class: RelevantVariable
functional Property Name type range value
HasRelevantAspect ObjectProperty Species Species A
IsRelevantVariable ObjectProperty VariableAttribute Rain in Driest Quarter
maximumValue DatatypeProperty float 200
minimumValue DatatypeProperty float 10
optimumProbability DatatypeProperty float 50
optimumValue DatatypeProperty float 75
RelevantVariable OWLClass String Species A Rain in Wettest Quarter
HasRelevantAspect ObjectProperty Elicitation M801 Sample Elicitation
HasRelevantAspect ObjectProperty Species Species A
IsRelevantVariable ObjectProperty VariableAttribute Rain in Wettest Quarter
maximumValue DatatypeProperty float 600
minimumValue DatatypeProperty float 100
optimumProbability DatatypeProperty float 450
optimumValue DatatypeProperty float 64
RelevantVariable OWLClass String Species A Elevation
HasRelevantAspect ObjectProperty Elicitation M801 Sample Elicitation
HasRelevantAspect ObjectProperty Species Species A
IsRelevantVariable ObjectProperty VariableAttribute Elevation
maximumValue DatatypeProperty float 2000
minimumValue DatatypeProperty float 0
optimumProbability DatatypeProperty float 1000
optimumValue DatatypeProperty float 76
RelevantVariable OWLClass String Species A Slope
HasRelevantAspect ObjectProperty Elicitation M801 Sample Elicitation
HasRelevantAspect ObjectProperty Species Species A
IsRelevantVariable ObjectProperty VariableAttribute Slope
maximumValue DatatypeProperty float 20
minimumValue DatatypeProperty float 0
optimumProbability DatatypeProperty float 7
optimumValue DatatypeProperty float 65
M801 - Suvey Data
Class: RelevantVariable
functional Property Name type range value
RelevantVariable OWLClass String Species A Aspect
HasRelevantAspect ObjectProperty Elicitation M801 Sample Elicitation
HasRelevantAspect ObjectProperty Species Species A
IsRelevantVariable ObjectProperty VariableAttribute Aspect
maximumValue DatatypeProperty float 360
minimumValue DatatypeProperty float 150
optimumProbability DatatypeProperty float 225
optimumValue DatatypeProperty float 78
RelevantVariable OWLClass String Species A Average Winter Temperature
HasRelevantAspect ObjectProperty Elicitation M801 Sample Elicitation
HasRelevantAspect ObjectProperty Species Species A
IsRelevantVariable ObjectProperty VariableAttribute Average Winter Temperature
maximumValue DatatypeProperty float 10
minimumValue DatatypeProperty float 0
optimumProbability DatatypeProperty float 7
optimumValue DatatypeProperty float 78
RelevantVariable OWLClass String Species A Average Summer Temperature
HasRelevantAspect ObjectProperty Elicitation M801 Sample Elicitation
HasRelevantAspect ObjectProperty Species Species A
IsRelevantVariable ObjectProperty VariableAttribute Average Summer Temperature
maximumValue DatatypeProperty float 40
minimumValue DatatypeProperty float 15
optimumProbability DatatypeProperty float 27
optimumValue DatatypeProperty float 67
RelevantVariable OWLClass String Species A Degree of Canopy Cover
HasRelevantAspect ObjectProperty Elicitation M801 Sample Elicitation
HasRelevantAspect ObjectProperty Species Species A
IsRelevantVariable ObjectProperty VariableAttribute Average Summer Temperature
maximumValue DatatypeProperty float 5
minimumValue DatatypeProperty float 1
M801 - Suvey Data
functional Property Name type range value
Class: RelevantVariable
optimumProbability DatatypeProperty float 3
optimumValue DatatypeProperty float 78
Class: SegmentVariable
SegmentVariable OWLClass String Species A Rain In Driest Quarter Median Ass 1
HasSegmentVariable ObjectProperty Elicitation M801 Sample Elicitation
HasSegmentVariable ObjectProperty RelevantVariable Species A Rain in Driest Quarter
position DatatypeProperty int 1
segmentProbabilityOfPresenc DatatypeProperty float 0.15 e
segmentValue DatatypeProperty float 0
SegmentVariable OWLClass String Species A Rain In Driest Quarter Median Ass 2
HasSegmentVariable ObjectProperty Elicitation M801 Sample Elicitation
HasSegmentVariable ObjectProperty RelevantVariable Species A Rain in Driest Quarter
position DatatypeProperty int 2
segmentProbabilityOfPresenc DatatypeProperty float 0.45 e
segmentValue DatatypeProperty float 15
SegmentVariable OWLClass String Species A Rain In Driest Quarter Median Ass 3
HasSegmentVariable ObjectProperty Elicitation M801 Sample Elicitation
HasSegmentVariable ObjectProperty RelevantVariable Species A Rain in Driest Quarter
SegmentVariable OWLClass String Species A Rain In Driest Quarter Median Ass 4
HasSegmentVariable ObjectProperty Elicitation M801 Sample Elicitation
HasSegmentVariable ObjectProperty RelevantVariable Species A Rain in Driest Quarter
position DatatypeProperty int 4
segmentProbabilityOfPresenc DatatypeProperty float 0.71 e
segmentValue DatatypeProperty float 45
SegmentVariable OWLClass String Species A Rain In Driest Quarter Median Ass 5
M801 - Suvey Data
functional Property Name type range value
Class: SegmentVariable
HasSegmentVariable ObjectProperty Elicitation M801 Sample Elicitation
HasSegmentVariable ObjectProperty RelevantVariable Species A Rain in Driest Quarter
position DatatypeProperty int 5
segmentProbabilityOfPresenc DatatypeProperty float 0.68 e
segmentValue DatatypeProperty float 63.3
SegmentVariable OWLClass String Species A Rain In Driest Quarter Median Ass 6
HasSegmentVariable ObjectProperty Elicitation M801 Sample Elicitation
HasSegmentVariable ObjectProperty RelevantVariable Species A Rain in Driest Quarter
position DatatypeProperty int 6
segmentProbabilityOfPresenc DatatypeProperty float 0.62 e
segmentValue DatatypeProperty float 81.7
SegmentVariable OWLClass String Species A Rain In Driest Quarter Median Ass 7
HasSegmentVariable ObjectProperty Elicitation M801 Sample Elicitation
HasSegmentVariable ObjectProperty RelevantVariable Species A Rain in Driest Quarter
position DatatypeProperty int 7
segmentProbabilityOfPresenc DatatypeProperty float 0.60 e
segmentValue DatatypeProperty float 100
Class: SegmentVariableVariance
SegmentVariableVariance OWLClass String Species A Rain in DQ Fixed 4 Range 0 Point 1
rangeSegment ObjectProperty SegmentVariable Species A Rain In Driest Quarter Median Ass 3
fixedSegment ObjectProperty SegmentVariable Species A Rain In Driest Quarter Median Ass 4
HasRangeVarSegment ObjectProperty SegmentVariable Species A Rain In Driest Quarter Median Ass 1
HasSegmentVariableVariance ObjectProperty Elicitation M801 Sample Elicitation
lowerMedian DatatypeProperty float 0
sequence DatatypeProperty int 1
upperMedian DatatypeProperty float 4
SegmentVariableVariance OWLClass String Species A Rain in DQ Fixed 4 Range 0 Point 2
M801 - Suvey Data
Class: SegmentVariableVariance
functional Property Name type range value
fixedSegment ObjectProperty SegmentVariable Species A Rain In Driest Quarter Median Ass 4
HasRangeVarSegment ObjectProperty SegmentVariable Species A Rain In Driest Quarter Median Ass 1
HasSegmentVariableVariance ObjectProperty Elicitation M801 Sample Elicitation
rangeSegment ObjectProperty SegmentVariable Species A Rain In Driest Quarter Median Ass 2
lowerMedian DatatypeProperty float 0
sequence DatatypeProperty int 1
upperMedian DatatypeProperty float 4
SegmentVariableVariance OWLClass String Species A Rain in DQ Fixed 3 Range 0 Point 1
fixedSegment ObjectProperty SegmentVariable Species A Rain In Driest Quarter Median Ass 3
HasRangeVarSegment ObjectProperty SegmentVariable Species A Rain In Driest Quarter Median Ass 2
HasSegmentVariableVariance ObjectProperty Elicitation M801 Sample Elicitation
rangeSegment ObjectProperty SegmentVariable Species A Rain In Driest Quarter Median Ass 1
lowerMedian DatatypeProperty float 0
sequence DatatypeProperty int 1
upperMedian DatatypeProperty float 4
SegmentVariableVariance OWLClass String Species A Rain in DQ Fixed 3 Range 0 Point 2
rangeSegment ObjectProperty SegmentVariable Species A Rain In Driest Quarter Median Ass 1
fixedSegment ObjectProperty SegmentVariable Species A Rain In Driest Quarter Median Ass 3
HasRangeVarSegment ObjectProperty SegmentVariable Species A Rain In Driest Quarter Median Ass 1
HasSegmentVariableVariance ObjectProperty Elicitation M801 Sample Elicitation
lowerMedian DatatypeProperty float 0
sequence DatatypeProperty int 1
upperMedian DatatypeProperty float 4
SegmentVariableVariance OWLClass String Species A Rain in DQ Fixed 2 Range 0 Point 1
fixedSegment ObjectProperty SegmentVariable Species A Rain In Driest Quarter Median Ass 2
HasRangeVarSegment ObjectProperty SegmentVariable Species A Rain In Driest Quarter Median Ass 1
HasSegmentVariableVariance ObjectProperty Elicitation M801 Sample Elicitation
rangeSegment ObjectProperty SegmentVariable Species A Rain In Driest Quarter Median Ass 1
lowerMedian DatatypeProperty float 0
sequence DatatypeProperty int 1
M801 - Suvey Data
Class: SegmentVariableVariance
functional Property Name type range value
upperMedian DatatypeProperty float 4
Class: Site
Site OWLClass String Site A
HasSite ObjectProperty GatherSurveyData M801 Sample Survey Data
siteName DatatypeProperty string M801 Site A
Site OWLClass String Site B
HasSite ObjectProperty GatherSurveyData M801 Sample Survey Data
siteName DatatypeProperty string M801 Site B
Class: SiteCondition
SiteCondition OWLClass String Optimum Site Condition Species A
HasProbabilityOfPresence ObjectProperty Species Species A
HasSiteCondition ObjectProperty Elicitation M801 Sample Elicitation
lowerEstimate DatatypeProperty float 25
medianEstimate DatatypeProperty float 50
upperEstimate DatatypeProperty float 75
Class: Species
Species OWLClass String Species A
AssessesSpecies ObjectProperty Expert M801 Sample Expert
HasSpecies ObjectProperty Elicitation M801 Sample Elicitation
Class: Survey
Survey OWLClass String M801 Fauna Survey
HasSurvey ObjectProperty InstantiateSurveySchema M801 OWL/S Statistics Exercise
M801 - Suvey Data
Class: Survey
functional Property Name type range value
surveyName DatatypeProperty string Example survey, schema, data & eliciatation
Class: SurveyFactorData
SurveyFactorData OWLClass String Site A Slope position
HasFactorData ObjectProperty FactorLevel 1 : Ridge;
HasSurveyedFactorData ObjectProperty Site Site A
HasSurveyFactorData ObjectProperty GatherSurveyData M801 Sample Survey Data
levelValue DatatypeProperty int 1
SurveyFactorData OWLClass String Site B Slope position
HasFactorData ObjectProperty FactorLevel 2: Mid;
HasSurveyedFactorData ObjectProperty Site Site B
HasSurveyFactorData ObjectProperty GatherSurveyData M801 Sample Survey Data
levelValue DatatypeProperty int 2
SurveyFactorData OWLClass String Site B Forest Structure
HasFactorData ObjectProperty FactorLevel 1 : senescent;
HasSurveyedFactorData ObjectProperty Site Site B
HasSurveyFactorData ObjectProperty GatherSurveyData M801 Sample Survey Data
levelValue DatatypeProperty int 2
SurveyFactorData OWLClass String Site A Forest Structure
HasFactorData ObjectProperty FactorLevel 3 : regenerate.
HasSurveyedFactorData ObjectProperty Site Site A
HasSurveyFactorData ObjectProperty GatherSurveyData M801 Sample Survey Data
levelValue DatatypeProperty int 3
SurveyFactorData OWLClass String Site A Present of Road
HasFactorData ObjectProperty FactorLevel 1 : present;
HasSurveyedFactorData ObjectProperty Site Site A
HasSurveyFactorData ObjectProperty GatherSurveyData M801 Sample Survey Data
M801 - Suvey Data
Class: SurveyFactorData
functional Property Name type range value
levelValue DatatypeProperty int 1
SurveyFactorData OWLClass String Site B Present of Road
HasFactorData ObjectProperty FactorLevel 0 : absent.
HasSurveyedFactorData ObjectProperty Site Site B
HasSurveyFactorData ObjectProperty GatherSurveyData M801 Sample Survey Data
levelValue DatatypeProperty int 0
SurveyFactorData OWLClass String Site B Grazing
HasFactorData ObjectProperty FactorLevel 1 : no grazing;
HasSurveyedFactorData ObjectProperty Site Site B
HasSurveyFactorData ObjectProperty GatherSurveyData M801 Sample Survey Data
levelValue DatatypeProperty int 1
SurveyFactorData OWLClass String Site A Grazing
HasFactorData ObjectProperty FactorLevel 0 : grazing.
HasSurveyedFactorData ObjectProperty Site Site A
HasSurveyFactorData ObjectProperty GatherSurveyData M801 Sample Survey Data
levelValue DatatypeProperty int 0
SurveyFactorData OWLClass String Site A Vegetation Type
HasFactorData ObjectProperty FactorLevel 1a: wet forest with E.saligna, E. microcorys, E.cl
HasSurveyedFactorData ObjectProperty Site Site A
HasSurveyFactorData ObjectProperty GatherSurveyData M801 Sample Survey Data
levelValue DatatypeProperty int 1a
SurveyFactorData OWLClass String Site B Vegetation Type
HasFactorData ObjectProperty FactorLevel 4a: mixed dry forest with E.siderophloia, E.propin
HasSurveyedFactorData ObjectProperty Site Site B
HasSurveyFactorData ObjectProperty GatherSurveyData M801 Sample Survey Data
levelValue DatatypeProperty int 4a
M801 - Suvey Data
Class: SurveyFactorData
functional Property Name type range value
SurveyFactorData OWLClass String Site B Land Zone Classes
HasFactorData ObjectProperty FactorLevel 1: quartenary saline alluvial;
HasSurveyedFactorData ObjectProperty Site Site B
HasSurveyFactorData ObjectProperty GatherSurveyData M801 Sample Survey Data
levelValue DatatypeProperty int 1
SurveyFactorData OWLClass String Site A Land Zone Classes
HasFactorData ObjectProperty FactorLevel 11: Permian age and older sedimentary rocks that h
HasSurveyedFactorData ObjectProperty Site Site A
HasSurveyFactorData ObjectProperty GatherSurveyData M801 Sample Survey Data
levelValue DatatypeProperty int 11
SurveyFactorData OWLClass String Site A Fire Disturbance
HasFactorData ObjectProperty FactorLevel 1: wild fire;
HasSurveyedFactorData ObjectProperty Site Site A
HasSurveyFactorData ObjectProperty GatherSurveyData M801 Sample Survey Data
levelValue DatatypeProperty int 1
SurveyFactorData OWLClass String Site B Fire Disturbance
HasFactorData ObjectProperty FactorLevel 2: controlled burn;
HasSurveyedFactorData ObjectProperty Site Site B
HasSurveyFactorData ObjectProperty GatherSurveyData M801 Sample Survey Data
levelValue DatatypeProperty int 2
SurveyFactorData OWLClass String Site B Logging Disturbance
HasFactorData ObjectProperty FactorLevel 2: nothing since 1950;;
HasSurveyedFactorData ObjectProperty Site Site B
HasSurveyFactorData ObjectProperty GatherSurveyData M801 Sample Survey Data
levelValue DatatypeProperty int 2
SurveyFactorData OWLClass String Site A Logging Disturbance
M801 - Suvey Data
Class: SurveyFactorData
functional Property Name type range value
HasFactorData ObjectProperty FactorLevel 4: other logging.;
HasSurveyedFactorData ObjectProperty Site Site A
HasSurveyFactorData ObjectProperty GatherSurveyData M801 Sample Survey Data
levelValue DatatypeProperty int 4
Class: SurveyVariableData
SurveyVariableData OWLClass String Site A Rain in Driest Quarter
HasSurveyVariableData ObjectProperty GatherSurveyData M801 Sample Survey Data
HasSurveyVariableData ObjectProperty Site Site A
HasVariableData ObjectProperty VariableAttribute Rain in Driest Quarter
variableValue DatatypeProperty float 50
SurveyVariableData OWLClass String Site B Rain in Driest Quarter
HasSurveyVariableData ObjectProperty GatherSurveyData M801 Sample Survey Data
HasSurveyVariableData ObjectProperty Site Site B
HasVariableData ObjectProperty VariableAttribute Rain in Driest Quarter
variableValue DatatypeProperty float 75
SurveyVariableData OWLClass String Site B Rain in Wettest Quarter
HasSurveyVariableData ObjectProperty GatherSurveyData M801 Sample Survey Data
HasSurveyVariableData ObjectProperty Site Site B
HasVariableData ObjectProperty VariableAttribute Rain in Driest Quarter
variableValue DatatypeProperty float 175
SurveyVariableData OWLClass String Site A Rain in Wettest Quarter
HasSurveyVariableData ObjectProperty GatherSurveyData M801 Sample Survey Data
HasSurveyVariableData ObjectProperty Site Site A
HasVariableData ObjectProperty VariableAttribute Rain in Driest Quarter
variableValue DatatypeProperty float 200
SurveyVariableData OWLClass String Site A Elevation
M801 - Suvey Data
Class: SurveyVariableData
functional Property Name type range value
HasSurveyVariableData ObjectProperty GatherSurveyData M801 Sample Survey Data
HasSurveyVariableData ObjectProperty Site Site A
HasVariableData ObjectProperty VariableAttribute Elevation
variableValue DatatypeProperty float 1250
SurveyVariableData OWLClass String Site B Elevation
HasSurveyVariableData ObjectProperty GatherSurveyData M801 Sample Survey Data
HasSurveyVariableData ObjectProperty Site Site B
HasVariableData ObjectProperty VariableAttribute Elevation
variableValue DatatypeProperty float 1500
SurveyVariableData OWLClass String Site B Slope
HasSurveyVariableData ObjectProperty GatherSurveyData M801 Sample Survey Data
HasSurveyVariableData ObjectProperty Site Site B
HasVariableData ObjectProperty VariableAttribute Slope
variableValue DatatypeProperty float 12
SurveyVariableData OWLClass String Site A Slope
HasSurveyVariableData ObjectProperty GatherSurveyData M801 Sample Survey Data
HasSurveyVariableData ObjectProperty Site Site A
HasVariableData ObjectProperty VariableAttribute Slope
variableValue DatatypeProperty float 25
SurveyVariableData OWLClass String Site A Aspect
HasSurveyVariableData ObjectProperty GatherSurveyData M801 Sample Survey Data
HasSurveyVariableData ObjectProperty Site Site A
HasVariableData ObjectProperty VariableAttribute Aspect
variableValue DatatypeProperty float 200
SurveyVariableData OWLClass String Site B Aspect
HasSurveyVariableData ObjectProperty GatherSurveyData M801 Sample Survey Data
HasSurveyVariableData ObjectProperty Site Site B
M801 - Suvey Data
Class: SurveyVariableData
functional Property Name type range value
HasVariableData ObjectProperty VariableAttribute Aspect
variableValue DatatypeProperty float 175
SurveyVariableData OWLClass String Site B Average Winter Temperature
HasSurveyVariableData ObjectProperty GatherSurveyData M801 Sample Survey Data
HasSurveyVariableData ObjectProperty Site Site B
HasVariableData ObjectProperty VariableAttribute Average Winter Temperature
variableValue DatatypeProperty float 10
SurveyVariableData OWLClass String Site A Average Winter Temperature
HasSurveyVariableData ObjectProperty GatherSurveyData M801 Sample Survey Data
HasSurveyVariableData ObjectProperty Site Site A
HasVariableData ObjectProperty VariableAttribute Average Winter Temperature
variableValue DatatypeProperty float 5
SurveyVariableData OWLClass String Site A Average Summer Temperature
HasSurveyVariableData ObjectProperty GatherSurveyData M801 Sample Survey Data
HasSurveyVariableData ObjectProperty Site Site A
HasVariableData ObjectProperty VariableAttribute Average Summer Temperature
variableValue DatatypeProperty float 28
SurveyVariableData OWLClass String Site B Average Summer Temperature
HasSurveyVariableData ObjectProperty GatherSurveyData M801 Sample Survey Data
HasSurveyVariableData ObjectProperty Site Site B
HasVariableData ObjectProperty VariableAttribute Average Summer Temperature
variableValue DatatypeProperty float 19
SurveyVariableData OWLClass String Site B Degree of Canopy Cover
HasSurveyVariableData ObjectProperty GatherSurveyData M801 Sample Survey Data
HasSurveyVariableData ObjectProperty Site Site B
HasVariableData ObjectProperty VariableAttribute Degree of Canopy Cover
M801 - Suvey Data
Class: SurveyVariableData
functional Property Name type range value
variableValue DatatypeProperty float 2
SurveyVariableData OWLClass String Site A Degree of Canopy Cover
HasSurveyVariableData ObjectProperty GatherSurveyData M801 Sample Survey Data
HasSurveyVariableData ObjectProperty Site Site A
HasVariableData ObjectProperty VariableAttribute Degree of Canopy Cover
variableValue DatatypeProperty float 4
Class: VariableAttribute
VariableAttribute OWLClass String Rain in Driest Quarter
HasVariable ObjectProperty Survey M801 Fauna Survey
HasVariableAttributes ObjectProperty InstantiateSurveySchema M801 OWL/S Statistics Exercise
maximum DatatypeProperty float 2000
minimum DatatypeProperty float 0
unit DatatypeProperty string mm
variableDescription DatatypeProperty string Rain in Driest Quarter
variableName DatatypeProperty string Rain in Driest Quarter
VariableAttribute OWLClass String Rain in Wettest Quarter
HasVariable ObjectProperty Survey M801 Fauna Survey
HasVariableAttributes ObjectProperty InstantiateSurveySchema M801 OWL/S Statistics Exercise
maximum DatatypeProperty float 2000
minimum DatatypeProperty float 0
unit DatatypeProperty string mm
variableDescription DatatypeProperty string Rain in Wettest Quarter
variableName DatatypeProperty string Rain in Wettest Quarter
VariableAttribute OWLClass String Elevation
HasVariable ObjectProperty Survey M801 Fauna Survey
HasVariableAttributes ObjectProperty InstantiateSurveySchema M801 OWL/S Statistics Exercise
maximum DatatypeProperty float 2000
minimum DatatypeProperty float 0
M801 - Suvey Data
Class: VariableAttribute
functional Property Name type range value
unit DatatypeProperty string mm
variableDescription DatatypeProperty string Elevation
variableName DatatypeProperty string Elevation
VariableAttribute OWLClass String Slope
HasVariable ObjectProperty Survey M801 Fauna Survey
HasVariableAttributes ObjectProperty InstantiateSurveySchema M801 OWL/S Statistics Exercise
maximum DatatypeProperty float 90
minimum DatatypeProperty float 0
unit DatatypeProperty string degrees
variableDescription DatatypeProperty string Slope
variableName DatatypeProperty string Slope
VariableAttribute OWLClass String Aspect
HasVariable ObjectProperty Survey M801 Fauna Survey
HasVariableAttributes ObjectProperty InstantiateSurveySchema M801 OWL/S Statistics Exercise
maximum DatatypeProperty float 360
minimum DatatypeProperty float 0
unit DatatypeProperty string degrees
variableDescription DatatypeProperty string Aspect
variableName DatatypeProperty string Aspect
VariableAttribute OWLClass String Average Winter Temperature
HasVariable ObjectProperty Survey M801 Fauna Survey
HasVariableAttributes ObjectProperty InstantiateSurveySchema M801 OWL/S Statistics Exercise
maximum DatatypeProperty float 40
minimum DatatypeProperty float 0
unit DatatypeProperty string degrees
variableDescription DatatypeProperty string Average Winter Temperature
variableName DatatypeProperty string Average Winter Temperature
VariableAttribute OWLClass String Average Summer Temperature
HasVariable ObjectProperty Survey M801 Fauna Survey
M801 - Suvey Data
Class: VariableAttribute
functional Property Name type range value
HasVariableAttributes ObjectProperty InstantiateSurveySchema M801 OWL/S Statistics Exercise
maximum DatatypeProperty float 60
minimum DatatypeProperty float 0
unit DatatypeProperty string degrees
variableDescription DatatypeProperty string Average Summer Temperature
variableName DatatypeProperty string Average Summer Temperature
VariableAttribute OWLClass String Degree of Canopy Cover
HasVariable ObjectProperty Survey M801 Fauna Survey
HasVariableAttributes ObjectProperty InstantiateSurveySchema M801 OWL/S Statistics Exercise
maximum DatatypeProperty float 5
minimum DatatypeProperty float 1
unit DatatypeProperty string option
variableDescription DatatypeProperty string Degree of Canopy Cover
variableName DatatypeProperty string Degree of Canopy Cover
198
Appendix F Prototype Software
The prototype software and source is contained on the attached CD-ROM.
The software requires Microsoft IIS 5.0 or greater and Microsoft SQL 2000.
F1 Installation Instructions
Copy the agent directories and OWL files from the ..\WWWRoot folder on the
CD-ROM into the wwwroot folder on the IIS machine. Create the following
virtual directories:
Name Path
Blackboard C:\Inetpub\wwwroot\Blackboard
CoordinatonAgent C:\Inetpub\wwwroot\CoordinationAgent
DataAgent C:\Inetpub\wwwroot\DataAgent
GraphAgent C:\Inetpub\wwwroot\DataAgent
StatsData C:\Inetpub\wwwroot\DataAgent
StatisticAgent C:\Inetpub\wwwroot\StatisticAgent
ServiceBroker C:\Inetpub\wwwroot\ServiceBroker
Create a database called OWL on the SQL 2000 server. Restore OWL.BAK
over it from the ..\DBMS folder on the CDROM.
The web.config file located in C:\Inetpub\wwwroot\Blackboard requires the
"ConnectionString" key to be amended to suit the SQL server instance.
199
References
Aarsten,.Brugali,C.A. and Menga, G. (1996) ‘Patterns for Three-Tier
Client/Server Applications’, Pattern Languages of Programs (PloP96), Monticello, Illinois.
Antoniou, G. and van Harmelen, F. (2004) ‘A semantic Web primer’
Cambridge, MA: MIT Press. Antoniou, G., Franconi, E. and van Harmelen, F. (2005) ‘Introduction to
Semantic Web Ontology Languages’, Lecture Notes in Computer Science, vol. 3564, pp. 1-21.
Al-Awadhi, S. A. and Paul H. Garthwaite, P. H. (2006) ‘Quantifying Expert
Opinion for Modelling Fauna Habitat Distributions’, Computational Statistics vol. 21, iss. 1, pp. 121-140.
Atkinson, C. (2004) ‘Unifying MDA and Knowledge
Representation Technologies’, The Model-Driven Semantic Web Workshop (EDOC 2004). Monterrey, USA.
Barrett, R., Patcas, L. M., Pahl, C. and Murphy, J. (2006) ‘Model driven
distribution pattern design for dynamic Web service compositions’ Proceedings of the 6th international Conference on Web Engineering, New York, ACM Press.
Beckett, C. (2005) ‘The Swedish Myth: The Corporal Punishment Ban and
Child Death Statistics’, British Journal of Social Work, 35, pp. 125-38. Berners-Lee T, Hendler J and Lassila O (2001) ‘The Semantic Web’ Scientific
American, May. Bocchi, L., Ciancarini, P., Moretti, R., Presutti, V. and Rossi, D. (2005) ‘An
OWL-S based approach to express grid services coordination’ Proceedings of the 2005 ACM Symposium on Applied Computing, New York. ACM Press.
Brockmans, S., Volz, R., Eberhart, A. and Lo-effler, P. (2004) ‘Visual
modelling of owl dl ontologies using uml’ Proceedings of the Third International Semantic Web Conference, pp.198–213.
Buhler, P., Starr, C., Schroder, W. H. and Andvidal, J. M. (2004) ‘Preparing
for service-oriented computing: A composite design pattern for stubless Web service invocation’ Proceedings of the International Conference on Web Engineering (ICWE 2004).
Chen, S., Lu, F.Y. (2002) ‘Web-based simulations of power systems’ IEEE
Computer Applications in Power, vol. 15, pp. 35-40.
200
Chen et al (2003) S.-C. Chen, S., Gulati, S., Hamid, X., Huang, L., Luo, N.
Morisseau-Leroy, M., Powell, C., Zhan, C. and Zhang, A. (2003) ‘Three-Tier System Architecture Design and Development for Hurricane Occurrence Simulation’ Proceedings of the IEEE International Conference on Information Technology: Research and Education (ITRE 2003), pp. 113-117.
Corcho, O. and Gomez-Perez, A. (2000) ‘Evaluating Knowledge
Representation and Reasoning Capabilities of Ontology Specification Languages’ Proceedings of the ECAI'00 Workshop on Applications of Ontologies and Problem-Solving Methods, Berlin.
da Silva, E.Q. and de Abreu Moreira, D. (2005) ‘Developing customizable
Web-based educational applications through a component-based framework’ International Conference on Next Generation Web Services Practices, (NWeSP 2005).
Dai, W. and Abrahams, B. (2005) ‘A multiagent architecture for semantic
Web resources’ International Conference on Intelligent Agent Technology, pp. 289-292.
Davis, J., Tierney, A., and Chang, E. (2005) ‘Merging Application Models in a
MDA Based Runtime Environment for Enterprise Information Systems’ 3rd IEEE International Conference on Industrial Informatics (INDIN '05), pp. 605-610.
Denny, M (2004) , Ontology Tools Survey [online]
http://www.xml.com/lpt/a/2004/07/14/onto.html [Accessed: 09.10.2006].
Fensel, D., Wahlster, W., Lieberman, H. and Hendler, J. (2002) ‘Spinning
the Semantic Web: Bringing the World Wide Web to Its Full Potential’ MIT Press.
Frankel, D., Hayes, P., Kendall, E. and McGuinness, E. (2004) ‘The Model
Driven Semantic Web’, Enterprise Distributed Object Computing (EDOC) Conference, Model Driven Semantic Web Workshop (MDSW2004), Monterey, California.
Jarvinen, P. (2000). ‘Research questions guiding selection of an appropriate research method’ In Hansen Bichler & Mahrer (Eds.), Proceedings of ECIS2000, 3–5 July (pp. 124–131). Wien: Vienna University of Economics and Business Administration.
Gannod, G. C. and Timm, J. T. E (2004) ‘An mda-based approach for
facilitating adoption of semantic Web service technology’, 8th International Enterprise Distributed Object Computing Conference (EDOC), Workshop on Model-Driven Semantic Web, Monterey, California, IEEE Press.
201
Gaševic, D., Djuric, D., Devedzic, V. and Damjanovic, V. (2004) ‘Approaching
OWL and MDA Through Technological Spaces’. Workshop WS5 at the 7th International Conference on the UML, Lisbon, Portugal.
Gomez-Perez, A. and Corcho, 0. (2002) ‘Ontology languages for the
Semantic Web’, IEEE Intelligent Systems and Their Applications, vol. 17, iss. 1, pp. 54-60.
Grønmo, R., Jaeger, M. C. and Hoff, H (2005) ‘Transformations between
UML and OWL-S’, The European Conference on Model Driven Architecture - Foundations and Applications (ECMDA-FA), Nuremberg, Germany.
Gruber, T. R. A (1993) ‘Translation Approach to Portable Ontology
Specifications’, Knowledge Acquisition, vol. 5, iss. 2, pp. 199-220. Grundy, J., Wei, Z., Nicolescu, R.and Cai, Y. (2004) ‘An environment for
automated performance evaluation of J2EE and ASP.NET thin-client architectures’ Proceedings of Software Engineering Conference, pp. 300-308.
Helsinger, A., Thome, M., and Wright, T. (2004) ‘Cougaar: a scalable,
distributed multi-agent architecture’ IEEE International Conference on Systems, Man and Cybernetics, vol. 2, pp. 1910-1917.
Horrocks, I., Peter F. Patel-Schneider, P. and van Harmelen, F. (2003) ‘From
SHIQ and RDF to OWL: The making of a Web ontology language. Journal of Web Semantics, vol.1, iss. 1.
Kiferand, M. and Lausen, G. (1989) F-Logic: a higher-order language for
reasoning about objects, inheritance and scheme, In Proc ACM SIGMOD, pp. 134–146.
Kleppe, A., Warmer, J. and Bast. W. (2003) ‘MDA Explained. The Model
Driven Architecture: Practice and Promise’ Object Technology Series. Addison-Wesley.
Knublauch, H. (2004) ‘Ontology driven software development in the context of
the semantic web: An example, scenario with protégé/owl’, 1st International Workshop on the Model-Driven Semantic Web (MDSW2004).
Kum, D. K. and Soo Dong Kim, S. D. (2006) ’A Method to Generate C# Code
from MDA/PSM for Enterprise Architecture’ 5th International Conference on Computer and Information Science (ICIS-COMSAR 2006)., pp. 238-243.
Kung, D.C., Bhambhani, H., Nwokoro, S., Okasha, W., Kambalakatta, R. and
202
Sankuratri, P. (2003) ‘Lessons learned from software engineering multi-agent systems’ Proceedings of the 27th International Annual Conference on Computer Software and Applications (COMPSAC 2003), pp. 50-55.
O.I.Lindland, G.Sindre, and Soelvberg A. (1995) ‘Understanding quality in
conceptual modelling’ Journal of IEEE software, vol. 11, iss. 2, pp. 42–49.
Marchionini, G. and Haas, S. W. and Plaisant, C. and Shneiderman, B. and
Hert, C. (2003). ‘Toward a Statistical Knowledge Network’, Proceedings of the National Conference on Digital Government Research, pp. 27 - 31.
McKeigue, B. and Beckett, C. (2004) ‘Care Proceedings under the 1989
Children Act: Rhetoric and Reality’, British Journal of Social Work, 34, pp. 831-49.
Meservy, T.O., and Fenstermacher, K.D. (2005) ’Transforming Software
Development: An MDA Road Map’ Computer ,vol. 38, no. 9, pp. 52- 58.
Milojicic, D., Kalogeraki, V., Lukose, R., Nagaraja, K.
Pruyne,,J., Richard, B., Rollins, S., and Xu Z (2002) ‘Peer-to-Peer Computing’ Technical Report (HPL-2002-57), HP, 2002.
Motta, E. (1998) ‘An Overview of the OCML Modelling Language’ In
Proceedings KEML'98: 8th Workshop on Knowledge Engineering Methods & Languages, Karlsruhe, Germany.
MSN Encarta (2006), MSN Encarta Web [online],
http://encarta.msn.com/encyclopedia_761555386_1/Metaphysics.html#p1, [Accessed 21 June 2006].
Mylopoulos, J., Borgida, A., Jarke, M., and Koubarakis, M. (1990) ‘Telos:
Representing knowledge about information systems’ ACM Trans. Inform. Syst., vol. 8, no. 4.
Nunamaker, J. F. J. and Chen, M. (1990) ‘Systems
Development in Information Systems Research’, Journal of Management Information Systems, vol. 7, iss. 3, pp. 89-107.
OMG Unified Modelling Language Specification Version 1.3 First Edition:
March 2000. Proposed M801 Topic (2005), Proposed M801 Topic (Unique Topic id: MCSS
–6ACLKK) [online], http://mcs-notes2.open.ac.uk/M801/M801Topics.nsf/22166ab203169633802570490074172b/b15393c46017915780256f2e00359325?OpenDocument [Accessed 02 February 2006].
203
Schattkowsky, T and Lohmann, (2005) ‘UML Model Mappings for Platform
Independent User Interface Design’, Bruel, J.M. (Ed.): MoDELS 2005 Workshops, LNCS 3844, pp. 201 – 9.
Schreiber, A.T., Dubbeldam, B., Wielemaker, J. and Wielinga, B. (2001)
‘Ontology-based photo annotation’, IEEE Intelligent Systems, vol. 16, iss. 3 (May-Jun), pp. 66 – 74.
Schulz-Hofen, J. and Golega, S. (2006) ‘Generating Web applications from
process models’ Workshop Proceedings of the Sixth international Conference on Web Engineering (ICWE '06), vol. 155., New York, ACM Press.
Selfa, D.M., Carrillo, M. and Del Rocio Boone, M. (2006) ‘A Database and
Web Application Based on MVC Architecture’ 16th International Conference on Electronics, Communications and Computers (CONIELECOMP 2006), pp. 48 – 48.
Shaw, M., and D. Garlan, D. (1996) ‘Software Architecture: Perspectives on
an Emerging Discipline’, Prentice Hall. Shen, J.,Yang, Y., Chuan Zhu and Wan, C. (2005) ‘From BPEL4WS to
OWL-S: integrating e-business process descriptions’, IEEE International Conference on Services Computing, vol. 1, pp. 181 – 88.
Silva, O., Garcia, A., Lucena, C. (2002) ‘The Reflective Blackboard
Architectural Pattern for Developing Large Scale Multi-Agent Systems’ Proceedings of the First International Workshop on Software Engineering for Large-Scale Multi-Agent Systems, pp. 73-93.
Su, X. and Ilebrekke, L. (2004) ‘Using a Semitic Framework for a
Comparative Study of Ontology Languages and Tools’ IDEA Group Publishing Group, chap. 14, pp. 278-299.
The Open University (2001) M878 Object-Oriented Software Development,
Milton Keynes, Open University. The Open University (2000) M880 Software Engineering, Milton Keynes,
Open University. Thomas, D. (2004) ‘MDA: revenge of the modelers or UML utopia?’, IEEE
Software, vol. 21, iss. 3 (May-Jun), pp.15 – 17. Timm, J.T.E. and Gannod, G.C. (2005) ‘A model-driven approach for
specifying semantic Web services’, Proceedings of IEEE International Conference on Web Services, ICWS 2005, vol.1 (11-15 July), pp. 313 – 20.
van Harmelen, F. and Horrocks, I. and Clark, P. and Patel-Schneider, P.F.
204
and Uschold, M. and Rousset, M.-C. and Hendler, J. and Schreiber, G. (2002) ‘Ontologies’ KISSES in standardization’, Intelligent Systems, IEEE vol. 17, issue 2 (Mar-Apr), pp. 70-79.
van der Vet, P.E. and Mars, N.J.I. (1998) ‘Bottom-up construction of
ontologies’, IEEE Transactions on Knowledge and Data Engineering, vol. 10, issue 4 (July-Aug), pp. 513-26.
W3C-OWLS (2004), OWL-S: Semantic Markup for Web Services [online]
http://www.w3.org/Submission/2004/SUBM-OWL-S-20041122/ [Accessed 14 August 2006].
Wikipedia (2006) , [online], http://en.wikipedia.org/wiki/Ontology,
[Accessed 21 June 2006]. Yu, Z., Xiu, L., Lin, L., Wenhuang, L. and Shouju, R. (2004) ‘A blackboard-
based multi-agent distributed QFD system’ IEEE International Conference on Systems, Man and Cybernetics, vol. 6, pp. 5125-5129.
205
Index Artificial Intelligence, 20Blackboard, 15, 58-60Business Process Execution Language for Web Services, 29, 38, 51centralised, 57-58code generation, 3, 36Computational Independent Model, 34, 92computer science, 20database management system, 70discovery, 37, 45, 56Distribution pattern, 56domain modelling, 5, 14dynamic models, 36, 97extensible stylesheet language transformation, 66GovStat ontology, 1hybrid distribution pattern, 62life-cycle, 10Meta Object Facility, 66Metaphysics, 19Model View Controller, 60Model-Driven Architecture, 2, 33-37multi-agent system, 53Object Management Group, 2, 4, 20ontology, 1, 20Web Ontology Language (OWL), 25OWL service language (OWL-S), 28peer-to-peer, 57, 58Platform Independent Model, 35, 45, 65Platform Specific Model, 33, 35, 45product family, 47product-line architecture, 48Protégé, 31, 66requirements, 63Semantic Web, 2, 19semiotic framework, 27software agent, 37Specification Modelling, 15Statistical Knowledge Network, 1system architecture, 9Systems development research methods, 8three-tier architecture, 52transformation, 35Unified Modelling Language, 2Web service, 29, 38workflow, 42
![Cedar: Engineering Role-Based Adaptive User Interfaces for ...computing-reports.open.ac.uk/2012/TR2012-08.pdf · CRM 2011 [33] and SAP GuiXT [34] offer such a mechanism. Yet, it is](https://img.pdfslide.us/doc/110x75/5ebe7aa3ac894b36b31ac23d/cedar-engineering-role-based-adaptive-user-interfaces-for-computing-crm-2011.jpg)
