Utilizing Ontologies to Integrate Heterogeneous Decision ... · of precision that they can be used...

353

Chapter 17-x

Data mining system

Case-based system

Rule-based system

Mediator

System n

Domain ontology 1

Domain ontology n

Integration ontology

Risk ontology

User

Authors:Josef KüngErik SonnleitnerReinhard Stumptner Andreea Hilda KosorusStefan Anderlik

17Utilizing Ontologies to Integrate Heterogeneous Decision Support Systems

MotivationStructural health monitoring (SHM) has been developed in fragmented activities in

various regions of the world. The large variety of systems for measurement planning, re-cording and analysis has disadvantages to be overcome. It is desirable to have a domain ontology enabling communication between the various systems.

Main ResultsThe IRIS ontology for Decision Support Systems in the field of structural health moni-

toring has been developed within the project. This enables the implementation of a har-monized Decision Support System.

354

17 Utilizing Ontologies to Integrate Heterogeneous Decision Support Systems

17-1 IntroductionStructural Health Monitoring (SHM) can be seen as a method for identifying and lo-

calizing damages on structures or structural elements. Each structure has its individual dynamic behaviour which can be identified by analyzing the signal response of the moni-tored structure. Due to the fact that in the area of SHM, individual institutions developed numerous different systems for planning, recording and analyzing measurements, an ontology-based integration of Decision Support Systems (DSS) for SHM is useful or even necessary. The selection of an adequate system for these operations depends, among oth-ers, on the kind of measurement data or on the defined monitoring objectives.

Within the scope of the European Union project IRIS, an integration-ontology for DSSs in the field of SHM has been developed and is shortly outlined in this contribution. IRIS was a project of 3.5 years (starting in October 2008) and involved 36 well-known industrial partners and research institutions in different areas of application (mainly SHM) world-wide. One of the main objectives of this research project was the development of an online risk management system to increase the safety degree in industries like oil and mining, as well as in the chemical and energy production sector of industry. To reach this aim, intel-ligent assessment strategies for structural measurement data have been implemented. As mentioned above, advantages of all conceivable systems within different branches of industry for planning, recording and analyzing measurements can be combined to guar-antee industrial safety and to reduce the contamination of environment. For this reason, domain ontologies are useful which shall describe relevant information and knowledge of a certain domain. Matching these ontologies by means of a higher level ontology, shall increase the collaboration levels of different institutions and suggesting the best possi-ble systems for measurement assessment. Therefore, an ontology-based integration ap-proach has been introduced and described by explaining the structure of the ontology, the overall mediator-supported systems and their possible benefits for DSSs in the field of SHM. Moreover, standardization and integration have been two major topics concern-ing the IRIS project. On these two main objectives, a concept for an integrative usage of different measurement analyzing functions for SHM like Fast Fourier Transformation (FFT) or Wavelet Transformation was required. These operations are partly available within sys-tems like BRIMOS® (Bridge Monitoring System) (see [Wenzel and Pichler, 2005; Anderlik et al., 2010]), but not in an integrative and guided manner. The problem of using such sys-tems is the lack of semantic behaviours and conditions for measurement analysis: Many operations are available, but not everyone knows which function should be executed to what scope (e. g. clustering operations can be useful in addition to certain pre-existence data discovery methods) and how (parameters, semantics, notifications, etc.). Hence, the integration approach of heterogeneous Decision Support Systems (DSS) for SHM in [An-derlik et al., 2010] shall provide a framework for these purposes and provides opportuni-ties for being guided through data analysis, data preparation and assessment tasks.

The integrative usage of DSS in SHM is a major challenge concerning “Black Box” sys-tems like BRIMOS®, where integration is not possible analogous to Open Source APIs like WEKA or RapidMiner. We will subsequently point out, how the integration of various dif-ferent DSSs has been done, and how it can be used to aid in SHM.

355

Decision Support Systems for Structural Health Monitoring 17-2

Monitoring AssessmentData PreparationCampaign Planning

BRIMOS® work-flow F.17-1

17-2 Decision Support Systems for Structural Health Monitoring

The area of Structural Health Monitoring is an ambitious topic for current Information- and Knowledge-Based Systems like Decision Support Systems. Therefore, BRIMOS® as an ambassador of SHM-Systems will be discussed within this section. The System Descrip-tion is based on processes and assessment methodologies shown in [Wenzel and Pichler, 2005; Wenzel, 2008].

BRIMOS® can be defined as a method for system identification and damage detection in bridge structures due to its dynamic response to ambient excitation such as wind, traf-fic and micro seismic activity.

This Bridge Monitoring System has been used for many years in the field of SHM. SHM, in terms of Ambient Vibration Monitoring, comprises recording a structure’s dynamic be-haviour by using measuring instruments as well as the performing evaluation and analysis tasks of the measured signals. The fundamental tools of health monitoring are system identification, damage determination and localization as well as safety assessment and the maintenance management for infrastructure.

The process itself starts with collecting meta-data of a structure. That meta-data is used for the detailed campaign planning. Campaign planning, in turn, can be divided into several steps like deciding whether detailed, periodic or permanent measurements should be conducted. At this stage, a sensor layout is created and schedules for measure-ments are written down.

After a detailed campaign planning phase, monitoring takes place. Measurement data is pre-processed depending on the kind of data and usually written into a data base be-fore using it for routine assessment (which, again, depends on the kind of measurement). Routine assessment e. g., provides the determination of the modal parameters, namely the structure’s natural frequencies, its mode shapes and its damping coefficients. These parameters, which are gained from the measurements, represent the real condition of a structure. The measurements, often represented by a signal time series provides a degree of precision that they can be used as reference data with a high qualitative value for every future evaluation method.

Routine assessment consists of any combination of assessment parts, which might be rapid frequency analysis, eigenfrequencies, drift calculation, trend cards, modal shapes, vibration intensities, energy levelling, among others. Describing any combination would go beyond the scope of the overall system description. Assessment results are used to

356


update mathematical models of a structure. If previous measurement data and results are available, establishing a simple comparison metric is possible. Otherwise, since a large data pool of previously investigated structures, which may be reasonably similar, is readily available, an integrated Case-based Reasoning (CBR) approach can be applied.

The BRIMOS® process flow is the reference structure for this ontology-based approach. At this point it is important to define a general procedure module, which will be imple-mented as a mediator system for supporting the whole process during monitoring, com-putation and assessment as well as interacting with certain end-users who are working with the different DSSs. This general concept is based on BRIMOS® and contains the steps shown in F.17-1. These process steps are modelled within the integration ontology beside much semantic knowledge about the domain SHM and the specific DSS descriptions.

The idea of utilizing an ontology for integration issues is one typical application for technologies within the Semantic Web, but its initial intention differs from the approach discussed in this contribution. Therefore ontologies, in the scope of data and semantic integration, will be explained in the next chapter.

17-3 Ontology-Based Data IntegrationThe term ontology has its origin in philosophy and metaphysics, within these research

areas people think about the being and not being in general and focus on questions con-cerning the existence of concrete things and their connections [Bunge, 1977]. This point of view is the philosophical perspective, but for computer scientists, an ontology is de-scribed as an “explicit and formal specification of a shared conceptualization of a domain of interest [Gruber, 1993]”. This initial definition was introduced by [Gruber, 1993] and can be seen as the essential meaning of such a semantic structure. Based on this state-ment, many authors developed important concepts and technologies for tasks within the area of ontology engineering and development. One major advantage of ontologies can be seen in their aspect of working with peripheral web resources, which are distributed but accessible within the so called Web of Data. If someone wants to develop a system, which has interconnections with other semantically different platforms, frameworks, agents, etc., and their resources, a mechanism is needed which assures a valid syntax and semantic for interoperability. Davenport and Prusak called this explicit, distributed and accessible resource a common vocabulary: “People can’t share knowledge, if they don’t speak a common language” [Davenport and Prusak, 2000]. This declaration can be ex-tended by substituting the word people with agents. If this is done, ontologies can be seen as knowledge bases, which provide interconnectivity between different agents like human individuals as well as computer agents. This perspective is one of the most im-portant application areas of ontologies. But if we analyze the definition of [Gruber, 1993] an ontology is not a semantically enhanced structure of class assertions, it provides wide and deep knowledge about a domain, which also includes the implicit rules and semantic associations within this area: “… it is an intentional semantic structure that encodes the implicit rules constraining the structure of a piece of reality” [Guarino and Giaretta, 1995].

357

Ontology-Based Data Integration 17-3

Today, ontologies are used for more specific areas of application and not only as glob-al vocabularies, knowledge bases, thesaurus, etc. The most important feature is to reason about the domain of interest, to classify certain individuals and to compute new knowl-edge also dynamically at runtime. Examples for these areas are the search for semantically annotated documents, queries within these information resources, data integration and proper interconnectivity between different and heterogeneous systems, search and com-position of (web) services, etc. We will further focus on the application of data integration, but first of all it should be discussed which main concepts are available in this area and what natural idea stands behind using ontologies for combining heterogeneous systems.

Data integration as an important concept in information systems is strongly connect-ed with the architecture of federated databases and with its aspects of combining distrib-uted, autonomous and heterogeneous databases [Buccela er al., 2003]. These concepts characterize the main idea of federation and also include design autonomy, communica-tion autonomy and execution autonomy [Lenzerini, 2002; Oszu and Valduriez, 1999], network characteristics of distributed agents and heterogeneity concerning structure, syntax, system and semantic [Cheng, 2003; Cui and O’Brien, 2000]. These properties of data integration can also be found in areas like application integration and application interoperability [Buccela er al., 2003]. The ontology-based data integration approach for Decision Support Systems is hybrid and combines aspects of distributed stand-alone ap-plications, heterogeneous DSSs, and different syntax and semantics of Structural Health Monitoring. The core of the architecture for interoperability between different DSSs is a central ontology, which contains knowledge about an abstract process flow (see also: chapter 2) and the definitions of every available system, especially its description of input and output parameters (see also: chapters 4 and 5). Beside this single ontology approach someone can use multiple or hybrid ontologies, which are either well known concepts in the area of data integration [Cruz and Xiao, 2005]. Another important factor to clarify is the use of the ontology. The DSS data integration ontology is handled as a global concep-tualization, to provide meta information about systems and to support a mediator com-ponent to maintain the whole routine by deciding which step should be done next and what are possible applications to work with a certain output (see also: chapter 4). Beside the idea of a global conceptualization, which can be seen as one of the first application areas initially mentioned from [Gruber, 1993], an ontology for (data) integration can also be used for meta-data representation, support for high-level queries, declarative media-tion or mapping support [Cruz and Xiao, 2005].

The overall idea of ontology-based data integration is based on the so called semantic data integration. It is not provided that systems within an application area like DSSs for SHM have the same semantic view of a certain input (measure, campaign, damage, etc.) or output (big difference, which ranges from simple results like pure statements to complex results shown in a matrix concerning information about facility state and problems). An appropriate definition of semantic data integration can be found in [Cruz and Xiao, 2005]: “We call semantic data integration the process of using a conceptual representation of the data and of their relationships to eliminate possible heterogeneities”. The problems of possible heterogeneities are solved by the ontology, which has to guarantee full seman-tic support for every available DSS. But [Guarino and Giaretta, 1995] declare the phrase “explicit and formal specification” from [Gruber, 1993] as a very important fact, because

358


Decision Support System

Integrationontology 1

Rule-basedsystem

Mediatorsystem

KB ofgroup 1

IRISknowledge base

Decision Support System

Integrationontology n

Domainontology 1

Data ofgroup 1

Data ofgroup n

Mediatorsystem

Systemn

Case-basedsystem

KB ofgroup n

Domainontology n

IRISontology

System landscape F.17-2

