Ontology-Extended Component-Based Workflows : A Framework for Constructing Complex Workflows from Semantically Heterogeneous Software Components


of 16
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Virtually all areas of human endeavor involve workflows – that is, coordinated execution of multiple tasks. In practice, this requires the assembly of complex workflows from semantically heterogeneous components. In this paper, we develop
  Ontology-Extended Component-BasedWorkflows: A Framework for ConstructingComplex Workflows from SemanticallyHeterogeneous Software Components Jyotishman Pathak, Doina Caragea, and Vasant G. Honavar Artificial Intelligence Research Laboratory,Department of Computer Science,Iowa State University,Ames, IA 50011-1040, USA { jpathak, dcaragea, honavar } @cs.iastate.edu Abstract.  Virtually all areas of human endeavor involve workflows -that is, coordinated execution of multiple tasks. In practice, this requiresthe assembly of complex workflows from semantically heterogeneouscomponents. In this paper, we develop ontology-extended workflowcomponents and semantically consistent methods for assembling suchcomponents into complex ontology-extended component-based work-flows. The result is a sound theoretical framework for assembly of semantically well-formed workflows from semantically heterogeneouscomponents. Keywords:  Workflows, Ontologies, Components. 1 Introduction Almost all areas of human activity - education, business, health care, science,engineering, entertainment, defense - involve use of computers to store, access,process, and use information. The term  workflow   typically refers to coordinatedexecution of multiple tasks or activities [16,1,12]. Processing of an invoice, the protocol for data acquisition and analysis in experimental science, responding toa natural disaster, could all be viewed as workflows.Examination of workflows in specific domains reveals that many activities(e.g., the task of credit evaluation in financial services workflows) are commonto several workflows. Encapsulation of such activities in the form of reusablemodules or workflow  components  , which can be assembled to create complexworkflows, can greatly reduce the cost of developing, validating, and maintainingsuch workflows [21]. Hence, component-based approaches to designing workflowshas begun to receive considerable attention in the literature [6,8,15,21]. A component [10,19] is a piece of software that can be independently de- veloped and delivered as a unit. Well-defined interfaces allow a component tobe connected with other components to form a larger system. Component-based C. Bussler et al. (Eds.): SWDB 2004, LNCS 3372, pp. 41–56, 2005.c  Springer-Verlag Berlin Heidelberg 2005  42 J. Pathak, D. Caragea, and V.G. Honavar software development [9] provides a flexible and cost-effective framework forreuse of software components. Compositionality ensures that global properties of the resulting system can be verified by verifying the properties of the constituentcomponents. By analogy with software components, a workflow component canbe viewed as a workflow module (i.e., an executable piece of software) which canbe connected to other workflow modules through well-defined interfaces.A simple workflow consisting of two simple components: F-Sensor andWeather Description is shown in Figure 1. The function of this workflow is to F-Sensor WeatherDescription Input Signals / BitStreamsTemperature(in F)Temperature(in F)HotWarmColdIf (temperature > 80) then Hotif (50 < temperature < 80) then Warmif (temperature < 50) then cold Fig.1.  Weather Description with F-Sensor determine whether the day is hot, or warm or cold based upon the tempera-ture. The input to the F-Sensor component consists of signals from one or moresensors and its output is the current temperature (in degree F) and the inputto the Weather Description component is the current temperature (in degree Ffrom the output of F-Sensor component) and its output is a description of theday (hot or warm or cold). Note that in this example, the output produced bythe F-Sensor component has the same semantics as the input of the WeatherDescription component; furthermore, the name  Temperature   used in the vocab-ulary associated with the F-Sensor component has the same  meaning   as the term Temperature   in the vocabulary associated with the Weather Description compo-nent. In the absence of syntactic or semantic mismatches between components,their composition is straightforward.However, it is unrealistic to expect such syntactic and semantic consistencyacross independently developed workflow components libraries. Each such work-flow component library is typically based on an implicit  ontology  . The workflowcomponent ontology reflects assumptions concerning the objects that exist inthe world, the properties or attributes of the objects, the possible values of at-tributes, and their intended meaning from the point of view of the creators of the components in question. Because workflow components that are created foruse in one context often find use in other contexts or applications, syntactic andsemantic differences between independently developed workflow components areunavoidable. For example, consider a scenario where we replace the F-Sensorcomponent with a new component: C-Sensor. Suppose C-Sensor behaves verymuch like F-Sensor except that it outputs the temperature, denoted by  Temp ,and measured in degrees Centigrade instead of degrees Fahrenheit. Now we canno longer compose C-Sensor and Weather-Description components into a sim-ple workflow, because of the syntactic and semantic differences between the two  Ontology-Extended Component-Based Workflows 43 components. Effective use of independently developed components in a given con-text requires reconciliation of such syntactic and semantic differences betweenthe components. Because of the need to define workflows in different applicationcontexts in terms of vocabulary familiar to users of the workflow, there is nosingle privileged ontology that will serve all users, or for that matter, even asingle user, in all context.Recent advances in networks, information and computation grids, and WWWhave made it possible, in principle, to assemble complex workflows using a diver-sity of autonomous, semantically heterogeneous, networked information sourcesand software components or services. Existing workflow management systems(WfMS) allow users to specify, create, and manage the execution of complexworkflows. The use of standard languages for defining workflows [1] provides forsome level of portability of workflows across different WfMS. A major hurdlein the reuse of independently developed workflow components in new applica-tions arise from the  semantic   differences between the independently developedworkflow components. Hence, realizing the vision of the Semantic Web [2], i.e.,supporting seamless access and use of information sources and services on theweb, in practice calls for principled approaches to the problem of assembly of complex workflows from semantically heterogeneous components - the  workflow integration   problem.The workflow integration problem can be viewed as a generalization of the Information Integration   problem [14]. Hence, we build on recent developmentsin component-based workflow design [6,8,15,21] to extend ontology-based solu- tions of the information integration problem [7,18] to develop principled solu- tions to the workflow integration problem. Specifically, in this paper, we develop ontology-extended workflow components   and  mappings   between ontologies to fa-cilitate assembly of   ontology-extended component-based workflows   using seman-tically heterogeneous workflow components. The proposed ontology-extendedcomponent-based workflows provide a sound theoretical framework for assemblyof semantically well-formed workflows from semantically heterogeneous informa-tion sources and software components. 2 Ontology Extended Component Based Workflows 2.1 Ontologies and Mappings An  ontology   is a specification of   objects  ,  categories  ,  properties   and  relationships  used to conceptualize some domain of interest. In what follows, we introduce aprecise definition of ontologies. Definition   (Hierarchy) [4]: Let  S   be a partially ordered set under ordering ≤ . We say that an ordering    defines a  hierarchy   for  S   if the following threeconditions are satisfied:(1)  x     y   →  x   ≤  y  ;  ∀  x, y   ∈  S  . We say ( S  ,   ) is  better than   ( S  ,  ≤ )),(2) ( S  ,  ≤ ) is the reflexive, transitive closure of ( S  ,   ),(3) No other ordering    satisfies (1) and (2).  44 J. Pathak, D. Caragea, and V.G. Honavar Example:  Let  S   =  { Weather, Wind, WindSpeed  } . We can define the partialordering  ≤  on  S   according to the  part of   relationship. For example,  Wind   is partof the  Weather   characteristics,  WindSpeed   is part of the  Weather   characteristics,and  WindSpeed   is also part of   Wind   characteristics. Besides, everything is partof itself. Thus, ( S  ,  ≤ ) =  { ( Weather, Weather  ), ( Wind, Wind  ), ( WindSpeed,WindSpeed  ), ( Wind, Weather  ), ( WindSpeed, Weather  ), ( WindSpeed, Wind  ) } .The reflexive, transitive closure of   ≤  is the set: ( S  ,   ) =  { ( Wind, Weather  ),( WindSpeed, Wind  ) } , which is the only hierarchy associated with ( S  ,  ≤ ). Definition   (Ontologies) [4]: Let  ∆  be a finite set of strings that can be usedto define hierarchies for a set of terms  S  . For example,  ∆  may contain stringslike  isa, part-of   corresponding to  isa   or  part-of   relationships, respectively. An Ontology O   over the terms in  S   with respect to the partial orderings contained in ∆  is a mapping  Θ  from  ∆  to hierarchies in  S   defined according to the orderingsin  ∆ . In other words, an ontology associates orderings to their correspondinghierarchies. Thus, if   part-of   ∈  ∆ , then  Θ ( part-of   ) will be the  part-of   hierarchyassociated with the set of terms in  S  . Example:  Suppose a company  K  1  records information about weather in someregion of interest (see Figure 2). From  K  1 ’s viewpoint, weather is described bythe attributes  Temperature, Wind, Humidity   and  Outlook   which are related toweather by  part-of   relationship. For example,  Wind   is described by  WindSpeed  .The values  Cloudy, Sunny, Rainy   are related to  Outlook   by the  i  s-a relation-ship. In the case of a measurement (e.g.,  Temperature, WindSpeed  ) a unit of measurement is also specified by the ontology. In  K  1 ’s ontology,  O 1 ,  Tempera-ture   is measured in degrees Fahrenheit and the  WindSpeed   is measured in milesper hour. For contrast, an alternative ontology of weather  O 2  from the viewpointof a company  K  2  is shown in Figure 3. WeatherTemperature Wind Humidity Outlook WindSpeed Cloudy Sunny Rainy Ontology O  1 Fig.2.  Weather Ontology of Company K  1 Suppose  O 1 ,..., O n  are ontologies associated with components  C  1 ,..., C  n , re-spectively. In order to compose workflow using those semantically heterogeneouscomponents, the user needs to specify the mappings between these ontologies of the various components. For example, a company  K  3 , with ontology  O 3  uses me-teorology workflow components supplied by  K  1  and  K  2 . Suppose in  O 3 ,  Weather   Ontology-Extended Component-Based Workflows 45 WeatherTemp Wind Humidity PrecWindSpeedHeavyRain LightRain Ontology O  2  WindDir RainNoPrec SnowLightSnowHeavySnow Fig.3.  Weather Ontology of Company K  2 is described by  Temperature   (measured in degrees Fahrenheit),  WindSpeed   (mea-sured in mph),  Humidity   and  Outlook  . Then,  K  3  will have to specify a suitablemapping  M  O 1  → O 3  from  K  1  to  K  3  and a mapping  M  O 2  → O 3  from  K  2  to  K  3 . Forexample,  Temperature   in  O 1  and  Temp  in  O 2  may be mapped by  M  O 1  → O 3  and M  O 2  → O 3  respectively to  Temperature   in  O 3 . In addition, conversion functions toperform unit conversions (e.g.  Temp  values in  O 2  from degrees Centigrade to de-grees Fahrenheit) can also be specified. Suppose  K  3  considers  Precipitation   in  O 2 is equivalent to  Outlook   in  O 3  and maps  Rain   in  O 2  to  Rainy   in  O 3 . This wouldimplicitly map both  LightRain   and  HeavyRain   in  O 2  to  Rainy   in  O 3 . Thesemappings between ontologies are specified through  interoperation constraints  . Definition   (Interoperation Constraints) [7,4]: Let ( H  1 ,   1 ) and ( H  2 ,   2 ), beany two hierarchies. We call the set of   Interoperation Constraints (IC)  the set of relationships that exists between elements from two different hierarchies. For twoelements,  x   ∈  H  1  and  y   ∈  H  2 , we can have  one   of the following InteroperationConstraints: –  x :  H  1  = y :  H  2 –  x :  H  1   =  y :  H  2 –  x :  H  1  ≤  y :  H  2 –  x :  H  1  ≤  y :  H  2 Example:  For the weather domain, if we consider  part-of   hierarchies associatedwith the companies  K  1  and  K  2 , we have the following interoperation constraints,among others-  Temperature   : 1 =  Temp  : 2,  Outlook   : 1 =  Prec   : 2,  Humidity   :1   =  Wind   : 2,  WindDir   : 2  ≤  Wind   : 1, and so on. Definition   (Type, Domain, Values) [7,4]: We define  T   =  { τ   |  τ   is a string }  tobe a set of   types  . For each type  τ  ,  D ( τ  ) =  { v | v  is a value of type  τ  }  is called the domain   of   τ  . The members of   D(  τ  )  are called  values   of type  τ  . Example:  A type  τ   could be a predefined type, e.g.  int   or  string   or it can be atype like  USD   (US Dollars) or  kmph   (kilometers per hour). Definition   (Type Conversion Function) [7, 4]: We say that a total function f  ( τ  1 ,τ  2 ):  D ( τ  1 )  →  D ( τ  2 ) that maps the values of   τ  1  to values of   τ  2  is a  type 
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks