Functional Profile Equivalence

We formulate the criteria for profile equivalence regarding the functional dimension in a similar way to structured matchmaking described inSection 5.4.1. The main concept is straightforward: we consider inputs, outputs, and effects (IOE); hence, preconditions are not considered, the reasons of which will be discussed below. It is important to understand that we formulate a minimal criterion that comprises properties that are re- quired at least to get a semantically equivalent execution: equivalent effects, required

outputs, while satisfied with the same set of inputs available. It is therefore not con- tributing another approach to the service matchmaking, apart from the introduction of a revised criterion of effect matches (cf. Condition (5.5)) and revised match criteria described next.

We have found that the conventional approach reflected byCondition (5.2)and(5.3)

cannot be utilized in that form for our purposes for two reasons. First, the actual data flow of a composite service also needs to be taken into account rather than just pro- files themselves. Second,Condition (5.2)and(5.3)happen to form a surjective relation. This may lead to ambiguous situations that result in false positive matches; it should be noted that this was also recognized and described similarly in [KFS09]. The conse- quence of surjectivity is that an input (output) in one profile might match more than one input (output) in another profile, which is illustrated by Example 5.2 and further explained afterwards. Therefore, a stricter relation is needed. Not surprisingly, it turns out that a one-to-one correspondence (i.e., a bijective relation) effectively disambiguates these situations. This in turn raises the question whether a match generally implies a single, unique bijection. Unfortunately, the answer is negative. As we will see, there is a special case, illustrated byExample 5.3, in which more than one such bijection exists rather than a single unique one. As a result, more information is needed in order to decide which one to choose. On the other hand, since we can precisely identify the root of this case, we can formulate syntactic restrictions under which it does not occur, in general.

Example 5.2

Suppose a data range inclusion int v long and two profiles Prr and Pra having the following output sets:

Prr.O = {U:int,V:long} Pra.O = {X:int,Y:date}

According to Condition (5.2), Pra is a plug-in match for Prr regarding O becauseU is

matched byXandVis also matched byX; Yis a spare output.

This may happen analogously for inputs. Suppose Prr and Pra have the following input sets:

Prr.I = {U:int,V:date} Pra.I = {X:int,Y:long}

According toCondition (5.3), Prais a match for Prrregarding I becauseXis matched by

UandYis also matched byU; Vis a spare input.

The problem inExample 5.2is that though the outputs of Prr are obviously not the same (otherwise there would be just one output), they are not sufficiently semantically differentiable since int is a long. In general, this problem is the result of the following cooccurrence:

1. A reflexive, transitive relation./is used (e.g.,vor≡) for pairwise matching pro- file parameters.

2. A parameter in one profile either directly or transitively ./-relates to more than one parameter in the corresponding set of another profile.

That is, if there is a sequence

type(Pa1) ./ type(Pa2₁) ./ . . . ./type(Pa2_n) (n≥2)

where Pa1, Pa2₁, . . . , Pa2n are parameters from the same kind of set (e.g., I or O) of two profiles Pr1, Pr2. For example, inExample 5.2we have

type(X) | {z } Pra_.O vtype(U) v type(V) | {z } Prr_.O

on the outputs and

type(U) | {z } Prr_.I vtype(X) vtype(Y) | {z } Pra_.I

on the inputs. Observe that transitivity does actually not come into play in this example; it can be easily modified such that it involves transitivity, which we leave as an exercise. Clearly, what is required is a one-to-one correspondence on matching profile param- eters: every parameter that is used should have a unique correspondent. Formulated in mathematical terms, we want to find a bijection m : X1 → X2 where X1, X2 are sets of matching profiles parameters. Such a bijection obviously does not exist forExample 5.2; we can find two surjective mappings m1: Pra.I →Prr.I and m2: Prr.O →Pra.O instead.

Example 5.3

Again, suppose a data range inclusion int v long and two profiles Prr and Prahaving the following output sets:

Prr.O = {U:int,V:int} Pra.O = {X:long,Y:long}

Then there exist two different bijections m1, m2each satisfyingCondition (5.2): m1: m1(U) = X, m1(V) = Y

m2: m2(U) = Y, m2(V) = X . Again, this may happen analogously for inputs.

Example 5.3 illustrates the case in which more than one bijection m exists, rather than a single one. The triggering cause here is the existence of a sequence of four related parameters, of which two are in each profile:

type(Pa1₁) ./ type(Pa1₂) ./ type(Pa2₁) ./ type(Pa2₂) .