an ontology is only a snapshot of a certain domain and cannot fulfil every issue. But it is possible to constrain the semantic meaning and to provide full semantic support of a certain area of a domain. Therefore the ontology developer has to be aware of the world consumption (open world – OWA; or closed world – CWA) to assure interoperability and well reasoning results. These aspects are very important for the development of the DSS ontology.

Definitions and descriptions, which are discussed in the above paragraphs, deal with the main idea of (semantic) data integration, but it has to be mentioned which concepts are mainly used in this research area and if they are appropriate for the use of DSS data integration. The most referenced and explained approaches are general concepts dealing with different data sources, as well as ontologies, and mappings between them. Depend-ing on the point of view these conceptions are called local-as-view (LAV), global-as-view (GAV) or as a hybrid combination global-local-as-view (GLAV) [Cruz and Xiao, 2005; Len-zerini, 2002]. The LAV approach focuses on the local data sources and formulates these sources as queries over the global schema (vice versa for GAV). The hybrid approach GLAV combines both assertions and formulates conjunctive queries over the global and local schemas, which are mapped together.

The mentioned methodologies are typical for data integration systems, where two or more sources with different schemas have to be merged in a syntactic as well as a seman-tic manner. The conceptualization of an ontology for heterogeneous DSSs differs from this point of view because this system should work with one single ontology and needs no implementation of concepts like LAV, GAV or GLAV. The introduced architecture will be described and drafted in the next section.

359

Integration Ontology for Structural Health Monitoring 17-4

Data mining system

Case-based system

Rule-based system

Mediator

System n

Domain ontology 1

Domain ontology n


Risk ontology

User

Integrated Decision Support Systems F.17-3

17-4 Integration Ontology for Structural Health Monitoring

In the field of Structural Health Monitoring, different institutions operate a large vari-ety of systems for measurement planning, recording and analysis. As a sophisticated rep-resentative BRIMOS® was described in chapter 2. An outlier detection approach [Siringo-ringo et al., 2009] and a case-based system [Freudenthaler, 2009] can be mentioned in addition. Each of these individual systems has its advantages and disadvantages, mainly depending on certain circumstances of an application, like the type of a regarded struc-ture, the kind of measurement data, defined monitoring objectives, etc. With the intention to increase precision and reliability of SHM processes in general, it is useful to combine the advantages of these individual systems.

Beside further developing sensors, recorders and measurement analysis systems within the EU project IRIS, partners identified collaboration as an important key factor of success. On behalf of that, a concept for computer supported collaboration by means of semantic technologies was worked out. F.17-2 shall illustrate this idea.

There is a certain number of institutions (civil engineers), called Group in F.17-2, which collected many gigabytes of measuring data and other documents related to SHM over several years. To increase the accessibility of these information sources, each participating institution develops its domain ontology. Furthermore, the participants’ knowledge can be integrated by mapping the domain ontologies by means of a higher level ontology (here called IRIS Ontology). A web-based system should make the accumulated informa-tion easily accessible to the co-operation partners in the form of a knowledge base. How-ever, this knowledge base is not the main focus of this contribution, but rather another aspect beside sharing knowledge. F.17-3 picks out the relevant parts from the system landscape to clarify the main concern of this contribution.

360


Thing Location

Physicalphenomenon

System

PDSIS item

IRIS concept

Company

DSS item type

DSS item

Physical entity

Resource

Event

Meas system

Comp system

Process step typeMonitoring

Assessment

Campaign planning

Ranked system

Acceptable risk

Individual risk

Adequate system

Not adequate system

Med adequate system

Data preparation

Risk

Consequence Human consequence Death

Individual humanconsequence

Injury

Public loss

Private loss

Property consequence

Probability

Damage

Decision

Broken physical entity

Statement

is-a

is-a

is-ais-a

is-a

is-ais-a

is-a

is-a

is-ais-ais-a

is-a

is-a

is-ais-a

is-a

is-a

is-a

is-a

is-a

is-a

is-a

is-a

is-a

is-a

is-a

is-a

is-a

is-a

is-a

is-a

is-a

is-a

is-a

is-a

is-a

is-a

is-a

is-a

is-a

is-a

Integration ontology (excerpt) F.17-4

In addition to supporting knowledge interchange between involved institutions, their systems for planning, running and analyzing measurements should be made available for each other in an automated and integrated manner. On account of this, a concept for an ontology-based integration of DSSs for SHM was developed, as presented in F.17-3. An In-tegration Ontology, which is based on the certain Domain Ontology and also uses the IRIS Ontology for referring to relevant background information serves as a mediator system: The integration process should be provided by the mediator instance, which classifies cer-tain inputs at runtime by reasoning the ontology and extracting the computed individu-als and their class assertions. This retrieved information will be used to decide whether the current process step should be repeated, returned to the previous one or proceeded to the next step. The decisions and operations of the whole system area should not be hard-coded and maintained by an algorithm, the knowledge about the supported and available systems for each process step should be independently available. The mediator system can be seen as a kind of router, which delegates a user through the measuring and analysis process for suggesting the appropriate tooling at the right point of time. To

361

The Passive Decision Support System PDSIS 17-5

make this possible, the mediator system has to be aware of the general work-flow shown in F.17-1, which covers a whole measuring campaign on a level of abstraction, which is high enough to make this process suitable to a large variety of applicable DSSs and which enables systems to be handled in a cooperative mode.

At each step, DataPreparation for instance, the mediator should be able to suggest suitable systems to a user and, with the help of an appropriate learning component, the most popular system for a certain process step could be provided. In the course of that, the ability can be gained to generate combined solutions for certain problems, which can rely on the contribution of a certain number of participating systems, making results more reliable and hopefully increasing the overall quality of a measuring campaign. Fur-thermore, individual DSSs can profit from each other. A case-based system for instance could import input and corresponding output of other systems and generate new cases to extend its case base, which can increase future problem solving capabilities. In reca-pitulatory terms, the main objective of integrating individual systems is to increase the quality of SHM in general by reaching highly reliable results at each process step of a monitoring campaign.

F.17-4 gives an overview of an Integration Ontology, as represented in F.17-3 and F.17-4. The nodes (classes) System, ProcessStep, CampaignPlanning, Monitoring, DataPrepara-tion and Assessment from F.17-4 are of main interest for the system integration concept. The class System represents available DSSs, a case-based system for instance, while the class ProcessStep realizes a representation of the individual steps of a monitoring cam-paign, which are campaign planning, monitoring, data preparation and assessment. This concept of an Integration Ontology, also including concrete examples, is presented in the following section.

17-5 The Passive Decision Support System PDSIS

For the purpose of identifying, localizing and assessing damages on structures or structural elements, various different and highly heterogeneous DSS are subject to assist in this process, which includes multiple diverging process steps, each having different syntactic and semantic requirements and communication interfaces to deal with. In order to enforce the integration of multiple heterogeneous DSS, the main concern is the estab-lishment of an integrative system, which aims to implement an additional high-level layer being abstract enough to offer the possibility of covering all conceivable kinds of different DSS in terms of SHM.

Resulting from intensive research within the frame of the European Union IRIS project as described earlier, an integration system PDSIS (Passive Decision Support Integration System) has been developed which tends to cover all of the previously mentioned re-quirements by heavily utilizing ontologies.

Since the participating partners of the IRIS project originate from a broad range of industry sectors, the knowledge and expertise of each sector is constituted within a par-

362


Mediator pre-process

Campaign planning


Thing Location

Physicalphenomanon

System

PDSIS item

IRIS Concept

Company

DSS item type

DSS item

Physical entitiy

Resource

Event

Meas system

Comp system


Assessment

Campaign Planning

Ranked System

Acceptable Risk

Individual Risk

Adequate system

Not adequate system

Med adequate system

Data Preparation

Risk

Consequence Human Consequence Death

Individuale humanconsequence

Injury

Public Loss

Private Loss

Property Consequence

Probability

Damage

Decision

Broken physical entitiy

Statement

is-a

is-a

is-ais-a

is-a

is-ais-a

is-a

is-a

is-ais-ais-a

is-a

is-a

is-ais-a

is-a

is-a

is-a

is-a

is-a

is-a

is-a

is-a

is-a

is-a

is-a

is-a

is-a

is-a

is-a

is-a

is-a

is-a

is-a

is-a

is-a

is-a

is-a

is-a

is-a

is-a

System validation


Monitoring

System validation

System validation

System validation

Work�ow summary



Assessment

Data preparation

Mediatorinteraction

UserAcceptresult?

NO

YES

Acceptresult?

[no,

bac

k to

cam

paig

n pl

anni

ng]

NO

YES

Acceptresult?

Acceptresult?

NO

YES

Acceptresult?

NO

YES

YES

Mediatorinteraction

PDSISmeasurement

database

User

Mediatorinteraction

User

Mediatorinteraction

User

[no,

bac

k to

mon

itorin

g]

[no,

bac

k to

dat

a pr

epar

atio

n]

[no,

bac

k to

ass

essm

ent]

Enhanced general work-flow F.17-5

ticular domain ontology. These domain ontologies are very specific and strongly related to the individual industry segments. In order to create an associational and semantic map-ping between these, each domain ontology also provides a specific integration ontology which, in turn, uses one central abstract ontology (which we call IRIS ontology) for refer-ring to relevant background information and therefore providing a rather holistic integra-tion approach based on semantic technologies.

The PDSIS architecture consists of a single central user-friendly front end, which inter-feres with a mediator component which mainly takes care about the integration process through classification at runtime. This is done by reasoning the ontologies and extracting the computed individuals and their class assertions [Cheng, 2003]. Therefore, for each process step in question, the mediator component is able to suggest suitable systems for a specific task

363


Search for systems

Retrieve input parameterRetrieve input data

Decision for systems


Thing Location

Physicalphenomanon

System

PDSIS item

IRIS Concept

Company

DSS item type

DSS item

Physical entitiy

Resource

Event

Meas system

Comp system


Assessment

Campaign Planning

Ranked System

Acceptable Risk

Individual Risk

Adequate system

Not adequate system

Med adequate system

Data Preparation

Risk

Consequence Human Consequence Death

Individuale humanconsequence

Injury

Public Loss

Private Loss

Property Consequence

Probability

Damage

Decision

Broken physical entitiy

Statement

is-a

is-a

is-ais-a

is-a

is-ais-a

is-a

is-a

is-ais-ais-a

is-a

is-a

is-ais-a

is-a

is-a

is-a

is-a

is-a

is-a

is-a

is-a

is-a

is-a

is-a

is-a

is-a

is-a

is-a

is-a

is-a

is-a

is-a

is-a

is-a

is-a

is-a

is-a

is-a

is-a

User

User

Mediator pre-processing F.17-6

The following figures show the complete workflow for a monitoring campaign based on BRIMOS®. This process flow is modelled within the integration ontology and also in-cluded in the mediator.

The workflow starts with the first step, campaign planning, by pre-processing of the mediator. This sub-process can be seen in F.17-2. Concerning this application flow, the first activity is to search for an adequate system related to the correspondent process step, e. g. if the current step is “Monitoring” then the mediator searches within the ontology for systems, which are classified as “Monitoring”-systems and the search result is a set of this type of systems. The concept of an integration ontology for SHM and the concrete model-ling of such systems matched with the relevant process steps can be found in [Buccela et al., 2003].

The next iteration affects the user because a decision is needed concerning which system should be chosen to be used for the current process step. Furthermore the user passes input parameters, e. g. an activity log-file for BRIMOS®, and input data, e. g. certain measures or modal parameters depending on the type of process step (see [Buccela et al., 2003]). At this point it is really desirable to participate for further improvements of this sub-process and the structure of the input data and parameters. This information is highly heterogeneous and concerning the overall goal of the integration ontology.

After transmission of the required data, the mediator sub process will terminate and the process flow will return to the next step within the enhanced integration workflow (F.17-1).

Back in the enhanced workflow, the next step would be the concrete execution of a certain process and in this context an IRIS DSS. During this computation, the mediator interacts with the chosen DSS and the user. The interoperation with these actors depends on the system itself, so maybe it is important to configure the correspondent DSS manu-ally, e. g. set up the measuring system, configure sensors and recorders, etc.

364


Monitoring AssessmentData PreparationCampaign PlanningBRIMOS®SystemhasInput MetaData,hasInput ConfigData,hasInput Campaign,hasInput Measure, hasInput ModalParameter,hasOutput Measure,hasOutput ModalParameter,hasOutput AssessmentResult,hasQuality Q_Bri_Monitor

MonitorDummyMonitoring

Q_Bri_MonitorQualityhasProcessStep MonitorDummy,hasAcceptCount 10,hasRefuseCount 1

Individual:Types:Facts:

Individual:Types:

Individual:Types:Facts:

Computed andattached by the

mediator and theend-user

Example quality measurement F.17-7

After the main process-step ended, the retrieved process result will be evaluated by the user and therefore also the system itself. Concerning this activity, the validation result will be stored in the ontology by adding additional knowledge about the correspondent system. Referring to the example for quality measurement in [Buccela et al., 2003] such a system description could appear as shown in F.17-3. Therefore, the BRIMOS® system, which was chosen in this example during mediator pre-processing of “Monitoring”, will be annotated with a quality mark, which gives information about the acceptance and refused count: a measure for the adequacy of the result. Furthermore, these measures can be used to calculate an acceptance rate, which can help the user by deciding which system is good for what kind of process step.

The topic of how to model a quality measurement within a knowledge grid like an on-tology is a rather interesting and huge topic within the current Semantic Web community. Therefore the FAW (Institute for Application-Oriented Knowledge Processing, JKU Linz) will improve the integration ontology by implementing appropriate enhancements. The first step will be the researching of existing quality ontologies, which are mostly based on SOA (Service Oriented Architecture) concepts concerning the so called Quality of Services (QoS). This information is specified by measurements and attributes, which are impor-tant for systems (in the field of SOA: services), but it is also important to include deep implicit domain knowledge and experiences from the experts to enhance this first hint. The overall goal is to model QoS measures in a way to construct Quality of Experiences (QoE) [Bunge, 1977].

If we step back to the general integration workflow, the process flow continues with the question whether the user accepted the computed system results during validation or not. Depending on this decision the mediator’s internal workflow will start again with the option to step back to another process, if it is adequate. This restart will only be ex-ecuted, if the current results are refused and the quality mark of the system is modified in the corresponding way as shown in F.17-3. In the case that the user does not accept the

365


result, the system has to store already computed figures for further comparison. So PDSIS has to handle this situation and ask the user whether to abandon the results in the current user session or reject it. This issue is only an application-internal feature and therefore not mentioned in the general workflow (see F.17-1).

Beside this refusing back-tracking to a previously executed process, the workflow con-tinues if the user accepts the computed results. In that case, the integration system goes on to the next process “Monitoring”, which is different to the other automatically execut-able steps. Nevertheless it will also start with the mediator internal workflow for searching appropriate systems, decision for a concrete DSS and retrieving input data and several parameters (see also F.17-2). The last steps concerning retrieving of system specific infor-mation for computation, the computed results of the previous computation will be taken as input parameters, but it is possible to transmit additional data and parameters if it is important for the next execution.

Furthermore, the execution of the monitoring is not directly covered by the integra-tion system, but it will hold on at this point and only display configuration tasks, which are required for the chosen system to compute measures. These measures will be displayed by the PDSIS online and live via streaming within the workflow, but the user only sees key figures and mash-ups of the computed measures, e. g. how many figures are computed at a certain time stamp, which time range is available, have there been any problems during monitoring and, if yes, which figures are affected, etc. The user can decide at any point of the monitoring process to continue with the workflow and to take the retrieved measure-ments as input data for the next process. The user can also cancel the monitoring analogi-cal to the “Campaign Planning”, but s/he has to do this manually, so the integration system can only get the notification from the system, whether the current monitoring is finished or cancelled.

After finishing or cancelling of the monitoring process, the workflow continues similar to the “Campaign Planning”, so computed results will be stored in session if the user wants to compare different results and the application flow continues with the next step “Data Preparation” or delegates the user back to a previous step.

The mediator interaction, computation, execution and validation of “Data Prepara-tion” and “Assessment” are handled similarly to the previous steps (see also F.17-1).

The last step “Workflow Summary” is more specific, but not complex, so the overall in-tegration system and the superordinate PDSIS will show a summary for each process step: chosen system, transmitted input data and parameters, retrieved results or error reports if computation failed and the entire user validation. General information and descriptions of the systems and the specific processes as well as user comments on computed results will also be displayed. At this point the user has the last chance to step back to a specific process and to recover input and output data for re-computation, so if the user proceeds to finish the workflow, the results will be stored within an PDSIS specific database, which has nothing to do with the storage of the data of a certain domain. This database is only for purposes of the PDSIS and the integration system as well for the mediator itself.

366


Thing

Quality

Modal analysis

Location

Input parameter

Frequency spectrum

PDSIS item

Company Device

System

IRIS Data SetTime series

StatementDSS item type

PDSIS concept

Low pass �lter

Process step type

Parameter

Physical entity

Resource

Time domain analysis

Digital frequency �lter

Frequency domain analysis

Operational modal analysis

Filtered time series

Measuring instrument

Core integration ontology F.17-8

17-6 Semantic Integration of Decision Support Systems

The topic of semantic data integration is a widespread area of different definitions and implementations mainly regarding the alignment, matching, merging or interchange of different schemes and structures not only through their syntactical behaviour, but also by interpreting and analyzing their semantics. Due to this description an overall semantic model with focus on IRIS was developed [Buccela et al., 2003]:

