OWL-FC: an upper ontology for semantic modeling ... - Semantic Scholar

Soft Comput (2012) 16:1153–1164 DOI 10.1007/s00500-011-0790-4

FOCUS

OWL-FC: an upper ontology for semantic modeling of Fuzzy Control C. De Maio • G. Fenza • D. Furno V. Loia • S. Senatore

•

Published online: 9 November 2011 Springer-Verlag 2011

Abstract This work introduces an OWL-based upper ontology, called OWL-FC (Ontology Web Language for Fuzzy Control), capable to support a semantic definition of Fuzzy Control. It focuses on the fuzzy rules representation by providing domain independent ontology, supporting interoperability and favoring domain ontologies re-usability. The main contribution is that OWL-FC exploits Fuzzy Logic in OWL to model vagueness and uncertainty of the real world. Moreover, OWL-FC enables automatic discovery and execution of fuzzy controllers, by means of context aware parameter setting: appropriate controllers can be activated, depending on the parameters proactively identified in the work environment. In fact, the semantic modeling of concepts allows the characterization of constraints and restrictions for the identification of the right matches between concepts and individuals. OWL-FC ontology provides a wide, semantic-based interoperability among different domain ontologies, through the specification of fuzzy concepts, independently by the application domain. Then, OWL-FC is coherent to the Semantic Web infrastructure and avoids inconsistencies in the ontology.

C. De Maio (&) G. Fenza D. Furno V. Loia S. Senatore CORISA (Consorzio Ricerca Sistemi ad Agenti), Dipartimento di Informatica, Universita´ degli Studi di Salerno, via Ponte don Melillo, 84084 Fisciano (SA), Italy e-mail: [email protected] G. Fenza e-mail: [email protected] D. Furno e-mail: [email protected] V. Loia e-mail: [email protected] S. Senatore e-mail: [email protected]

Keywords

Ontology OWL-S Fuzzy Control

1 Introduction The Semantic Web has contributed to change the models of communication and interactions in last decades, with a profound impact on the human society. It defines a new model to connect different sources of information such as web pages, posts, databases, etc., which enable computers and people to work in co-operation. Past research in Semantic Web attracted attention of two-value-based logical methods, but more recent trends aim at handling imprecise or uncertain information encountered in real world knowledge (Sanche 2006), through fuzzy models which can reinforce semantic-based systems and bridge the gap between vague human-understanding and hard machine-processing. The use of fuzzy techniques in the ontology modeling can provide an adequate add-on to reflect real world capture uncertainty in the relationship and conceptual information. This paper presents an OWL-based upper ontology, called OWL-FC (Ontology Web Language for Fuzzy Control) which, by means of a set of markup language constructs, provides semantic specification of Fuzzy Control in a high-level, semantic form. OWL-FC has been designed by completely reflecting the modeling of OWL-S (Martin et al. 2004). In fact, we have built a parallel model for the deployment of the fuzzy control (instead of OWL-S web service) capabilities, through the three homonymic modules: ‘‘Profile’’, ‘‘Model’’ and ‘‘Grounding’’, (details are given in Sect. 3). Behind the benefits of a high-level abstraction language of specification, this modeling can easily translate and deploy a Fuzzy Control in a web service.

123

1154

OWL-FC ontology provides a stable abstract model to represent fuzzy knowledge for describing fuzzy controls. In fact, one of the main advantages is the definition of an ontology which is independent of the knowledge domain: the same model is exploited to represent different fuzzy controls and environments. Thanks to this independence, OWL-FC ontology guarantees a clear separation between domain knowledge and fuzzy controllers implementation. Moreover, other benefits of OWL-FC are the automatic execution of defined controllers as well as the support to their discovery (i.e., in the case of matchmaking algorithm design) by enabling context aware parametrization of the controllers. The paper is structured as follows. Section 2 surveys the related works; Sect. 3 briefly introduces the role of OWL-s in the characterization of our upper ontology. Then, Sect. 4 describes the Fuzzy Control and the OWL-based modeling. Additional details about the relative OWL-based coding are given in Sects. 5–8, where the mapping of our ontology into a three-layer structuring is shown. An application scenario depicted in Sect. 9 emphasizes the high flexibility of OWL-FC in modeling Fuzzy Control and its independence from domain ontologies. Finally, considerations and conclusions close the paper.

