Profile Parameter

A profile parameter (parameter for short) is the notion used to capture an input, an out- put, or a non-functional property; as noted inSection 4.1.5, categories are abbreviated I, O, N, respectively. It consists of five elements. First, a name that is usually human- assigned. In the service model, the name of a parameter is merely used for identification purposes. Although practical names often carry superimposed semantics, we shall not

assume that this is generally the case for parameter names. Second, a type used to relate a parameter to a shared conceptualization (i.e., an ontology). The type is, therefore, the central means that captures the semantics of a profile parameter. Third, a data value that can be any kind of data item, but not a data stream as discussed inSection 4.1.1. For an IO parameter, the data value is the actual input or output in the format as consumed or produced by an operation or a service. The data value of an N parameter is optional as it is not part of the data processed by a service; if used then it is the quantity or nominal assigned (e.g., MAXRESPONSETIME = 30 sec; CERTIFICATION = ISO 9001). Fourth, a

profile parameter includes a finite set of representatives. Representatives can be referred to by variables in preconditions and effects in order to instantiate (ground) them. Each representative is either an individual name or a lexical form (seeDefinition 3.2and3.9). The existence of representatives in addition to the data value is owing to the observation that practical operations and services are often heterogeneous in the sense that different data formats are in use. More specifically, a data value may be in a format that cannot be directly used within preconditions and effects.

Finally, a profile parameter includes an assignment function, denoted with σ, that cap- tures how the representatives are determined. There are basically two types. For an IO parameter, σ establishes a relationship between the data value and the representatives (i.e., how the latter are derived from the former). For an N parameter, σ can also de- scribe a query operating, for instance, over context information, a KB, or other sources of information. As will be seen, σ is simple (e.g., a syntactical transformation) down to trivial in some cases. A profile parameter is formally defined as follows.

Definition 4.1(Profile Parameter). Let VI,VLSbe a set of individual names and lexical forms, respectively. A profile parameter (parameter for short) is a 5-tuple Pa= (id, type, val, Re, σ)

where

• id is the name (or identifier) of the parameter,

• type is either a concept or a data range, called the type of the parameter, • val is a data item, called the data value optionally assigned to the parameter,

• Re = {r1, . . . , rn}is a finite set of representatives ri∈ VI∪VLSindexed by consecutive integers{1, . . . , n}, and

• σ is an assignment function (or procedure) for Re.

The lowest numbered representative r1 is called the primary representative and the rest are secondary representatives.

A profile parameter is concrete if its type is a data range and general otherwise.7 A profile parameter is instantiated (or ground) if Re is non-empty.

We will use the function-like notation id(Pa), type(Pa), val(Pa), and Re[i](Pa) to denote the name, type, data value, and the i-th representative of a parameter Pa, re- spectively. In concrete examples, we will write PAR:Type to denote a parameter named PAR, whose type is a concept or data range named Type (i.e., type(PAR) = Type).

