2 The inference-based semantic business process composition agent

The proposed SCA System has five main parts, which are as follows: translator, planner, inference engine, execution engine, and monitoring agent. The system has three ontology knowledge bases (Tasks-TKBO, Concepts (or Domain-CKBO) and Processes-PKBO), and one Rule Knowledge Base (RKB) that contains the Revised Armstrong's Axioms.

SCA composes OWL-S-based atomic processes using a novel planning method through the RAAs. The Armstrong's Axioms (AAs; or more precisely, Armstrong's inference rules) are a set of axioms that are used to infer functional dependencies on a relational database. They were developed by William W. Armstrong in his paper titled Dependency Structures of Data Base Relationships (Armstrong, Reference Armstrong1974). We revised AAs in order to shorten inference chains while preserving the integrity to derive functional dependencies of the processes, and used in this work during the inferencing and planning phase. The novelty of the SCA System is that for the first time such a study revises the AAs and employs them in semantic-based planning and inferencing of Web services. This article proposes embedding the AAs in ontologies for finding appropriate composition plans of OWL-S-based atomic processes. The architecture of the SCA System is depicted in Figure 1; main parts of SCA are introduced below:

Figure 1

Architecture of the SCA System. SCA=semantic business process composition agent.

• • The Translator performs a parsing task of knowledge bases namely, translating all atomic tasks in Task Knowledge Base Ontology (TKBO), all atomic processes of SWSs (candidates) in Process Knowledge Base Ontologies (PKBO) and goal process of client into I/O/P/E form. The translator utilizes the Tasks, Concepts and Processes ontology KBs, and details translation from OWL-S process model to I/O/P/E form. According to I/O/P/E modeling, a given set of task instances in the TKBO and atomic processes in the PKBO (e.g. P_i) are converted into the form P_i ≡ I_i → O_i, where its inputs are I_i ≡ I_{i 1}∧I_{i 2}∧…∧I_ik and its outputs are O_i ≡ O_{i 1}∧O_{i 2}∧…∧O_im. The logical expression of P_i ≡ I_i → O_i determines that O_i is obtainable only if I_i is available. The linear implication operator (‘→’) asserts that, I_i is consumed and O_i is produced. Domain-related atomic tasks in TKBO, candidate SWSs, and goal process in I/O/P/E form are passed on to the planner.