Definition. An integration model for DSS in SHM ( I ) is defined as a set of systems (S ) which contains knowledge about the type of needed parameters and process steps (P ), which are mapped (together) by matching their inputs (In) and outputs (Out) such that for each described system there is at least one adequate process step; otherwise the system description is not appropriate (inappropriate systems will be handled as semantically in-valid). Therefore the following constraint must be satisfied by the ontology for integrating heterogeneous DSS:

: : : : ( . . . . )x S p P i In o Out p i x i p o x o∀ ∃ ∃ ∃ = ∧ = (integrity constraint)

Furthermore, o and i are only semantic descriptions of outputs and inputs provided by a certain system and needed by specific process steps. The DSS integration approach classifies systems based on the constraint above by matching their inputs and outputs and therefore classifying a system or not.

367

Semantic Integration of Decision Support Systems 17-6

Choose operator

Start/proceed computation

Logout

Send login data

Start new work�ow Lookup for operator settings[jena-call: select ?optwhere{?opt rdfs:type ?type}.]

loop {while !authenticated}

loop {while !(work�ow �nished)}

Lookup foroperator

Executiveoperator

Lookup for operator settings

Receive server result

Render result set Retrieve result set

Store result set

Show login page

Finalize work�ow

Show summary

Render collection ofoperators

Retrieve collection of operators

Retrieve operator meta data

Upload input & execute operator

Render parameters& description

Web client PDSIS IRISServices IRISServices is an application, which covers several web services in the area of IRIS developed by the Institute for Application-Oriented Knowledge Processing (FAW), e.g. mediator for PDSIS

At this stage of execution, a reasoner (e.g. pellet) will compute the integration ontology assert certain process-step-type classes (e.g. data preparation, assessment) to the stored operators (e.g. outlier) and classi�es them as adequate for a certain analysis type.

Sequence diagram – interaction of web client, PDSIS and IRISServices F.17-9

The ontology was developed by using Protégé (current version 4.1 Beta) and consists of 150 classes, 335 object properties, 32 data properties and currently 240 individuals and their axioms. The TBox and ABox are not finished and will be enhanced in the future. Therefore it is currently not possible to clarify the complexity of the ontology and the performance of the whole proposal, but it is one of the major tasks to be declared in the future work.

The Core Integration Ontology contains all classes, properties and individuals, which are needed for describing several semantic structures of specific operators, which are used within DSSs. Hence, the most important connection between PDSIS and the Integration Ontology, stored in a separate OWL-File (Ontology Web Language; structures and indi-viduals are not stored independently, but this will be part of the future issues concerning the size and performance of the ontology itself ), is the property “shortName”. This prop-erty contains the textual name of the specific operation, which will also be specified in a property file of PDSIS and contains meta-information (not necessary for reasoning and therefore not stored in the ontology) concerning the execution and interaction. Further-more the interaction model described in the previous section was enhanced and realized through two independent web applications: PDSIS and IRISServices. The first application is the pure web application already discussed. The second application is intended to be

368


used as a service handler for all available services in IRIS. Actually, IRISServices contains the mediator component, which is a web service for handling the communication be-tween the integration ontology (and also the execution of the reasoner), but it is capable of integrating other web services, e. g. the FAW case-based reasoning approach [Bunge, 1977].

The introduced mediator delivers several operations for look up of available opera-tions concerning a given process step type (lookupOperatorsByType), the retrieving of parameter information and datatypes (getParametersByOperatorName) and the execu-tion (executeOperator). Furthermore the mediator is implemented as a Java Web Services, which communicates via SOAP messages with PDSIS. Therefore, the interaction model envisions basic Java classes like collections, or simple object items.

The results of this refinement can be found in F.17-9. Interaction with PDSIS starts by logging in to the web application with a pre-defined user name and password (both stored encrypted in the PDSIS databases, which covers the meta information of all work-flows and system executions). Beside the clearly structured page and content, the web-application is designed to be multilingual.

17-7 Integrated Decision Support SystemsNumerous DSSs have been integrated to seamlessly work with PDSIS within the IRIS

project. The chosen DSS cover several distinct and important fields within the areas of statistical computing, numerical computing, machine-learning and custom proprietary scripts. The following DSS have been, among others, integrated to work with PDSIS:

17-7-1 RapidMiner

A data mining toolkit, well-suited for processing very large data pools and performing various analytical tasks. Being open source, it offers a programming interface and is pri-marily intended for data mining [Davenport and Prusak, 2000] operations which makes it a considerable utility for Decision Support. At the time of this writing, the mediator service fully implements the RapidMiner Fast Fourier Transformation and Principal Component Analysis functionalities.

17-7-2 WEKA

Originating from the University of Waikato, WEKA (Waikato Environment for Knowl-edge Analysis) [Cui and O’Brien, 2000] aims to be a versatile framework for machine learning and predictive modelling including but not limited to pre-processing, text-learn-ing and clustering. Currently, the corresponding IRIS mediator implements Wavelet trans-formation using the standard WEKA Java API. The specific notification workflow can be interpreted as analogous to RapidMiner.

369

Hands on: Integrating R as Decision Support System for Time Series Analysis 17-8

17-7-3 R (GNU S)

As opposed to the two frameworks outlined above, R [Freudenthaler, 2009] is a non-graphical programming language for statistical computations and became a de facto standard for statistical software development. R implements the S programming lan-guage and originates from the University of Auckland. Since R is not developed in Java, it does not offer integrated programming interfaces like RapidMiner and WEKA, although certain third-party expression evaluator interfaces exist [Lenzerini, 2002]. Currently, R has not yet been implemented as mediator service within PDSIS, but approaches towards in-cluding R through either web-services or socket communication are in progress. Further-more, R also supports graphical plotting which, at this time, is not intended to be utilized by PDSIS.

17-7-4 MATLAB (GNU Octave)

MATLAB, and its free open-source equivalent GNU Octave, are programming languag-es intended for numerical computations. It is interpreter-based yet very fast, offers com-mand-line and API interfaces and may be extended through various dynamically loadable modules. This DSS has been chosen, since many companies utilize MATLAB or GNU Octave for calculations and have already implemented extensive scripts which have proven to offer industrial-strength.