7_{The terminology is chosen in analogy to concrete domains versus the general-purpose domain (see}

Two parameter Pa1, Pa2are said to have the same name, written id(Pa1) =id(Pa2), iff the strings are the same sequence of characters. Two parameter are said to be equivalent, written Pa1 ≡Pa2, iff their types are equivalent; that is, given a KBK,

K |= type(Pa1) ≡type(Pa2) .

Equivalent parameter therefore have the same extension in every interpretationI that is a model of K. Consequently, profile parameter are ascribed with Tarski-style model- theoretic semantics [Tar56] as membership over sets. Two parameter are said to be the same, written Pa1= Pa2, iff they have both the same name and are equivalent.

The name and the type of a parameter are assumed to be static, meaning that they are assigned at design time. In contrast, we shall abstract from whether the data value val (and hence the set of representatives Re) is constant or variable between different service instances since this is a relative matter.8 In the same vein, we can abstract from whether there is a default value for val, which would be specified at design time and used by default whenever a value is not assigned at runtime. However, it is important that val and hence Re are service instance bound for IO parameter while we can also abstract from that for N parameter. An IO profile parameter can therefore also be understood as a statically typed instance variable while an N parameter need not be instance specific.

Details on data formats for val are intentionally left unspecified in Definition 4.1. The reason is to allow the use of various kinds of (possibly “complex”) data depending on the actual data formats consumed and produced by an operation or service. Subject to the actual grounding, the data value might therefore further involve a second-party type. Note that type and the second-party type need not necessarily be the same, though both are certainly in a more or less close intensional relationship.

The primary representative Re[1] is special insofar as – analogous to a typed vari- able in a programming language – the type of a profile parameter defines the range of representatives that can be assigned for Re[1]. An assignment outside such a range is considered illegal. For a concrete parameter Pa, Re[1]is generally a lexical form repre- senting an element from the value space of the data range. Formally, given a DL+D

interpretationI with the datatype and data range interpretation function·D,

(Re[1](Pa))D ∈ (type(Pa))D . (4.1) Analogous, for a general parameter Pa, Re[1]is required to be an instance of the concept; that is, given an interpretationI,

(Re[1](Pa))I ∈ (type(Pa))I . (4.2) We note that the requirement expressed byEquation (4.1) and (4.2)can be equally ex- pressed by a precondition. Therefore, we leave it to the discretion of an implementation how they are actually enforced. Secondary representatives (if any) are exempted from this restriction and can even be a mixture of individuals and lexical forms. However, we require all representatives to be compatible to the preconditions and effects by whom they are referred. This will be detailed inSection 4.2.2.

<Person> <firstName>Alice</firstName> <lastName>Wond</lastName> <birthday>03.03.2003</birthday> <SSID> 123 456 789 </SSID> </Person> { "Person" : { "firstName" : "Alice", "lastName" : "Wond", "birthday" : "03.03.2003", "SSID" : " 123 456 789 " } } Re = { urn:example.org#AliceWond₁ , 123 456 7892 } @prefix : <urn:example.org#> . <:AliceWond> a :Person; :firstName "Alice"; :lastName "Wond"; :birthday "03.03.2003"; :SSID " 123 456 789 " . σ1 _σ2 σ3 σ1 σ2 σ3

Figure 4.3: Exemplary input/output values in different data formats: XML (top left), JSON (top right), and RDF Turtle syntax (bottom). Value-specific assignment functions

σ1, σ2, and σ3 specify how representatives are determined. In this case the primary representative shall be a person’s concatenated name plus a namespace prefix and the secondary representative its social security Id.

If a parameter is referred to by a precondition or an effect, or if it is taken into ac- count for the purpose of dynamic failure recovery (the former of which detailed inSec- tion 4.2.2and the latter inSection 5.4.4) then Re is non-empty. Elements of Re are then determined by the assignment function σ. In general, σ may be an n-ary function such that

Re :=σ(α1, . . . , αn) n≥0 (4.3) and where α1, . . . , αn are the arguments. As mentioned above, the representatives of IO parameters are solely derived from the data value; that is, Re :=σ(val). Figure 4.3illus-

trates the relationship between val, σ, and Re using a simple practical example where also three different data formats are considered. Further details on σ are as follows. Concrete Input and Output Profile Parameter

Valid data values for concrete parameters are all lexical forms in the extension of the data range; that is,

(val(Pa))D ∈ (type(Pa))D . (4.4) This means that an operation or service directly takes or produces, for instance, an inte- ger value. Therefore, σ is either a trivial identity mapping such that Re[1](Pa) = val(Pa)

or a simple syntactical conversion from one lexical space into another (e.g., a date from the US locale specific date format into DE specific date format). Since there can be at

most syntactic differences between val and Re[1], one of them – preferably the represen- tative – is actually redundant and can be factored out in an implementation. Secondary representatives are usually not needed for unary datatypes such as numbers. For com- posite datatypes such as dates or other n-ary datatypes they might be needed in order to reference a component of a data value (e.g., the day of a date).

General Input and Output Profile Parameter

There are basically two possibilities for general IO parameters. In the simple case, the data value is an individual name. Analogous to concrete IO parameters, this means again that Re[1](Pa) = val(Pa)and σ is the trivial identity mapping. Hence, in order to satisfyEquation (4.2),

(val(Pa))I ∈ (type(Pa))I . (4.5) An example for this simple case would be an operation that consumes or produces a data item that is an IRI and that refers to an OWL individual. Observe, that the data item can be an anonymous instance of the concept (i.e., val(Pa) 6∈ VI). In this case, there would be an artificial name (that is not meaningful to the application) created by a Skolemization-style approach (e.g., an anonymous OWL individual corresponds to a blank node in RDF).

On the other hand, the data value might be a more complex structured data item. For instance, SOAP-based Web services use XML Schema elements to define the in- put/output parts of messages exchanged. Therefore, val can also be a data item that is an instance of a second-party type. Such a type is understood to allow for a possi- bly infinite set of data items where each data item is well-formed in the sense that it complies to the type’s specification. Usually, the specification imposes structure and syntax on data (and might also include a set of operations that can be applied on in- stances of the type). Examples of such second-party types are XML Schema elements or types of (object-oriented) programming languages such as Java classes. The assign- ment function σ then represents a conversion that is supposed to select and/or extract the representatives (cf.Figure 4.3). Rather than being a generic function as in the sim- ple case mentioned before, σ is then specific to the second-party type and needs to be defined as part of the design process. The Extensible Stylesheet Language (XSL) is one example for specifying and performing such conversions.

Non-Functional Profile Parameter

Since a non-functional parameter – no matter whether concrete or general – differs from “real” IO parameters in the sense that it does neither represent a data item consumed nor produced, σ is a function that rather captures where the representatives come from. For instance, when the representatives are dynamically determined by a query q over a knowledge base K (or any other information source), thus, Re := σ(K, q). Another

example would be the case where σ is a trivial null-ary function returning a constant primary representative.

Remark on Profile Parameter Types

The type of a parameter is taken from a domain ontologyO(that was loaded into a KB). In general, O can be local or global in the domain. If it is local then there are possibly other local ontologies in the domain. They are designed independently, for instance, by different service providers, and all of them might model the domain in more or less different and overlapping ways. If O is global then it is either shared by all partici- pants in the system (which means that there is a high degree of standardization), or one can assume that it represents the combination of all the local ontologies where concepts and data ranges have been merged or aligned. The assumption of such a possibly dy- namically constructed global ontology is (tacitly) made by numerous DL-based service discovery/selection approaches (e.g., [SWKL02, CWT08, SMM10, TRBD11]). The prob- lem of (automated) merging or aligning multiple local ontologies [ES07] is not a goal of this thesis.