• • The Planner is in the heart of the SCA System. It tries to find an execution sequence of processes using the predefined tasks (TKBO) and candidate SWSs (PKBO) while satisfying the requested complex goal process. In matching parameters, when the planner needs to find out similar concepts, it calls on the inference engine. The Inference Engine (IE) performs inferencing on the processes of candidate SWSs using the RAAs. A suitable RAA rule from the RKB is picked and then applied to a pair of task instances (or processes). If a new complex process is produced, it is then sent to the planner for checking its suitability. The inference engine and the planner are thus coordinated to work in alternating sequence in each iteration. In summary, there is a complex goal process G ≡ I_G → O_G, with I_G ≡ I_{G 1}∧I_{G 2}∧…∧I_Gj inputs and O_G ≡ O_{G 1}∧O_{G 2}∧…∧O_Gh outputs. Given a path, P, is planned by SCA, the question is whether P is canonically implied by G $$\[--><$>(P\, \models \,G) <$><!--$$ or not. To resolve this question, we used a process derivation task that employs the RAAs inference rules. Inferencing using the RAAs is taken up in Section 6.

• • The Execution Engine (EE) executes the planned sequence of OWL-S-based atomic processes. The sequence defined by the Planner and IE must meet the client's goal. In this paper, it is assumed that all OWL-S-based atomic processes in the planned sequence are implemented as individual SWSs and the executions of these atomic processes are triggered by the invocations of the SWSs through Grounding of OWL-S.

• • Finally, the Monitoring Agent (MA) monitors proper execution of the atomic processes of the composite process during the execution stage. In the last two steps, the system initiates the execution of all the components/processes in the defined plan path. After the execution, the SCA serves the result to the client.

3 Knowledge base ontologies of the SCA system

Semantic Web is an extension of the current Web where information has a well-defined meaning. This better enables cooperation between computers and people (Lee et al., Reference Berners-Lee, Hendler and Lassila2001). Ontology, that is, the conceptual language of the Semantic Web, is a specification of a conceptualization of a knowledge domain. It is a controlled vocabulary that formally describes objects and their relationships. As mentioned above, the SCA uses three ontology knowledge bases, namely, Tasks, Concepts (or Domain), and Processes knowledge bases. Effective detailing of the knowledge bases will help understanding mechanics of the SCA System. They are introduced below.

3.1 Task Knowledge Base Ontology

TKBO is a common ontology that contains capability corresponding to functionality provided by Web services. TKBO provides an extensive ontology of functions or tasks. Using TKBO, Web services may be defined as instances of classes that represent their capability based on OWL-S descriptions on their service site. Furthermore, SCA System may use the TKBO during its stages for discovery, composition, and invocation of services. This is necessary in order to distinguish processes according to their functional semantics since the services may have the same inputs and outputs but have different functional semantics. The following ontology snippet presents an excerpt from the TKBO model. TKBO is used by a semantic-based SCA System for matching service capability during the inferencing and planning stage. In the TKBO, semantic task contexts of task instances are embedded by using the OWL semantic tags such as <owl:class>, <rdfs:subClassOf>, <owl:ObjectProperty>, and <owl:DatatypeProperty>. For example, the semantic task contexts in Table 1 are used to explain that the Tasks, e_Commerce_Service, Information_Service, Buying_Service, Selling_Service, and Book_Buying are as <owl:class> classes, which keeps semantic-based descriptions for instances of tasks in e-commerce area. The line 5 declares that there is a class named Tasks using the tag <owl:class>, and the line 6 describes that there is another class named e_Commerce_Service, which is a kind of Tasks using the tag <rdfs:subClassOf> at line 7. Other classes of the other tasks instances are described similarly. The lines 1–4 present defined <owl:DatatypeProperty> properties Input_Parameter, Output_Parameter, Precondition_Parameter, and Effect_Parameter. The lines 18–23 present a Book_Buying task having an Input_Parameter (at line 20) that specifies the association between the Book_Buying task and the Input_Parameter by <owl:DatatypeProperty>. The meaning of the association is that the Book_Buying task contains only one input, which is ISBN. All other output, precondition and effect parameters of the Book_Buying task are described in the same format (lines 21–22; and there is no effect parameter). In this manner, various meanings related to the task can be described in the semantic task contexts. Details of inferencing and planning using <owl:ObjectProperty> are presented in Section 7.

Table 1

Beginning part of the TKBO

TKBO=Task Knowledge Base Ontology.

4 Semantics in the OWL-S process model

In this section, we introduce semantic descriptions of Web services through OWL-S. An OWL-S Profile characterizes two aspects of service functionality: information transformation, which is represented by Inputs and Outputs, and state change, which is produced by an execution of a service.

1 <service:Service rdf:ID=“BookPrice”>

2 </service:Service>

3 <process:AtomicProcess rdf:ID=“BookPrice-Process”>

4 <process:hasInput rdf:resource=“#BookName”/>

5 <process:hasOutput rdf:resource=“#PriceOfBook”/>

6 <process:hasPrecondition>

7 <expr:SWRL-Condition rdf:ID=“BookInStock”>

8 <expr:expressionLanguagerdf:resource=“http://www.daml.org/…/Expression.owl#SWRL”/>

9 <expr:expressionBody rdf:parseType=“Literal”>

10 </expr:SWRL-Condition>

11 </process:hasPrecondition>

12 </process:AtomicProcess>

For example, to complete a sale, a book-selling service may require the name of a book as input, and the fact that the book is in stock (the precondition). The result of the sale encompasses production of a receipt that confirms the proper execution of the transaction, transfer of ownership, shipment of the book, and reduction of stock (as effect). The above given OWL-S fragment exemplifies a BookPrice SWSFootnote ² that contains an atomic BookPrice-Process. The process has one input “BookName”, output “PriceOfBook”, and one precondition “BookInStock” (at lines 4, 5 and 7).

Let us take up a BookSearch SWS with a single atomic process called BookSearch-Process. The atomic service has only one input “BookTitle” and one output “Book” of parameter type Concepts.owl# Title and Concepts.owl# Book, respectively. Here we give snippets of code for OWL-S of sample BookSearch SWSFootnote ³.

1 <service:Service rdf:ID=“BookSearch”>

2 <process:AtomicProcess rdf:ID=“BookSearch-Process”>

3 <process:hasInput rdf:resource=“#BookTitle”/>

4 <process:hasOutput rdf:resource=“#Book”/>

5 </process:AtomicProcess>

6 <process:Input rdf:ID=“BookTitle”>

7 <process:parameterType rdf:datatype=“http://.ontology/Concepts.owl#Title”/>

8 <rdfs:label>Book Title</rdfs:label>

9 </process:Input>

10 </service:Service>

Each process:parameterType has a type specified using an URI. The type can be defined by the service provider as either a class/concept or a specific xmlDatatype, and the parameter must be associated with a concept in the domain ontology of the service. Let's consider the OWL-S declarations of inputs ‘BookTitle’ of BookSearch-Process and ‘BookName’ of BookPrice-Process as given below.

1 <service:Service rdf:ID=“BookPrice”>

2 <process:AtomicProcess rdf:ID=“BookPrice-Process”>

3 <process:Input rdf: ID=“BookName”>

4 <process:parameterType rdf:resource=“http://www.w3.org/2001/XMLSchema#string”/>

5 </process:Input>

6 </service:Service>

Clearly these inputs have the same meaning, but they are declared differently by their providers. Furthermore, the process:parameterType property of the first is defined as Concepts.owl# Title and of the second as XMLSchema# string. A service with the process:parameterType defined as string may be composed with any other service as any service can return a string as an output. This situation would make proper composition more difficult due to the availability of unrelated services because of inadequate semantic description. Unfortunately, the use of standard XMLSchema data types such as string, integer, double, etc. in the properties of process:parameterType can lead to missed semantic matching of processes in the search of suitable processes of candidate SWSs during the constitution of the required composition plan. During planning phase, a semantic search agent will not be able to notice the equivalency of those processes from either process:parameterType property or rdf:ID(input-output) concepts. To solve this problem, we used the Concepts.owl (CKBO). Each parameter type of task instances (in TKBO) or processes (in the PKBO) indicates a class in the Concepts.owl instead of using XMLSchema data types.

5 Sample SWSs corpus used

The data set of the OWL-S-based atomic processes (in PKBO) and an ontology of concepts (CKBO) used in this paper can be found on SemWebCentral Website. The most commonly used test collection SWS-TC includes 241 OWL-S-based SWSs. This test collection is selected since the average quality of the descriptions is somewhat better than other test collections. The OWL-S descriptions of 241 different SWSs in the SWS-TC are analyzed in the Translator stage of the SCA, and some ontological data were extracted such as the Effects (I/O/P/E), parameter name and parameter type (as an ontological reference).

Table 2 depicts seven atomic processes of OWL-S-based SWSs from the SWS-TC 1.1 with the information needed for the scope of this section. All of them have input and output concepts described in the form “rdf:ID<#process:parameterType>’’ and only one service contains a Precondition; no service has Effect. A possible scenario is that a user wants to find the price of a book by giving its title, and expects the price information in a specific currency such as the United States Dollars (USD). Assume that the goal task (G) is required by the client (G ≡ (BookTitle[Text]∥InputCurrency[Currency]∥DestinationCurrency[Currency])→BookPrice[Price]) where the ‘InputCurrency’ is specified as Euro and ‘DestinationCurrency’ is specified as USD by the user. We will continue with this scenario in the next section to show how RAAs are applied on OWL-S atomic processes.

Table 2

Seven atomic processes from the SWS-TC 1.1 with I/O/P/E parameters

6 Revised Armstrong's Axioms

Armstrong's Inference Rules (also referred to as Armstrong's Axioms) are a set of axioms used to infer functional dependencies (FDs) on a relational database. They were developed by William W. Armstrong in his paper titled Dependency Structures of Data Base Relationships (Armstrong, Reference Armstrong1974). An inference axiom is a rule, which states that if a relation satisfies certain FDs, it must also satisfy certain other FDs. There are seven axioms that are Reflexivity, Augmentation, Transitivity, Pseudo Transitivity, Additivity, Accumulation, and Projectivity as shown in Table 3. Five of them, namely, Transitivity, Pseudo Transitivity, Additivity, Projectivity, and Accumulation are applied exactly in the same fashion during the constitution of a composition plan by the Planner and IE of SCA. We tested and found them suitable for deriving the required process sequences for a composition. On the other hand, since the Reflexivity and Augmentation axioms applied in sequence performs like factorization; we combined them together in order to form a shorthand Pseudo Factorization axiom. By using these two rules separately by Planner of SCA System, the system is likely to generate many unsuitable derivative composition plans; perhaps even end up doing infinite iterations. The combined version for these two rules will not only eliminate unsuitable derivations, it will also reduce the complexity of composition. In addition, we renamed the Projectivity axiom as Dissection for the latter better expresses the intended operation.