17-8 Hands on: Integrating R as Decision Support System for Time Series Analysis

17-8-1 What is R?

R is a programming language and software environment for statistical computing and graphics. The R language has become a de facto standard among statisticians for the de-velopment of statistical software, and is widely used for statistical software development and data analysis. R is an implementation of the S programming language created by John Chambers while at Bell Labs combined with lexical scoping semantics inspired by Scheme. R was created by Ross Ihaka and Robert Gentleman at the University of Auckland, New Zealand, and is now developed by the R Development Core Team. R provides a wide variety of statistical and graphical techniques, including linear and non-linear modelling, classical statistical tests, time-series analysis, classification, clustering, and others. R, like S, is designed to be a true computer language, and it allows users to add additional func-tionality by defining new functions. R has many features in common with both functional and object oriented programming languages. In particular, functions in R are treated as objects that can be manipulated or used recursively. The capabilities of R are extended through user-submitted packages, which allow specialized statistical techniques, graphi-cal devices, as well as import/export capabilities to many external data formats.

370


17-8-2 Time Series Analysis

Time series are used in a wide range of domains, especially in econometrics, for exam-ple in predicting the opening price of a stock based on its past performance, or computing the interest rates or the monthly rates of unemployment. Beside economics, time series are also used in natural sciences, like meteorology: recording the hourly wind speeds, the daily maximum/minimum temperatures, the annual rainfall or in geophysics: recording the shaking or trembling of the earth in order to predict possible earthquakes. There are also several examples of time series in social sciences: the annual death and birth rates, number of accidents in the home, recording criminal activities, etc. All these examples show us that time series analysis plays an important role in our daily life and they require special analysis methodologies.

What is different about time series, compared to other data, is that they have a natu-ral temporal ordering. This makes time series analysis distinct from other common data analysis problems, in which there is no natural ordering of the observations. A time series model generally reflects the fact that observations close together in time are more closely related than observations further apart. In addition, time series models often make use of the natural one-way ordering of time so that values for a given period are expressed as derived in some way from past values, rather than from future values.

What is the scope of time series analysis? Mainly, when we study time series data we try to gain a better understanding of the data, predict future values, optimally control sys-tems, monitor processes, derive computer simulations, prepare countermeasures in case of unexpected events, improve output/quality/performance of a system, etc. Time series analysis can be, among others, used for:

1) Forecasting

First, and the most common one is forecasting or predicting. The idea is to use obser-vations from a time series available at time t to forecast its value at some future time t l+ . First, suppose that observations are available at discrete, equispaced intervals of time. As input we have the observations generated until time t : 1 2 3, , , ,t t t tz z z z- - -

The output should be a function žt( l ), 1,2,l = , which is also called the forecast func-tion. It will provide the forecasts at origin t for all future lead times. Our goal is to obtain a forecast function such that the mean square of the deviations zt+1-žt( l ) is as small as possible. As an example, if we wanted to predict future values for the next year for the air passengers time series, we would like to obtain a function that describes the behaviour of future data:

2) Determine Relationship between Input and Output

The second problem is the estimation of transfer functions, which will enable us to determine a relationship between, usually, input and output time series. A transfer func-tion can relate an input process Xt to an output process Yt through a linear relationship, for instance. More precisely, we express Yt (output) as a linear dependency of the previous input values t t-1 t-2X ,X ,X , given by t j j t-jY v X , j 0,= Σ =

The input in this case is the rate of air supply and the output is the concentration of carbon dioxide (CO2) that is produced in the furnace. The observations were made at

371

Hands on: Integrating R as Decision Support System for Time Series Analysis 17-8

800

700

600

500

400

300

200

100

1950 1952 1954 1956

Forecasts from ETS (M,A,M)1958 1960 1962

Using time-series analysis for forecasting purposes F.17-10

intervals of nine seconds and the linear dependency detected is given by the values of vi. Another important application of the transfer function models is in forecasting. If, for example, the dynamic relationship between two time series Xt and Yt can be determined, past values of both series may be used to predict Yt. In some situations this apporach might lead to a considerable reduction of the estimation error.

3) Analyze Effects of Unusual Events

Time series are often affected by special events or circumstances such as policy chang-es, strikes, advertising promotions, environmental regulations, and similar events, which are usually called intervention events. Examples of such intervention include the incorpo-ration of new environmental regulations, economic policy changes, strikes and promo-tion events.

In this case intervention analysis is performed in order to obtain a quantitative meas-ure of the impact of the event of the time series or to adjust for any unusual values in the series that might have resulted as a consequence of the intervention event. This will en-sure that the results of the time series analysis, like the structure of the model or estimates of the model parameters or forecasts of future values, are not seriously distorted by the influence of these unusual events.

4) Process Control

The fourth application of time series analysis is in discrete control of systems. There are some important scientific notions that need to be explained before. Process control means controlling the output of a specific process usually used in engineering and statis-tics. A subdomain of process control is statistical process control (SPC), which deals with monitoring a process using statistical tools, like control charts. The main idea here is to detect and correct variations in the process that might affect the quality of the end prod-uct or service.

372


4·10−05

7·10−09

40000

60000

Intensity

Eigenfrequency

Bridge ID

GNU R kmeans clustering with PDSIS based on eigenfrequencies of a bridge F.17-11

17-8-3 Integration

R has been integrated within PDSIS as generically usable service. R scripts can be run natively within the operator execution process of PDSIS, regardless of what calculations are actually done. This dramatically increases the opportunities instead of only imple-menting one specific calculation task done with R.

As with almost all other available operators, R has been equipped with a PDSIS-wrap-per which basically resembles a number of standardized interface programme calls, like perform-operation and retrieve-results. These interfaces allow seamless and easy integra-tion of multiple DSS which may offer completely different and heterogeneous usages. PDSIS takes care of consistent data alignment in a manner, which enables us to pipeline multiple DSS in both, sequential and parallel manner. This eases comparability of results as well as, if needed, iterating through multiple pre- and post-processing steps which, in turn, may also consist of the execution of operators. This makes PDSIS an utterly versatile tool for Decision Support, and aims to be independent from data formats, implementa-tion details, technical dependencies and service availability.