2 Related works The imprecise nature of real world information has pushed scientific community to model knowledge representation systems for the representation and management of uncertainty, imprecision and vague knowledge. The conceptual formalism embedded in a common ontology is often based on crisp logic and may not suitable to represent uncertainty, due to the lack of a clear separation between domain concepts (Zhai et al. 2008). Introducing tolerance for imprecision, through the use of Fuzzy Logic, may be exploited in a great number of application fields. In literature, fuzzy ontologies have been exploited to deal with fuzzy knowledge in many application domains, such us text, image and multimedia objects representation and retrieval (Parr 2004; Ren et al. 2008). Lee et al. (2005) proposed an algorithm to create fuzzy ontology for news summarization; in Tho et al. (2006), a Fuzzy Ontology Generation Framework (FOGA) for fuzzy ontology generation on uncertainty information has been presented. In Abulaish (2006), a fuzzy ontology framework has been defined, where a concept description is represented by a fuzzy relation which encodes the degree of a property value using a fuzzy membership function. Other trends aimed at producing vague information representation have triggered a mass of theoretical and applied researches about fuzzy ontologies, whose main logical infrastructures are Fuzzy

123

C. De Maio et al.

Description Logics (briefly Fuzzy DLs). Classical DLs with fuzzy capabilities yielding Fuzzy DLs have been developed to represent the uncertainty in the Semantic Web: Straccia proposed a fuzzy extension of DL ALC (a fragment of Description Logic, whose acronym stands for Attributive Language with Complements), called F ALC in which fuzzy semantics is introduced to describe concepts and roles as fuzzy sets (Stracci 2001) and then, in Stracci (2005), a fuzzy extension of SHOIN ðDÞ, i.e., a fuzzy version of the ontology description language OWLDL and its syntax and semantics. Stoilos et al. (2006) discuss Fuzzy OWL and uncertainty representation with rules. They present a fuzzy reasoning engine that implements a reasoning algorithm for a fuzzy DL language f KD SHIN . It handles most of OWL features. Yet, the implementation is proprietary and not directly compatible with any established Semantic Web technologies and tools. Despite this trend, OWL-FC is not a fuzzy ontology but provides Description Logic constructs useful to represent fuzzy controllers and enable their discovery and execution. Furthermore, OWL-FC is an OWL-like language thus it is compatible with existing Semantic Web standards. Among the scientific works on the development of reasoning engines for the interpretation of imprecise knowledge, closely related to our approach, there are several proposals. On the one hand, XML technologies have already been used for modeling fuzzy controllers. Indeed, Acampora and Loia (2011) designed the Fuzzy Markup Language (FML), a novel computer language skilled for defining detailed structure of Fuzzy Control independent of its legacy representation. Even though it was designed for defining the behavior of heterogeneous hardware in the context of ambient intelligence, it is successfully combined with fuzzy ontologies in order to be applied to several application domains (Lee et al. 2010). On the other hand, in the literature, there are proposal for fuzzy extensions of Semantic Web Rule Language (briefly, SWRL),1 which is a rule extension to OWL DL. In Pan et al. (2006), a fuzzy SWRL (f-SWRL) has been defined. It includes fuzzy assertions and fuzzy rules, even though no implementation details are given as highlighted in Agarwal (2005); f-SWRL actually offers no fuzziness in the rules definition. Bobillo et al. (2009) instead present a semantic fuzzy expert system for a fuzzy balanced scorecard. They use OWL ontology to represent knowledge about variables and provide an interface to FuzzyJess to execute fuzzy rules. Similarly, Wlodarczyk et al. (2011) proposes SWRL-F, whose aim is to provide a fuzzy logic extension to SWRL, based on the standard OWL DL ontology language and SWRL rule language. One of the benefits introduced by SWRL-F ontology is that it enables 1

http://www.w3.org/Submission/SWRL/.

OWL-FC: an upper ontology for semantic modeling of Fuzzy Control

the description of fuzzy logic knowledge and its application in SWRL rules. Similar to f-SWRL and SWRL-F, our approach presents a definition and implementation of a control system based on the well-known scheme: collect crisp inputs, fuzzify inputs, perform fuzzy inference, defuzzify inputs, apply crisp outputs. In particular, our system exploits an OWL-based upper ontology to allow semantic definition of a Fuzzy Control. Moreover, it enables a context aware discovery of Fuzzy Control for autonomous Fuzzy Control usage.