Table 3

Armstrong's Axioms and Revised Armstrong's Axioms

Table 3 displays AAs in the first column, corresponding RAAs in the second column. Let us assume that X, Y, Z, W, and T are classes/concepts of Input/Output parameters of an available process set and that the right arrow is the linear implication operator. Using example X∥Y→Z in the Table 3, we can understand that the concepts X and Y are taken as concurrent inputs (i.e. X∥Y) while execution of the process, thus their order is not important. The outcome is the concept Z after execution.

An important point of the revision is that, while combining Reflexivity and Augmentation axioms, we did not alter correctness and completeness of AAs. Therefore, the RAAs are equivalent transformations of AAs. A composition plan is associated with a control flow and a data flow of processes in the plan. A control flow addresses the task dependencies among a set of atomic processes. Here, the order of atomic processes is a crucial point. A pair of processes is called combinative if the output of one is equal to the input requirements of the other (transitive), or, if the input of one is equal to the input requirements of the other (additive). RAAs are applicable in structuring a control flow (as a workflow of atomic processes) among candidate processes. If we apply Transitivity then Pseudo Transitivity rules to the BookSearch.owl, BookPrice.owl and CurrencyConvertor.owl in Table 2, the possible chain is Pseudo[Transitivity[BookSearch○BookPrice]○CurrencyConvertor]]. Additionally, the expected new process (named as P) after tracing of Planner and IE actions is P ≡ [Title[Concepts.owl#Text]∥DestinationCurrency[Concepts.owl#Currency]→OutputAmount[Concepts.owl#Price]] that results the P is canonically implied by G $$\[--&#x003E;&#x003C;$&#x003E;({\rm{P}}\, \models \,{\rm{G}}) &#x003C;$&#x003E;&#x003C;!--$$ . Inferencing is taken up next.

7 Inferencing in the SCA System

Semantic task contexts are supported by the OWL formal semantics. Therefore, reasoning can be performed based on the semantically described task contexts. In order to do this, we employ the Task ontology (Tasks.owl-TKBO) for inference purpose. In this section, we present the details of inference through TKBO of the SCA System. OWL formal semantics can be used to define RAAs as object property characteristics to be used during the inference and planning stage. Thus hasTransitivity, hasPseudoFactorization, hasPseudoTransitivity, hasAdditivity, hasAccumulation and hasDissection are defined as <owl:ObjectProperty>. The RAAs rules are inserted into the Tasks ontology (TKBO) in order to describe task dependencies as displayed in the lines 1, 6, 11, 16, 21, and 26 in Table 4.

Table 4

Revised Armstrong's Axioms in the Tasks.owl (TKBO)

OWL formal semantics provide many property characteristics such as transitive, symmetric, functional, inverseOf, inverseFunctional, etc. For instance, if a property P is specified as transitive then for any X, Y, and Z: P(X,Y) and P(Y,Z) implies P(X,Z). Kang et al. (Reference Kang, Lee, Kim and Lee2009) used the property characteristics during the reasoning of business process knowledge to provide an order among some semantic business processes for monitoring purpose. However, the SCA uses theRAAs to describe task dependencies semantically as a kind of OWL object property. In Table 4, the defined transitive-based properties (as shown in lines 2, 7, 12, and 22) are suitable to reason about the execution order of several tasks while planning. Additionally, union-based properties (as shown in the line 17) could be also suitable for additive-based operations among a set of tasks.

To understand better the depth of inferencing in the SCA System, one will have to consider another similar example of Online Book Store domain. Four different task instances from TKBO: BookISBN-Task, BookPrice-Task, Currency_Converter-Task, and BookSearch-Task are given in Table 5. The object property hasTransitivity is specified as transitive (lines 1 and 2 in Table 4). In addition, if the BookISBN-Task is transitive with BookPrice-Task then BookISBN-Task has to be performed before the BookPrice-Task. The tasks dependency knowledge is semantically described for these two task instances (BookISBN-Task & BookPrice-Task) through <hasTransitivity> rule of RAAs in the semantic contexts of the task instance (BookISBN-Task) in Table 5 (line 5). The other task dependencies are described in the same fashion through RAAs in Table 5. In this manner, various meanings related to the task can be described in the semantic contexts of task instances and their dependency knowledge that give us an opportunity to derive a new process named NewBook-Process from these two processes. Based on this transitive characteristic of the hasTransitivity, the resultant new task (NewBook-Process) is performable before any suitable task to continue the possible chain. Some of possible reasoning operations are formalized as below:

Table 5

Four tasks of the Online Book Store Domain in the Tasks.owl (TKBO)

TKBO=Task Knowledge Base Ontology.

$$\matrix{ {\rm{TRANSITIVITY1[BookISBN {\hbox -} Task(Title}} \rightarrow {\rm{ISBN),}} \cr {\rm{BookPrice {\hbox -} Task(ISBN}}\rightarrow{\rm{Store}}&#x007C;&#x007C;{\rm{Price}}&#x007C;&#x007C;{\rm{Currency)]}}\,\, \cr {\rm{implies}}\,\,{\rm{[NewBook {\hbox -} Process (Title}}\rightarrow {\rm{Store}}&#x007C;&#x007C;{\rm{Price}}&#x007C;&#x007C;{\rm{Currency)]}} $$

$$\matrix{ {\rm{PSEUDOTRANSITIVITY1[NewBook {\hbox -} Process}} \cr {\rm{(Title}} \rightarrow {\rm{Store}}&#x007C;&#x007C;{\rm{Price}}&#x007C;&#x007C;{\rm{Currency),}}\,\,{\rm{Currency\_Converter {\hbox -} Task}} \cr {\rm{(Currency}}&#x007C;&#x007C;{\rm{Price}}&#x007C;&#x007C;{\rm{Currency}} \rightarrow {\rm{Price)]}}\,\,{\rm{implies}}\,\, \cr {\rm{[AnotherBook {\hbox -} Process (Title}}&#x007C;&#x007C;{\rm{Currency}} \rightarrow {\rm{Store}}&#x007C;&#x007C;{\rm{Price)]}}$$

$$\matrix{ {\rm{PRODUCED}}\; \; {\rm{NEW}}\; \; {\rm{PROCESS}}\; \; {\rm{(RESULTNODE)\!\!:}} \cr \; \; {\rm{AnotherBook {\hbox -} Process}}\,\,{\rm{(Title}}&#x007C;&#x007C;{\rm{Currency}} \rightarrow {\rm{Store}}&#x007C;&#x007C;{\rm{Price)}} $$

The profile model of the resultant composition process (Formula 3) is given in Table 6. In Table 6, two inputs (lines 2–7 and 8–13) and two outputs (lines 14–19 and 20–25) are defined with their parameter types by URLs pointing to the related concepts in the Concepts.owl (CKBO).

Table 6

Profile model of the returned composite process (AnotherBook-Process)

In Table 7, a part of process model of the resultant composite process by SCA is given. The model contains semantic contexts of the knot points in the returned chain, which are TRANSITIVITY1 (Formula 1), PSEUDOTRANSITIVITY1 (Formula 2), and RESULTNODE (Formula 3). The order is described as TRANSITIVITY1, PSEUDOTRANSITIVITY1, and RESULTNODE, which is given in lines 1–21 through <process:ControlConstructList>, <list:first>, <list:rest>, and so on. Three different tasks are used for the resultant composition plan: BookISBN-Task, BookPrice-Task, and Currency_Converter-Task. The common parameter of the BookISBN-Task and BookPrice-Task is ‘ISBN’. ISBN is produced by BookISBN-Task and consumed by BookPrice-Task that is shown between lines 31 and 46 in Table 7. Common parameters of BookPrice-Task and Currency_Converter-Task are ‘Input _Currency’ and ‘Input_Price’. These produced by BookPrice-Task and consumed by Currency_Converter-Task, which are shown in lines 47–67 in Table 7. Finally, during the Execution and Monitoring stage, the SCA System uses grounding information (keeps the URLs of services) of those atomic processes to execute the composite process. The semantic context of the grounding information is given in lines 68–73 in Table 7. Thus, various new processes can be inferred based on the semantic contexts of task instances and their dependency knowledge in the Tasks ontology (TKBO). The system produces an OWL-S-based ontology file of requested composite process. Matching of the tasks in the resultant plan and also tasks of the client goal will be checked by the Process Equivalency Task, which is discussed next.

Table 7

Process model of the returned composite process (AnotherBook-Process)

8 Process Equivalency Task

The planner performs the Process Equivalency Task between the client goal process (G) and the newly derived composite process (P) in order to identify if the two processes have the same purpose or not. This is performed according to the algorithm depicted in Table 8. Let us assume that the input and output parameters of processes G and P are indicated as G ≡ {G_i , G_o} and P ≡ {P_i , P_o}, let us say that

Table 8

Process Equivalency Task

G_i ≡ {BookTitle[Text], InputCurrency[Currency], OutputCurrency[Currency]} and

G_o ≡ {BookPrice[Price]}.

P_i ≡{Title[Text], SourceCurrency[Currency], DestinationCurrency[Currency]} and

P_o ≡ {OutputAmount[Price]}. Then clearly, G_i ≡ P_i and G_o ≡ P_o, consequently, P is equivalent to G according to their parameter types that is given in brackets ‘[ ]’. In another case, if G_i ≡ P_i, however, G_o ≡ {BookPrice[Price]} and Po ≡ {OutputAmount[Price], DestinationCurrency[Currency]}, that is, G_o ⊂ P_o, then it can be stated that P subsumes process G. Producing extra outputs is acceptable, therefore it can be concluded that P is equivalent to G. In the latter case, the SCA System checks whether any unnecessary I/O is generated, and if so, stipulates where it can be ignored in the above example.

9 Related works

In recent studies, the composition problem is solved by using a planner. A planner uses a list of participating candidate Web services (contains atomic or composite processes) and a complex goal (stated by the user in the form of a task description) in generating a composition plan. The most popular AI planning techniques are the Hierarchical Task Network (HTN) planner using Situation Calculus (SC) as discussed by (Sirin, E. & Parsia, B., 2004; Sirin et al., 2004). Event Calculus (EC)-based composition as discussed by Aydin et al. (Reference Aydin, Cicekli and Cicekli2006, Reference Aydin, Cicekli and Cicekli2008); Planning Domain Definition Language (PDDL)-based composition as introduced by Yang and Qin (Reference Yang and Qin2010); and Compositional/Process Algebra (PA, Bergstra et al., 2001)-based composition as given by Hashemian & Mavaddat, Reference Hashemian and Mavaddat2006; Forgy, 1991).

HTN planner (Sirin et al., Reference Sirin, Parsia, Wu, Hendler and Nau2004) uses a task decomposition approach, called the fragmentation process that divides complex tasks into smaller subtasks until it reaches atomic tasks that can be executed directly. The advantage of the HTN method is that it decreases the complexity of planning phase that may require many steps, however, the mechanism of dividing high-level tasks is in itself difficult to execute accurately.

The basic ontology of EC is very similar to that of SC. Aydin et al. (Reference Aydin, Cicekli and Cicekli2006, Reference Aydin, Cicekli and Cicekli2008) contributed a valuable approach to the problem of composition of Web services by using the EC method. This work presented a method of translating the OWL-S ontology to EC events and actions. The main idea is to get a suitable composition plan with complex actions by using EC as an alternative approach to building agent technology, based on the notions of generic procedures and customizing user constraints.

The PDDL; (McDermott, Reference McDermott1998) is widely documented as a standardized input for high-tech planners and used for composition of Web services. Consequently, the mapping process from DAML-S or OWL-S representations to PDDL is very user friendly and simple to operate because the ontology languages have been strongly influenced by PDDL and vice versa. Yang and Qin (Reference Yang and Qin2010) proposed that the OWL-S description of SWSs can be translated into a description written in PDDL. Also they developed several key procedures of the translating algorithm for OWLS2PDDL and vice versa.

Hashemian and Mavaddat (Reference Hashemian and Mavaddat2006) represented the behavior and operations of a Web service using a simple PA, called ‘Composition Algebra’. PA operators are used to find a solution for automatic composition from stateless components, which had a simple two-step workflow: receiving inputs and then returning the corresponding outputs. They provided a forward chaining algorithm to find possible components for composition in order to achieve a requested behavior. However, the proposed approach is not modeled on Semantic Web, thus lacks semantics.

Most researchers concentrated either on semi-automated or fully automated techniques for Web services composition, drawing inspiration particularly from AI planning and Process Calculi. However, these approaches are lexical in nature and can only return service composition upon user's necessity description, which lacks flexibility in meeting later change. Two important contributions of this present study are that the SCA takes advantage of its own TKBO, and RAAs based inferencing. Using TKBO, Web services can be defined as instances of classes by using OWL semantic tags that represent Web services capabilities based on their OWL-S descriptions. A domain-specific TKBO contains commonly used task instances for a specific domain (e.g. Online Book Selling/Buying, Traveling, or Car Selling/Buying, etc.), I/O/P/E concepts of the described task instances, and semantically described task dependencies through RAAs by using OWL tags (e.g.Table 5 contains four task instances of the Online Book Store Domain). Additionally, SCA keeps the semantic contexts of task dependencies belonging to the newly constituted composite task in the corresponding domain Tasks ontology (TKBO) for possible reuse. For example, Tables 6 and 7 display Profile and Process models of the returned composite process (AnotherBook-Process). The technique saves time and effort whenever same composite task is requested or may be used to form more complex composite tasks later.

Additionally, in order to select suitable tasks for the required composition, the SCA searches over lesser number of the related task instances that are in the interest domain TKBO instead of searching over a large number of candidate OWL-S (POKB) processes at first. After specifying the suitable task instances for newly constituted appropriate solution plan by Planner, the SCA selects same structured OWL-S atomic processes (a task instance is having same I/O/P/E with a candidate OWL-S atomic process) from candidate set by looking only the included task instances in the plan. After execution of the resultant plan, the semantic contexts of the newly produced composite task will have been embedded into the TKBO if the newly produced composite task was not produced and recorded before. Therefore, the SCA does not require to search and parse the large set of candidate OWL-S processes, which makes the performance better compared with other solutions in this case. Although many proposed solutions employ Semantic Web technologies, however, they do not take advantage of such a common TKBO.

Moreover, the SCA has a different and extended matching mechanism since the matching task takes into consideration similarity and defines relations such as is_a, synonym, or equivalentClass between I/O concepts of processes. Additionally, the process matching task considers both properties that are rdf:ID(matching of input- output) concepts and process:parameterType properties (see details in Section 4). Consequently, relevant combinative processes will not be missed in finding a composition plan.

As mentioned above, the SCA System draws advantages from its OWL ontology knowledge bases due to their expressive nature and semantic richness. SCA uses the RAAs to further elaborate on such rich knowledge bases. In fact, AAs being created for the relational models, this may bring to one's mind the question: How appropriate is to employ RAAs/AAs in connection with OWL ontologies. In order to address this issue, and relate AAs to OWL, let us study the ontology spectrum. Obrst (Reference Obrst2003) developed an ontology spectrum as a framework for illustrating various information models relative to others in terms of their semantic richness. An abridged version of the Obrst ontology spectrum as depicted in Figure 2 lines up some existing mainline semantic languages or models by plotting them on a span from weak to strong semantics. Obrst says that ‘Weak semantics indicate the expression of very simple meaning while strong semantics indicate the expression of arbitrarily complex meaning. As one progresses up the spectrum, the domain semantics are based on logic, allowing the machine to make valid inferences and execute sound semantic constraints’ (Obrst, Reference Obrst2003).

Figure 2

Ontology spectrum: weak to strong semantics (after Obrst, Reference Obrst2003).

All models of the given spectrum have an association with each other that correspond to semantic expressiveness and syntax; for instance: the Description Logics (DL) syntax can be used for a description of OWL ontology or knowledge base. A concept from DL is referred to as a class in OWL and a role from DL is referred to as a property in OWL. Furthermore, the Relational Model (RM) has a strong mathematical foundation. This makes it closer to the DL layer, which is the basis for many ontology languages, including OWL. In addition, tables in the RM are equivalent to ontology classes. The main advantage with respect to ER is that the relational model includes domains for the attributes (Fagin, Reference Fagin1977; Abiteboul et al., Reference Abiteboul, Hull and Vianu1995; Rao & Su, Reference Rao and Su2005; Motik et al., Reference Motik, Horrocks and Sattler2007). Higher level semantic models on the spectrum provide more expressiveness, semantic richness and complexity than those in the lower levels. On the other hand, while climbing from the bottom to the top, there will be no semantic loss. To the contrary, more powerful descriptions of functions, data and properties will be availed. The AAs are well known and widely used in inference rules in the area of the Relational models and Databases. Consequently, it is just to say that, AAs may as well be a suitable approach to derive tasks dependencies of a composition as used in Sections 6 and 7 in relation to SWSs.