As a real-life example, F.17-11 shows a graphical representation of a calculation made with a custom-made GNU R script, which can be directly accessed using the PDSIS system. After pre-processing the initial data pool, which has been gathered using the BRIMOS® system in the first place, the data can be pipelined into a kmeans time-series computation done via GNU R.

373

Conclusion and Outlook 17-9

17-9 Conclusion and OutlookWith PDSIS, we have shown that utilizing multiple different DSSs can significantly

improve computation results within the frame of structural health monitoring. GNU R, among multiple other DSS, can be used for data processing in order to analyze and per-form qualitative as well as quantitative analysis of measurement data and can dramati-cally ease and assist in localizing damages and projecting estimated structural lifetimes. The utilization of Passive Decision Support in conjunction with semantic technologies like Ontologies within an integrated environment can effectively simplify the decision making process and all necessary computational steps in order to do so.

Future research and development strategies are supposed to cover an even more in-depth approach towards seamless integration, communication, data forwarding and in-put/output pipelining from and to distinct DSSs. In order to achieve this, the design of the utilized ontologies in question is still to be refined and broadened for being applicable to as many situations and scenarios as possible, in a more generalized manner.

As the PDSIS system suggests, more experimental calculations and data processing tasks have to be done for the system to enhance its capability of suggesting certain DSSs to a user who wants to find suitable components and processing strategies for a given task. This especially affects the sequential chaining of multiple DSSs for task completion, as well as the hereby strictly necessary normalization and unification of numerical data in order to do so.

Also, the inclusion of new DSS components from a pragmatic and developer-specific point of view is expected to be even easier than now. Given a sufficiently capable ontol-ogy for doing so, the higher goal is to be able to add new DSSs almost autonomously without major human intervention, similar to a plug-in based architectural software de-sign, augmented by the utilization of semantic technologies.

Moreover, as more generalized and abstract the high-level design and its correspond-ing ontologies become, the higher the chances will be for the PDSIS framework to be capable of being a useful toolkit far beyond its initial primary focus within the IRIS project itself. Therefore, the framework is not restricted to being used for SHM only, but also for a broad variety of other conceivable scenarios, especially towards (but not limited to) time series analysis based ones, like climate science, earthquake engineering and disaster sce-narios.

We believe that passive Decision Support can dramatically ease the decision making process for both, professionals and non-professionals, and can be applied to virtually eve-ry computational task whose outcome relies on analysing number series and performing calculations thereupon. Once the corresponding common infrastructure is established and certain semantic technologies are used and mutually agreed upon, passive Decision Support may seriously assist in choosing the right DSS, speeding up the decision making process, and narrowing down or even eliminating potential sources of errors.

374


ReferencesBuccella, A., Cechich, A. and Brisaboa, N. R., 2003. An Ontology Approach to Data Integra-

tion. Journal of Computer Science and Technology. Springer, Berlin/Heidelberg, 3:62–68.Bunge, M., 1977. Treatise on Basis Philosophy. Ontology I: The Furniture of the World.

Springer, New York, 1.Cheng, H. G., 2003. Representing and Reasoning about Semantic Conflicts in Heterogeneous

Information Sources. Ontology-based Integration of Heterogeneous Decision Support Systems for SHM, MIT Press, Massachusetts.

Cruz, I. F. and Xiao, H.,2005. The Role of Ontologies in Data Integration. In: International Journal of Engineering Intelligent Systems for Electrical Engineering and Communica-tions, CRL Publishing, Leicester, 13(4):245–252.

Cui, Z. and O’Brien, P., 2000. Domain Ontology Management Environment. In: Hawaii Inter-national Conference on System Sciences, IEEE Computer Science, 8:1–9, Washington.

Davenport, T. and Prusak, L., 2009. Working Knowledge. Harvard School Press, Boston.Freudenthaler, B., 2009. Case-Based Decision Support for Structural Health Monitoring. PhD

thesis, Johannes Kepler University, Linz.Gruber, T., 1993. A Translation Approach to Portable Ontology Specifications. Knowledge

Acquisition, 5(2):199–220, Academic Press Ltd., London. Guarino, N. and Giaretta, P., 1995. Ontologies and Knowledge Bases: Towards a Terminolog-

ical Clarification. In: Mars, N. I. J. (ed.) Towards very large knowledge bases: knowledge building and knowledge sharing, ISO Press, Amsterdam, 24–32.

Lenzerini, M., 2002. Data Integration: A Theoretical Perspective. In: 21st Symposium on Prin-ciples of Database Systems. Madison, New York, 233–246.

Oszu, M. T. and Valduriez, P., 1999. Principles of Distributed Database Systems. 2nd ed., Pren-tice Hall, New Jersey.

Siringoringo, D. M., Nagayama, T., Fujino, Y., Su, D., Chondro and Tandian, C., 2009. Dy-namic Characteristics of an Overpass Bridge During a Distructive Test. Bridge and Struc-ture Laboratory Internal Report.

Wenzel, H. and Pichler, D., 2005. Ambient Vibration Monitoring. John Wiley & Sons Ltd., UK.Wenzel, H., 2008. Health Monitoring of Bridges. John Wiley & Sons Ltd., UK.Anderlik, S., Stumptner, R., Freudenthaler, B. and Fritz, M., 2010. A Proposal for Ontol-

ogy-based Integration of Heterogeneous Decision Support Systems for Structural Health Monitoring. In: The 12th International Conference on Information Integration and Web Based Applications & Services (iiWAS2010).

Utilizing Ontologies to Integrate Heterogeneous Decision ... · of precision that they can be used...

Documents

Transcript of Utilizing Ontologies to Integrate Heterogeneous Decision ... · of precision that they can be used...