3 OWL-FC: an upper ontology for the Fuzzy Control The structure and the characterization of our ontology OWL-FC strictly reflect the modeling of OWL-S (Martin et al. 2004). Our idea is, indeed, to provide an upper ontology which naturally reproduces the model of OWL-S used to apply semantic descriptions to Web Services. OWL-S enables the deployment of the web services capabilities, through the three modules: ServiceProfile, ServiceModel and ServiceGrounding. Generally speaking, the ServiceProfile provides the information needed to discover a service, while the ServiceModel and ServiceGrounding, together, enable the use of a service, once found it. Similarly, our model of OWL-FC provides a complete description of the Fuzzy Control capabilities, through the three homonymic modules: ‘‘Profile’’, ‘‘Model’’ and ‘‘Grounding’’. While, in the OWL modeling, the goal of dynamic publishing and discovering of web services, driven by agents and supported by ontologies, may be reached exploiting OWL-S languages as a qualified OWL-based support for semantic web services, analogously, we can say that the definition of OWL-FC aims at supporting mapping and conversion between fuzzy controls generated by different fuzzy systems or legacy environments, through a common, high-level abstraction of the specification and semantics. As a consequence of the described strict analogy of OWL-FC with OWL-S, a natural, trivial conversion of the OWL-FC Profile into OWL-S ServiceProfile enables the deployment of the Fuzzy Control in the form of a simple web service. Using ontology to support fuzzy controls specification enables the semantic definition of services.

1155

The class FuzzyControl specifies a control system based on fuzzy logic. Fuzzy controllers consist of an input stage, a processing stage, and an output stage. The input maps inputs to the appropriate membership functions and truth values. The processing stage invokes each appropriate rule and generates a result for each, then combines the results of the rules. Finally, the output stage converts the combined result back into a specific control output value. As OWL-FC structure completely reflects the OWL-S structure, our ontology structuring for Fuzzy Control is based on three essential types of knowledge about a FuzzyControl (shown in Fig. 1), in accordance with the following associated questions: •

• •

What does the Fuzzy Control? The layer ‘‘Profile’’ is the answer to this question, because it shows the main characteristics of the control. How does it work? The ‘‘Model’’ shows how the Fuzzy Control is used in process. How does one interact with it? The ‘‘Grounding’’ supplies the details of interaction and communication: more specifically, maps the semantic form of messages (according to the format and input/output specification provided in a process model) to the low-level protocol language. Moreover, the Grounding specifies, for each semantic type of parameters specified in the Model, the way of exchanging data elements (i.e., the serialization techniques employed). This module is not yet implemented in this OWL-FC modeling.

The class FuzzyControl represents a reference class for a declared Fuzzy Control (see Fig. 1); an instance of the class FuzzyControl exists for each distinct Fuzzy Control which has been defined. As shown in Fig. 1, this class has associated three properties: presents, describedBy and supports. Obviously, the classes Profile, Model, and Grounding are the ranges (i.e., targets) of those properties, respectively. Each instance of FuzzyControl presents a Profile description, describedBy a Model description, and

4 OWL-FC: Fuzzy Control representation As said, OWL-FC is an upper ontology to model the Fuzzy Control process. In this section, we describe the main class of OWL-FC Ontology, in particular, the classes Fuzzy Control, Profile and Model are defined, through hierarchy structures, relevant entities and their relationships, rules, axioms, etc.

Fig. 1 The Fuzzy Control representation in OWL-FC

123

1156

C. De Maio et al.

supports the modality of accessing and communication protocol, defined by the Grounding description. The details of Profiles, Models, and Groundings may vary from one type of control to another one, i.e., from one instance of FuzzyControl to another one. They are needed to specify a Fuzzy Control. In particular, Profiles and Models provide details about Fuzzy Control process, whereas the Groundings bind to the specific implementation protocol. An example of a instance of FuzzyControl is given in Listing 1.

This code defines an instance of FuzzyControl concept (or class), identified as ‘‘FuzzyControl_1’’. It presents what is accomplished by the Fuzzy Control, by an instance named ‘‘Profile_3’’ of the class Profile, is described by an instance named ‘‘Model_2’’ of the concept Model and supports the communication protocol by the instance ‘‘Grounding_0’’ of the concept Grounding.

3. 4.

hasOutput: its range is composed of instances of the class Output, as defined in the ontology. outputOf: is the inverse of hasOutput and links an output to a specific Profile.

However, there are many other properties associated with the class Profile; some of them, intended for human consumption, others useful to attach context parameters to a Fuzzy Control definition. Some example are: • • •

textDescription: is the description of the Profile. hasName: is the name connected with the Profile. hasParameter: allow adding some parameters, in order to enhance context aware discovery capabilities, once associated with the right Fuzzy Control. In fact, using the OWL subclassing it is possible to create specialized ad hoc parameters useful to specify environmental features such as coordinates, geographic radius, etc.

The code in Listing 2 describes a simple OW-FC Profile instance.

5 Profile As said above, the class Profile describes ‘‘what the FuzzyControl does’’. According to the characterization of a fuzzy control, this class specifies the functional description of the Fuzzy Control in terms of inputs and outputs. Furthermore, the profile allows the description of non-functional properties that are used to describe features of the Fuzzy Control. Let us analyze the main characteristics of this class. As shown in Fig. 2, there is a two-way relation between FuzzyControl and Profile, described by the properties presents and presentedBy: 1.

2.

presents: is a relation between an instance of FuzzyControl and an instance of Profile, it basically says that a Fuzzy Control is represented by a profile. presentedBy: is the inverse of presents; it specifies that a given profile represent a Fuzzy Control.

In Fig. 2, the concepts Input and Output are associated with the FuzzyControl by the class Profile, through the functionality properties: 1. 2.

hasInput: the range of this property is composed of the instances of the class Input. inputOf: is the inverse of hasInput, it links an input to a specific class Profile.

123

This code defines an instance of a FuzzyControl for detecting risk of landslide. The functional description of the Fuzzy Control is represented by the instance of Profile identified by ‘‘Profile_3’’ and referencing to instances of Input and Output. Specifically, their definitions are linked to the concepts of ontology domain Humidity and Rainfall (Input), RiskLanslide (Output). Furthermore, a geographic feature (i.e., OnTheCoast) and a seasonal one (i.e., Winter) are specified by means of the properties hasParameter, associated with the Profile. 5.1 Input The class Input describes a concept given as input to the Fuzzy Control process. Each instance of Input is identified by a name and an identifier through the properties hasName and rdf:ID, respectively. The specification of Input plays the key role to mediate between concepts in the domain knowledge and its fuzzy modeling. In fact, each instance of the class Input has two properties: hasURI and hasFuzzyConceptInput. The first one associates the Input to the concept or property of the domain


1157

Fig. 2 The OWL-FC Profile representation

ontology; the second one connects Input to the class FuzzyConceptInput that defines the fuzzification of the domain concept specified by hasURI. An instance of the class FuzzyConceptInput represents a specific fuzzy concept. Just to give an example, Listing 3 defines inputs of the Fuzzy Control associated with the previous definition of Profile.

Each instance of Output is connected, through the property hasFuzzyConceptOutput, to FuzzyConceptOutput. Differently from FuzzyConceptInput, FuzzyConceptOutput can be used in the defuzzification of Fuzzy Control model. Let us note in Fig. 2, the class FuzzyConceptOutput is connected to the class Defuzzifier by means of the properties isFCOutput and its inverse hasFCOutput.