It is not difficult to see that one can avoid this case by requiring that profile parameters within one of the different types of sets of a profile Pr are not related among each other; that is, if

∀Pa1, Pa2 ∈ Pr.X and Pa1 6=Pa2: type(Pa1) 6vtype(Pa2) (5.8) where X is, for instance, the set of inputs or outputs. This raises the question whether this restriction is too confining. We leave a discussion of this question toSection 5.7.1.

Effects are incorporated as follows. Given effect atoms of the form defined byEqua- tion (4.10), we require a one-to-one correspondence m analogous to inputs and outputs and based on the equivalence relation (≡), thereby being in accordance with Condi- tion (5.5). The rationale behind using “≡” is that two services (or operations) should be considered equivalent only if they create the same effects. Since effect atoms of DL- based effect systems are expressed using concept names and role names, this indeed means that only the same concepts/roles qualify as equivalent (since “≡” is reflexive).

Interestingly enough, the constraint expressed byEquation (5.8)is natural for effects. In fact, the case of a set of effects E that violates Equation (5.8) should be regarded a modeling fault because redundancy is modeled. This is easily seen: Suppose the set of effects E of some profile contains two effect atoms A1(x)and A2(x). Suppose there is an inclusion A1 v A2in the domain (which implies that A2 is a ramification of A1). Then A2(x)is redundant in E as it is implied by A1(x)anyway; hence, it should be removed from E. The consequence is that, given profiles that adhere to Equation (5.8), either a bijection exists between two sets of effects or none exists, but never more than one.

We are now ready to introduce our notion of functional profile equivalence.

Definition 5.5(Functional Profile Equivalence). Let Sc = (id, Pr,U, Gcf, Gdf)be a service, Prr ∈ (S

u∈Sc.Uu.Pr) ∪Sc.Pr a requested profile of Sc. Let X be a subset of the sources available

w.r.t. Sc’s data flow Gdf as an input for Prr.14 Let Y be the subset of outputs Prr.O that are actually consumed w.r.t. Sc’s data flow Gdf.15 We define the binary relation ∼C on profiles16 by setting Prr ∼C Pra iff there exist bijective mappings mI : X → Ia, mO : Y → Oa, and mE: Er →Easuch that

• ∀x ∈ X : type(x) v₁type(mI(x)), • ∀y ∈Y : type(y) w type(mO(y)), and • ∀ϕ∈ Er: ϕ≡mE(ϕ).

If Prr ∼C Pra then the advertised profile Prais said to be functionally equivalent to Prr w.r.t. Sc’s data flow Gdf.

Observe that outputs of the requested profile Prr that are not consumed anywhere in the overall data flow of Sc can be ignored. Conversely, since the data flow is defined to provide a value for every input that a profile lists, such cases cannot exist for inputs.

Another interesting observation regarding effects is that the approach expressed by

Definition 5.5is independent of their change semantics ascribed by the actual effect sys- tem. The reason is not found in a general commonality between different effect systems. What matters in this regard is that the same effect system is used for all effects applied to a KB. Only if different effect systems are used for applying effects to the same KB then they need to be mutually compatible, whatever compatibility precisely means in this case. What is more, the approach is also not restricted to effect systems whose effect

14_{Formally, X⊆ {x|x∈Oand x≺}

G_cf i}where i∈ Prr.I, O is the set of sources of Gdf, and x≺G_cf i is defined according toEquation (4.24).

15_{Formally, Y= {y|y∈Pr}r_{.O and∃x.(x, y) ∈ L99}whereL99is the flow relation of G} df. 16_{The symbol∼}C _{is chosen such that it indicates the relation’s asymmetry.}

expression languageLESis DL-based. In principle, any framework can be used that de- fines an appropriate and decidable semantic generalization (subsumption) relation and where mutual generalization describes equivalence.

Finally, there are two reasons that justify the absence of preconditions for functional equivalence. First, the inclusion of preconditions is more of a dictate than a contribution to the decision whether an advertised profile describes equivalent outcomes. Requiring a plug-in or exact match for preconditions reflects the assumption that all candidates have similar requirements in order to be operable, which might not be the case. It is easily conceivable that services/operations have (completely) different preconditions yet are functionally equivalent. Including preconditions would therefore dictate condi- tions, which is more of an unnecessary restriction. In fact, one can actually not know what conditions one should require from an advertised profile to be operable. Second, it is even not essential to include preconditions bearing in mind that they need to eval- uate to true anyway in order to be executable. What matters is that preconditions are satisfied at commencement of execution of the service/operation they describe.