6 Model The class Model gives a description about how the fuzzy control works. Similar to the class Profile, there is a twoway relation between the classesFuzzyControl and Model, as shown in Fig. 3. These relations are expressed by the properties describes and describedBy, detailed as follows: The aim is to introduce a fuzzy modeling of the domain concepts Humidity, Rainfall (identified, respectively, as ‘‘http:… #Humidity and ‘‘http:… #Rainfall’’). The given code evidences the connections between the concepts Humidity and Rainfall of the domain ontology to our upper ontology. 5.2 Output This class represents a concept given as output to the Fuzzy Control process. Like the class Input, this concept has associated two properties hasName and hasUri. Listing 4 defines the fuzzy concept output RiskLanslide (identified ‘‘http:… #RiskLanslide’’) associated with the previous instance of Profile.

1.

2.

describes: represents a relation which exists between an instance of FuzzyControl and an instance of Model. In other words, it asserts that a Model describes a FuzzyControl. describedBy: this is the inverse property of describes.

Figure 3 shows a representation of the model process, introducing all the steps of a Fuzzy Control process. The three main phases are described by the following three corresponding classes: Fuzzification, Inference and Defuzzification. Let us note the Model class contains a single class Fuzzification, a single class Defuzzification and multiple specializations of the Inference class. The main properties that connect the Model class with these ones are:

123

1158

C. De Maio et al.

Fig. 3 The Model process representation

1.

2. 3.

hasFuzzification: this property binds the Model class with the Fuzzification class and assumes values in the range of the class Fuzzification. hasDefuzzification: similarly, it acts between the classes Model and Defuzzification. hasInferences: this property has as range the abstract class Inference, which is, in turn, specialized in the classes MamdaniInference and TSKInference. These classes are the main inference methods applied on the Fuzzy Control.

The OWL code in Listing 5 is associated with the Model class.

In the model process representation of Fig. 3, a relation between the classes Fuzzification to FuzzyConceptInput has been defined through the property hasFuzzyConcept. An example of OWL-code describing an instance of the class Fuzzification is given in Listing 6 as follows:

Herein, the instance Fuzzification_5 of the class Fuzzification takes two fuzzy concepts as input, named, respectively, HumidityFC and RainfallFC. 6.2 Inference

The code defines an instance of the class Model named ‘‘Model_2’’. It is defined by the instances of the classes Fuzzification, Inference and Defuzzification, identified by ‘‘Fuzzification_5’’, ‘‘MamdaniInference_8’’ and ‘‘Defuzzification_4’’, respectively. 6.1 Fuzzification The class Fuzzification is crucial to the Fuzzy Control process. The fuzzification procedure achieves the process to convert an element in the universe of discourse (typically, crisp values) into a membership value of the fuzzy set. Just to give an example, let us suppose a fuzzy set A is defined through a membership function lA on the interval [a, b]; for any x 2 ½a; b; lA ðxÞ is the fuzzification value associated with the value x.

123

Fuzzy inference defines the mapping from a given input to an output using Fuzzy Logic. It is associated with a fuzzy if–then rules base, which represents control strategy or modeling knowledge/experience. For each rule, the inference engine looks up the membership values of the input variables in the antecedent part of the rule. The ‘‘activation’’ of the premise of the rule inducts the conclusion of the rule, i.e., the outcome for output variable(s) in the consequent part of a rule. The main fuzzy inference schemas are Mamdani and Takagi-Sugeno (TSK, for short) fuzzy rules. Each inference schema exploits a set of operators for combining the variables in the rules. In Fig. 3, MamdaniInference and TSKInference are two subclasses of the abstract class Inference. This latter class is related to the classes Accumulation, Activation, And_ Method, Or_Method through the properties hasAccumulation, hasActivation, hasAnd, hasOr, respectively. Listing 7 provides an idea about the modeling of Mamdani-based inference instance.


This code defines the instance 00 MamdaniInference_8’’ of the class ‘‘MamdaniInference’’. Same parameters such as Activation, Accumulation, AndMethod and OrMethod are set. Then, three rules of inference, instances of the class Rule, identified by ‘‘Rule_35’’ and ‘‘Rule_38’’ have been associated too. 6.3 Defuzzification The defuzzification is the process for converting fuzzy information, i.e., one or more fuzzy sets into a single crisp value. It is a mandatory step because fuzzy sets generated by fuzzy inference in fuzzy rules must be somehow mathematically combined (i.e. defuzzified) to come up with one single number as the output of a fuzzy controller. There are many different available methods of defuzzification, such as COA (center of area), COG (center of gravity), ECOA (extended center of area), etc. The class Defuzzification is related to the class Defuzzifier (i.e., the class associated with the defuzzification method, see Fig. 3), which can have more than one instance. The single defuzzification is related to the number of Defuzzifier instances, that is equal to the number ofInput instances of the Fuzzy Control process. Listing 8 describes an example for the instance of Defuzzification and Defuzzifier.

1159

The code defines an instance of Defuzzification, identified by ‘‘Defuzzification_4’’. The properties ‘‘hasMin’’ and ‘‘hasMax’’ represent a range used for the specification of minimum and maximum values of an output variable of the class ‘‘Defuzzifer‘‘. This definition of range of each output variable allows limiting each membership function and avoids unpredictable output values. It is not applicable if singletons are used for output membership functions. In this example, the method of defuzzification is COG (Center of Gravity), defined as an instance of the class Defuzzifier.

7 Fuzzy concept The core class in the Fuzzy Control process is the FuzzyConcept which represents a fuzzy concept. Figure 4 shows the ontological model of the FuzzyConcept class. Each FuzzyConcept presents more FuzzyTerm connected to it.

Fig. 4 Fuzzy concept class representation

123

1160

The hasFuzzyTerm relation establishes the connection of each fuzzy concept with a specific fuzzy term, described by a membership function. More specifically, the class FuzzyTerm has a data property hasLabel, i.e. the linguistic variable and has a property membershipFunctionOf which assumes values in the class Shape. In this version, OWLFC focuses on the linear shapes. The definition of the class Point allows us to define points for specific shapes. TheShape class is a superclass of classes of N_Point, Singleton, Trapezoidal and Triangular, that represent the well-known membership functions associated with a fuzzy term. Moreover, the definition of each linear shape has a restriction on the cardinality of an instantiation of Point. An example built on instances of classes Inference, FuzzyTerm, Shape and Point is given by OWL code in Listing 9.

C. De Maio et al.

instance of FuzzyConceptOutput, viz.‘‘RiskLand-slideFC’’. For each fuzzy concept, one or more fuzzy terms are defined. Then, each term is composed of a label and a membership function.

8 Fuzzy rules Generally, a fuzzy controller uses fuzzy rules, which are linguistic IF–THEN statements involving fuzzy sets, fuzzy logic and fuzzy inference. Fuzzy rules play a key role in describing expert control/modeling knowledge and in linking the input variables of fuzzy controllers to one or more output variables. The (Mamdani or TSK) fuzzy rules are used in the inference process to compute an action to be taken. Each rule has a weight connected to it. Thus, the ontological model for fuzzy rules is described by the Rule class connected to an Antecedent class and one Consequent class. 8.1 Antecedent and consequent

This code defines two instances of the class FuzzyConceptInput, named ‘‘HumidityFC’’, ‘‘RainfallFC’’ and an

123

The property hasAntecedent enables us to associate antecedent clauses to each rule of Fuzzy Control inference in OWL-FC. Instances of Antecedent, AntecedentClause or Variable work in the range of hasAntecedent. The class Antecedent represents the whole IF part of a Rule. The Antecedent class has associated two operands (by means of two properties called FirstOperand and SecondOperand) connected by operators AND or OR and just negated by a NOT operator. Each one is connected with a Fuzzy Concept Input that has a Fuzzy Term (that can be negated). The definition of Antecedent class is recursive. In particular, hasFirstOperand and hasSecondOperand are properties that admit two kinds of range class: the first one is Antecedent, that implies other two antecedent clauses; the second one is AntecedentClause that is the atomic part of antecedent of the fuzzy rule. The definition of Antecedent enables us to specify more than two clauses in the antecedent. Analogously, the property hasConsequent enables us to associate consequent clauses to each rule of Fuzzy Control inference in OWL-FC. The class Consequent represents the whole output of a Rule. Each Consequent class has multiple ConsequentClause, with a minimum cardinality value equal to one. The class ConsequentClause specifies a single clause of the THEN part of a rule. Each class ConsequentClause is connected to a class FuzzyConceptOutput with a specific Fuzzy Term. An example of a rule, involving instances of classes Inference, FuzzyTerm, Shape is given in Listing 10.


1161

The system modeling foresees a data sensing base that collects data coming from environmental sensors. Specifically, data are gathered on the basis of a domain ontology that models humidity and rainfall detection as described in Listing 11.

The rule of the inference process is identified by ‘‘Rule_35’’. This instance is composed of an antecedent, ‘‘Antecedent_36’’, and a consequent ‘‘Consequent_37’’. In particular, the given OWL code represents the following rule: IF Humidity is high AND Rainfall is high THEN RiskLandslide is high.

The code defines the concept Sensor, which represents the generic sensor; then two specializations of it yield concepts Humidity and Rainfall of the domain ontology: these specific sensors allow detecting humidity and rainfall, respectively. The next step is the detection of landslide’s risk. For this purpose, human domain expertise is required to model risk landslide condition. Traditional approaches exploit semantic technologies (i.e., OWL, SWRL, etc.) and DL reasoning capabilities to design systems that recognize landslide’s risk and provide the right answers by looking up among the available ones in database. In this OWL-FC approach, landslide’s risks conditions are defined by integrating fuzzy logic in the process of reasoning, as better detailed in the next section.

9 A case study 9.1 Approach based on an application ontology A use case is described in order to give a concrete application example of our OWL-FC. Benefits deriving by OWL-FC as well as drawbacks using traditional approaches which are based on application ontology are evidenced too. The application domain is landslide’s risk prevention and detection. The goal is to model a knowledge-based system that exploits ontologies to provide answers and alerts about the presence of landslide’s risks.

Application ontology is an ontology designed for a specific application scope. It usually uses canonical ontologies to define ontological classes and relationships between classes. Specifically, application ontologies are employed for modeling cross-domain experiments, data annotation and for generating data driven views across reference ontologies for specific use. In our example, risk landslide conditions are modeled by means of OWL constructs. Indeed,

123

1162

one of the statement is that there is risk landslide when Humidity and Rainfall data sensing fall into a specific, well-defined ranges. Listing 12 describes this situation.

C. De Maio et al.

to RiskLandslide class is defined in a sharp way: the bounding is well-defined and no belonging gradations can be modeled. Detection of landslide risk is affected by environmental conditions and features such as geographic locations, seasons of the year and so on. The system should support the discovery of the right set of valuable conditions that are necessary to detect possible risks of landslide. In order to obtain qualitative and accurate answers, it is crucial to model the uncertainty according to the meaning of concepts involved in the specific application domain and exploit context parameters to support discovery of those conditions which trigger the detection of landslide risk. 9.2 Approach based on OWL-FC

In this code, the concept of RiskLandslide has been represented as an intersection class computed by between the class representing the concept of HighHumidity and the class representing the concept of HighRainfall. For each concept, the range (defined through the minInclusive and maxInclusive) has been specified too. Then, through SPARQL queries and description logic reasoner, it is possible to reply to request about the presence of landslide’s risk. Let us point out that the belonging

123

OWL-FC provides a general-purpose OWL-based modeling of fuzziness, which is independent of a specific domain: no direct human intervention is required to adapt the concepts of the domain ontology (representing the real implementation system) to the OWL-FC language. The association of the domain and application ontologies with OWL-FC is achieved defining in the Fuzzy Control Profile a direct mapping between concepts of the respective ontologies and input/output concepts of Fuzzy Control. In other words, thanks to OWL-FC Input and Output classes, it is possible to relate specific domain concepts to fuzzy controls. In particular, concepts defined in specific application domain ontologies can be mapped in OWL-FC upper ontology by means of property hasUri, whose domain is represented by Parameter, a super class of Input and Output. An example of landslide risk modeling is shown in Fig. 5. Herein, the level of mapping necessary to use OWL-FC with domain ontology is evidenced: the fuzzy concepts defined in OWL-FC are instanced in correspondence of the concepts defined in the reference domain. Just as an example, in the fuzzy rule of Fig. 5, Humidity represents (the name of) an instance of Input class and it is related to the class of domain ontology Humidity through the URI identified by the property hasUri (for details, consult Listing 3 relative to Input_Humidity, in Sect. 5.1). That means a direct mapping exists between the concept Humidity of the domain ontology and the instance HumidityFC of the FuzzyConceptInput class. Let us note that more than one fuzzy model of the same domain concept is admitted. Another important aspect to outline about OWL-FC modeling is the possibility to add not functional parameters to the profile definition of a Fuzzy Control. In fact, we can consider some not functional parameters such as geographical references for location (i.e. coast), season (i.e. winter), etc. (see Sect. 5). These features facilitate the discovery process in the selection of the right Fuzzy


1163

Fig. 5 An example of OWLFC-based modeling: landslide’s risk prevention and detection. The independence of OWL-FC from a domain ontology is guaranteed through a mapping of concepts in the fuzzy control (specified by the fuzzy rule) to concepts of the ontology

Control for detecting the critical situation. Moreover, in our example, the OWL-FC control will be selected only for requests coming from coastal area, since we have correlated the Fuzzy Control profile with Input_Winter and Input_OnTheCoast context parameters by means of profile property hasProperty (see Listing 2). This emphasizes that OWL-FC upper ontology is able to achieve context aware discovery of fuzzy controls depending on context parameters specified in the profile definition. Therefore, it is possible to enable different fuzzy controls according to the given different context conditions. For instance, the Fuzzy Control defined in this case study is suitable for all regions whose context is defined by high values of humidity and rainfall and the season is the winter; otherwise, in different context conditions (e.g., with values of humidity and rainfall similarly high yet it is summer and we are at sea) probably another ad hoc OWL-FC control could be necessary. Another interesting application domain example for context aware control could be the forecasting of the traffic jam: the modeling is strictly dependent on many context factors such as date-time, day of week, geographical area, weather, etc. According to the most meaning factors in a certain context, it is possible to enable the most appropriate fuzzy controls. In nutshell, OWL-FC allows us to reuse domain ontologies; it provides context aware control and monitoring by easy definition of a semantic context/Fuzzy Control matchmaking algorithm. Moreover, the fuzzy controls guarantee a relaxed membership to an ontology concept compared with crisp boundaries of traditional approaches (see Sect. 9.1): the system can identify situation near to be interesting or ‘‘warning’’ (for example, in the case of emergency risks retrieval).

10 Conclusion OWL-FC defines an upper ontology which allows the modeling of fuzzy control systems in a semantic way and, thanks to the Fuzzy Control profile, it can achieve an automatic context aware discovery of them. In particular, OWL-FC reproduces the model of OWL-S and enables the automatic usage of fuzzy controllers. The combination of OWL and Fuzzy Logic favors in the definition of a highly expressive language, yet, there are still several situations where this merging cannot accurately represent real world knowledge, especially in representing vague and imprecise information. Such kind of information is evident in many applications such as multimedia processing and retrieval, information fusion, etc. Our next objective for future works is to analyze the limitations of languages through the combination of Description Logics and Fuzzy Logic, in order to cope the problems related to semantic modeling and reasoning. Moreover, we are investigating on the possibility of enabling the composition of fuzzy controls, by exploiting the analogy with OWL-S-based representation of web services. Another challenge is related to use OWL-FC to represent fuzzy controls automatically extracted through fuzzy data analysis techniques. In this way we can wrap interaction with a description logic reasoner by introducing OWL-FC-based execution engine.

References Abulaish M, Dey L (2006) Interoperability among distributed overlapping ontologies—a fuzzy ontology framework. In: Proceedings of the 2006 IEEE/WIC/ACM international conference

123

1164 on web intelligence, WI ’06. IEEE Computer Society, Washington, DC, pp 397–403. doi:10.1109/WI.2006.10 Acampora G, Loia V (2011) Fuzzy control interoperability and scalability for adaptive domotic framework. IEEE Trans Ind Inf 1(2):97–111. doi:10.1109/TII.2005.844431 Agarwal S, Hitzler P (2005) Modeling fuzzy rules with description logics. In: Proceedings of workshop on OWL experiences and directions. Galway, Ireland. doi:10.1.1.59.8946 Bobillo F, Delgado M, Go´mez-Romero J, Lo´pez E (2009) A semantic fuzzy expert system for a fuzzy balanced scorecard. Expert Syst Appl 36:423–433. doi:10.1016/j.eswa.2007.09.020. http://portal.acm. org/citation.cfm?id=1453254.1453308 Lee CS, Jian ZW, Huang LK (2005) A fuzzy ontology and its application to news summarization. IEEE Trans Syst Man Cybern Part B Cybern 35(5):859–880 Lee CS, Wang MH, Acampora G, Hsu CY, Hagras H (2010) Diet assessment based on type-2 fuzzy ontology and fuzzy markup language. Int J Intell Syst 25(12):1187–1216. doi:10.1002/int. 20449 Martin D, Burstein M, Hobbs E, Lassila O, Mcdermott D, Mcilraith S, Narayanan S, Parsia B, Payne T, Sirin E, Srinivasan N, Sycara K (2004) OWL-S: Semantic Markup for Web Services. Technical report. http://www.w3.org/Submission/OWL-S/ Pan JZ, Stoilos G, Stamou G, Tzouvaras V, Horrocks I (2006) f-swrl: a fuzzy extension of swrl. J Data Semant Spec Issue Emergent Semant 3697:829–834 Parry D (2004) A fuzzy ontology for medical document retrieval. In: Proceedings of the second workshop on Australasian information

123

C. De Maio et al. security, data mining and web intelligence, and software internationalisation, vol 32, ACSW Frontiers ’04. Australian Computer Society, Darlinghurst, pp 121–126. http://portal.acm. org/citation.cfm?id=976440.976458 Ren Y, Cheng X (2008) Semantic-based image retrieval using fuzzy domain ontology. In: Intelligent information technology application, 2008. Second international symposium on IITA ’08, vol 2, pp 141–145. doi:10.1109/IITA.2008.327 Sanchez E (2006) Fuzzy logic and the semantic web (capturing intelligence). Elsevier, New York Stoilos G, Simou N, Stamou G, Kollias S (2006) Uncertainty and the semantic web. IEEE Intell Syst 21(5):84–87. doi:10.1109/MIS. 2006.105 Straccia U (2001) Reasoning within fuzzy description logics. J Artif Intell Res 14 Straccia U (2005) A fuzzy description logic for the semantic web, Chap 4. In: Fuzzy logic and the semantic web, capturing intelligence. Elsevier, New York, pp 167–181 Tho Q, Hui S, Fong A, Cao TH (2006) Automatic fuzzy ontology generation for semantic web. IEEE Trans Knowl Data Eng 18(6):842–856. doi:10.1109/TKDE.2006.87 Wlodarczyk T, O’Connor M, Rong C, Musen M (2011) Swrl-f—a fuzzy logic extension of the semantic web rule language 654:97–100 Zhai J, Luan W, Liang Y, Jiang J (2008) Using ontology to represent fuzzy knowledge for fuzzy systems. In: Proceedings of the 2008 fifth international conference on fuzzy systems and knowledge discovery, vol 03, FSKD ’08, pp 673–677