*: Alphabetical order
This document is also available in non-normative PDF version.
Copyright © 2004 DERI®, All Rights
Reserved. DERI liability,
trademark, document use, and software licensing rules apply.
This document provides a more detailed specification of the concept of Mediators as a top level element of the Web Service Modeling Ontology WSMO. Mediation is concerned with handling heterogeneity by resolving possibly occurring mismatches between resources that whose interoperability would be useful but is not given a priori. As heterogeneity naturally arises in open and distributed environments, and thus in the application areas of Semantic Web Services, WSMO identifies Mediators as a core element of Semantic Web Services. The aim is to define specification, usage and mediation techniques of WSMO Mediators as an extension of the definition provided in the WSMO specification [Roman et al., 2005].
The document is structured as follows. The remainder of Section 1 outlines the aim and approach for mediation in WSMO, Sections 2 to 5 specify the distinct types of Mediators in detail, and Section 6 concludes the document.
Heterogeneity is an inherent characteristic of open and distributed environments like the Internet that hampers interoperability and thus automated Web service usage. A major merit of the Semantic Web and Semantic Web services is that all information and resources carry unambiguous semantic descriptions. This allows development of general purpose mediation techniques and infrastructures that work on declarative, semantic resource descriptions. Consequently, WSMO aims at providing techniques and an infrastructure for handling all kinds of heterogeneity that potentially occur within Semantic Web services. The approach taken in WSMO for realizing an integrated mediation framework for Semantic Web services is explained in the following.
In order to tackle heterogeneity handling as a major issue within the Semantic Web and Semantic Web services, WSMO defines the concept of Mediators as a top level notion in order to support mediation-orientated architecture for Semantic Web services. Implementing the WSMO design concept of strong decoupling and strong mediation, the WSMO mediation framework presented in this document is comprised of a general structure definition of mediators as architectural components and a typology of different mediators along with infrastructural correlations between them.
A WSMO mediator connects heterogeneous components and resolves mismatches between them. The general structure of WSMO mediators is shown in Figure 1, stating:
 |
|
Figure 1: WSMO Mediator Structure
|
Heterogeneities that might hamper Web service providers and requesters interacting successfully can arise on different levels, e.g. between terminologies or representation formats used by distinct entities. For resolving mismatches that potentially occur on each of these levels, corresponding mediation techniques are needed. WSMO understands its top level elements - Ontologies, Goals, Web Services, and Mediators - as the core elements of Semantic Web service technology. In consequence, WSMO distinguishes four mediator types that connect related WSMO elements and resolve mismatches between them. The different mediators are named by prefixes, denoting WSMO elements as the respective source and target components, and use respective mediation techniques for resolving mismatches that can potentially occur between the source and target components. Namely, these are OO Mediators that connect ontologies and resolve terminology as well as representation and protocol mismatches, GG Mediators that connect Goals, WG Mediators that connect Web services and Goals, and WW Mediators that connect Web services.
Understanding the WSMO top level elements as the core elements for Semantic Web services, these mediator types specifically allow defining the heterogeneity handling with respect to the mismatches that might occur between these elements.With respect to an integrated mediation architecture for Semantic Web services, the following architectural correlations hold :
A formal specification of the WSMO mediation architecture is considered as future work. The following sections define each mediator type in more detail. Thereby, we subsequently introduce the identified mediation techniques for Semantic Web services.
While related work on the distinct mediation techniques is discussed in the subsequent sections, we briefly examine work related to mediation architectures.
With respect to heterogeneity being identified as a major issue for future IT systems, [Wiederhold, 1994] propagated mediator-orientated architectures in the early 1990ies. A mediator is a special kind of software component capable of dynamically handling heterogeneities that hamper functional components from successful interoperation. The aim is to develop general purpose mediation techniques that work on abstract, semantic level independent of concrete application domains. Therefore, a mediator is understood as an entity capable of establishing interoperability of resources that are not compatible a priori by resolving mismatches between them at runtime. The aspired approach for mediation relies on declarative description of resources whereupon mechanisms for resolving mismatches work on a structural, semantic level, in order to allow defining of generic, domain independent mediation facilities as well as reuse of mediators. The WSMO mediation framework follows this idea.
Concerning the needs for mediation within Semantic Web services, the Web Service Modeling Framework WSMF - the conceptual basis of WSMO - distinguishes three levels of mediation [Fensel and Bussler, 2002]. (1) Data Level Mediation - mediation between heterogeneous data sources; within ontology-based frameworks like WSMO, this is mainly concerned with ontology integration, (2) Protocol Level Mediation - mediation between heterogeneous communication protocols, i.e. translation between technical transfer protocols (e.g. SOAP, HTTP, etc.), and (3) Process Level Mediation - mediation between heterogeneous business processes; in WSMO, this is concerned with mismatch handling on behavioral Web Service Interface descriptions for information interchange, communication, and cooperation between Web services and clients. The mediation framework for presented in this paper covers all of these levels, and introduces another level: Δ-Relation Mediation for explicitly describing the logical relationship between functional descriptions of goals and Web services in order to enable efficient resource management.
An early approach for realizing a mediation technology that follows Wiederhold's propagation has been presented in the MedMaker project in the mid 1990ies [Papakonstantinou et al., 1996]. The approach is based on a proprietary, not ontology-based description language for resources called the Object Exchange Model (OEM), and a Mediator Specification Language (MSL), which both are defined as FOL languages. The latter is used for specifying rules that integrate heterogeneous OEM resource descriptions, thereby enabling information interchange between heterogeneous resources. The referenced paper further presents a system implementation Mediator Specification Interpreter (MSI) that is capable of reading and executing MSL specifications. This work can be seen as a predecessor of data level mediation as realized in OO Mediators (see Section 2). Therein, OEM refers to ontologies, respectively WSMO descriptions of goals and Web Services, while MSL refers to the ontology mapping language as specified in Appendix A.
A more recent approach concerned with the formal specification of mediators as software components is presented in [Barros and Borger, 2005]. The authors propose eight basic mediation patterns, four for bilateral communication and four for the multilateral mediation patterns and further define combinations and refinements of the basic patterns. However, all these basic patterns and their combinations/refinements are defined using hard-coded Abstract State Machines [Borger, 1998] and before-hand defined predicates, obtaining in this way an inflexible, rigid model. In our approach we would like to be more flexible, for allowing easily extensions of the addressed patterns.
OO Mediators (or ooMediators) are fundamental components of the mediation mechanism proposed by WSMO. They represent bridging entities between the ontologies used to semantically describe all the other WSMO entities. ooMediators can be used by any WSMO element (including mediators) when the ontologies needed in the modelling of particular semantic descriptions contain overlapping (maybe even conflicting) aspects. In this section we discuss the aims of the ooMediators and how they can be used, we go in detail through the definition of an ooMediator and we continue with aspects of the underlying mediation techniques.
The following gives a general overview on the aims and usages of an ooMediator (subsection 2.1), followed by a detailed analyses of its definition (subsection 2.2). The last subsection (subsection 2.3) presents some aspects related to the mediation techniques behind an ooMediator.
Conforming to WSMO, all aspects related to Semantic Web Services have to be semantically described using ontologies. A creator of such descriptions has the choice of creating their own ontology or to reuse already existing ones. As the ontologies are "shared conceptualizations", reusing ontologies should be the first choice in any modelling process and WSMO directly supports this by the importsOntology statement. Sometimes it might be necessary to refer to multiple ontologies that can describe overlapping domains using different concepts and even conflicting models.
In the next section we describe in details the structure of an ooMediator, emphasizing aspects that can be useful in both the creation and the reuse of ooMediators.
Applying the inheritance principles we derive the following structure for an ooMediator:
Class ooMediator sub-Class mediator
hasNonFunctionalProperties type nonFunctionalProperties
|
In the rest of this section we will expand and particularize the definition of each of its constituents presented in [Roman et al., 2005]. By this we intend to capture the specific characteristics of the ooMediators and to provide the prerequisites for their creation and usage.
The non-functional properties of an ooMediator remain identical with the general definition of non-function properties for mediators as described in [Roman et al., 2005]. In addition, we recommend the usage of another non-functional property that can play an important role in discovery and selection of ooMediators:
usedMappingLanguage type mappingLanguage
By using this non-functional property the designer of the ooMediator can offer an insight into the internal mechanism behind the mediation service.
The importsOntology statement points to the ontology that describes the terms used in defining the ooMediator. For example the mapping language referred by the above non-functional property can be described in more details in the imported ontology. As we don’t have the usesMediator statement in an ooMediator it is assumed that the imported ontologies are free of heterogeneity problems.
An ooMediator can have as a source either an ontology or an ooMediator. In the first case this indicates that the mediation process will be applied to entities that can be found in the name space of this ontology.
The second case is more interesting having as source component an ooMediator. Let’s considers the following example:
ooMediator
_"http://example.org/ooMediators/secondMediatorExample" ooMediator
_"http://example.org/ooMediators/firstMediatorExample" |
In this case, the role of the source for the secondMediatorExample will be played by the target of the firstMediatorExample. This means for this example, that the mediation process will be applied to entities that can be found in the name space of firstMediatorExample. firstMediatorExample might be a syntactic mediator having the role of converting an ontology (e.g. firstSourceOntology) from one representation language into another.
As a general remark, the source of an ooMediator should never be referred directly in a WSMO entity that uses that particular ooMediator. The reason is that an ooMediator is used to make that source entity available in a heterogeneity-free and consistent way in the component using the ooMediator. By going around the ooMediator and directly referring concepts, relations, individuals etc. from the source component the description that is currently built might become inconsistent.
There are four possible cases with respect to the types of entities allowed as target components for an ooMediator:
Class goal
hasNonFunctionalProperties type nonFunctionalProperties
|
Important for these discussions are the importsOntology and usesMediator statements. Our ooMediator has to be specified in the usesMediator statement while the importsOntology has to point to the source ontology of this ooMediator. An example of these would be:
ooMediator
_"http://example.org/ooMediators/firstMediatorExample" goal
_"http://example.org/goals/goalExample" |
The mediator guarantees that the problems of heterogeneity between the source ontology (in out example firstOntology) and all the imported ontologies are solved. Please note that this mechanism can be used to determine which mediator was used to import a particular ontology when multiple ontologies are imported and multiple ooMediators are used.
ooMediator
_"http://example.org/ooMediators/firstMediatorExample" |
This is the case of syntactical mediators which have the role of converting an ontology (e.g. firstSourceOntology) from one representation language into another. Such a mediator can appear as a source component for another ooMediator. Another interesting usage would be the one in Listing 6.
ooMediator
_"http://example.org/ooMediators/firstMediatorExample" ooMediator
_"http://example.org/ooMediators/secondMediatorExample" webService
_"http://example.org/ws/wsExample" |
firstMediatorExample could be a syntactic ooMediator transforming firstSourceOntology from an arbitrary ontology language to WSML. The transformed ontology is made available through the namespace of secondMediatorExample, which in its turn has the role of solving the heterogeneity problems between the transformed ontology and secondTargetOntology. Inside of wsExample we can refer to elements from secondTargetOntology which is aligned with the entities modelled in the firstMediatorExample. Please note that the firstSourceOntology and secondMediatorExample cannot be referred from wsExample as they are source components in one of the used mediators.
It is important to stress that the target component of an ooMediator doesn't necessarily indicate what WSMO element uses that mediator, but rather indicates where or how the mediation results are made available. Though, for example, if the ontology A imports another ontology S and uses an ooMediator M, where M has as source the ontology S, and as target the ontology A, it means that one can refer in terms of ontology A to elements modelled in ontology S.
The hasMediationService links the description of the ontology mediator (i.e. WSMO ooMediator) with a concrete solution for ontology mediation. This mechanism allows using ooMediators to describe pieces of functionality offered by complex services able to perform concrete mediation scenarios: instance transformation, query rewriting, etc.
There are three possibilities of connecting to the mediation services, using hasMediationService , by specifying a:
Listing 7 presents an example of such a mediation service together with the relevant aspects modelled in the ontology it imports. The service is able to perform instance transformation between two given ontologies, location ontology and addresses ontology and viceversa. The capability of this service specifies that it is able to transform instances of the concept City in the location ontology to instances of concept city in the addresses ontology. It is important to note that no details regarding what this transformation actually means are revealed in this capability but only that this transformation is taking place. Of course, if desired, such information could be included, for example in the effect of the capability; these details could even contain the whole ontology alignment specification (e.g. mappings expressed as WSML axioms).
| namespace {
_"http://www.wsmo.org/ontologies/Mediator#", dc _"http://purl.org/dc/elements/1.1#", wsml _"http://www.wsmo.org/wsml/wsml-syntax#", loc _"http://www.wsmo.org/ontologies/location#", addr _"http://example.org/ontologies/addresses#" }
webService_"http://www.wsmx.org/webservices/DataMediator" importsOntology
{_"http://www.wsmo.org/ontologies/location#", capability assumption postcondition interface |
We also do not exclude the possibility to point from the mediation service capability to external documents containing the full specification of the mappings that are going to be used in the mediation process by the service. As the default language used to represent WSMO ontologies is WSML, the default way of representing the ontology mappings would be by using WSML axioms. It is however possible to represent mappings using other ontology representations languages or even an abstract mapping language as the one presented in Appendix A. It is then possible to specify the mapping language used, via the usedMappingLanguage non-functional property (if not specified the mappings are assumed to be expressed as WSML axioms).
Data mediation level has a crucial role in all mediation aspects that are described in this document: the process mediation level relies on it and all four types of mediators introduced by WSMO [Roman et al., 2005] refer to it in order to achieve their functionality. Data mediation is a very well explored area and a multitude of approaches were developed in this direction. In this section our scope is not to describe a particular solution or approach for such a mediator but to draw the requirements such a mediator has to meet (subsection 2.3.1) in order to suits the needs of WSMO mediators. In addition we give a very short overview of what ontology mediation means as described in most of the existing approaches (subsection 2.3.2).
In this context, everything used for modeling various WSMO elements and the data being exchanged is semantically described by using ontologies. As a consequence, the first requirement that comes up for data mediation is that it has to make use of the ontological description for solving data heterogeneity problems. That is, the data mediation level has to resolve the existing mismatches between different conceptualizations used in describing a particular domain, in other words to perform what is called ontology mediation.
The very next requirement comes directly from [Roman et al., 2005] which mentions that the mediators have to allow for loose coupling between services, goals and ontologies. By this, we can conclude that from the three forms of ontology integrations identified in [Ding et al., 2002] (ontology merging, ontology alignment and ontology relating) only ontology alignment and ontology relating are of interest for us in this context. Ontology merging implies that a new ontology is created based on the existing ones and in all future processing only the new ontologies is to be used. Obviously this contradicts the above presented requirement. On the other hand, ontology alignment and ontology relating bring the ontologies into a mutual agreement and show how they are related. The main difference between these two approaches is that in the first case at least one of the input ontologies is subject of changes and adaptations while in the second case the input ontologies are kept intact and additional axioms are required to describe the relations between them. As a consequence, another requirement we impose to the data level mediator is to be able to perform ontology integration by keeping the input ontologies intact (if it is possible) or by adjusting one or more from the input ontology. In other words, we envision two usage scenarios for data mediation: the first one is to make available the set of axioms (we will call them mapping rules from now on) relating the ontologies to be picked by the used reasoning service and the second one, to provide the result of evaluating the mapping rules on a set of input data (e.g. ontology instances, queries) directly, using its own reasoning service (e.g. instance transformation, query rewriting).
Summarizing the requirements presented in the above paragraphs, the data level mediation should offer one of the following pieces of functionality:
Additionally the data mediation level can take care of resolving pure syntactical transformations to/from various ontology representation languages to WSML. By this, another requirement we can derive is:
It is worth noting that not all the above requirements are mandatory - depending on what requirements are fulfilled by a particular mediation service, different WSMO mediators can be created having a particular mediation service as an underlying technological solution.
The most common approach towards data mediation in the context of Semantic Web and Semantic Web Services is ontology mapping. As data is described in terms of ontologies, mappings are created between these ontologies and applied on data in various mediation scenarios. As described in [Mocan and Cimpian, 2005] this involves a design time process consisting of a set of semi-automatic mechanisms and interaction with the domain expert, which has as output a set of mappings between ontologies. In other works ([Doan et al., 2002], [Euzenat et al., 2004]) these mappings (also called alignments) are generated automatically but in general for these approaches the degree of accuracy cannot be guaranteed. The language used to represent the mappings is usually influenced by the language used to represent the ontologies that have to be mapped. In [Mocan and Cimpian, 2005] the abstract mapping language proposed in [de Bruijn et al., 2004b] is used (the EBNF grammar of this abstract mapping language can be found in Appendix A). As the mapping language is an abstract one, it needs to be grounded to a concrete language, to associate a formal semantics to the mappings and basically to make them usable by existing reasoners for that particular concrete language. Such grounding mechanism are provided by [Mocan and Cimpian, 2005] to Flora-2 (see http://flora.sourceforge.net) or by [Predoiu et al, 2004] to WSML-Flight.
The second stage of the mediation process implies the usage of the design-time created mappings or alignments in different mediation scenarios as instance transformation, query rewriting, instance unification etc. This is a completely automatic, run-time process that can be wrapped in a Web service to obtain what we call in this document the mediation service. The scope of the ooMediators is to describe in WSMO terms, the functionality of this service.
A special case of Ontology Mediation is consider the transformation of an ontology from one representation language to another. In this case the mappings are created at the meta-level of the two languages and applied in run-time processes to effectively transform a given ontology from one language to another. In [de Bruijn et al., 2005] a set of transformation functions are provided to map WSML-Core to OWL-DL and other way around. If wrapping the implementation of these transformation functions in a Web service, a syntactic ooMediator can be used to describe in WSMO terms its functionality. We call these mediator a syntactic ooMediator because even if the mappings at the meta-level capture the semantic relationships between the two languages, the transformations operated on the ontologies themselves are only syntactical transformations.
This section addresses the usage, definition, and mediation techniques of GG Mediators in more detail. We first outline the functional purpose of GG Mediators and provide their definition as WSMO elements. Then, we expose Δ-relations that explicitly specify the logical relationships between source and target components of a mediator and provide the basis for a new mediation technique.
The purpose of GG Mediators is to connect Goals and provide additional information on the relationships between them in order to enable more sophisticated management of Goals. Apart from resolving possible data level mismatches, the central mediation technique is so-called Δ-relations that define the explicit logical relationship between Goals. In particular, a Δ-relation denotes the difference between the functionality requested in related Goals, wherefore we discuss the definition and properties below in detail.
Beneficial usage scenarios of GG Mediators are:
Goal Specification by Refinement
Consider a goal G1 that defines the objective buy
product, and another goal G2 buy ticket whereby
ticket is sub-class of product in the used domain
ontology. Imagine that G1 already exists, and some user wants to
define G2. As G2 is a semantic refinement of G1
(means: both goals have the same structure, but the scope of G2 is
narrower than the one of G1), we can use a ggMediator
GGMG1, G2 that contains
ΔG1, G2 for automatically deriving the
specification of G2 as it holds that G2 = G1 ^
ΔG1, G2.
This follows the concept of problem specification by refinement which is the main purpose and motivation for Problem-Solving Methods [Fensel, 2000] for goal creation and creation of goal ontologies as collections of explicitly interlinked goals.
Goal Adjustment by Strengthening and Weakening
The second usage scenario refers to if a client specifies a goal that can
not be resolved by any existing Web service, but similar goals that can be
resolved. Imagine in the example setting that we have a Web service
WS select best French restaurant, with French
restaurant being a sub-class of restaurant in the used
domain ontology. Imagine a Goal G select best
restaurant. WS is not directly usable for solving G,
but it is providing a sub functionality. Weakening the goal towards not
requesting the best restaurants of all restaurants but only French or
alternatively assuming that the best restaurant must be a French anyway would
bridge the gap. A delta relation Δ should be a minimal description of
this gap, i.e., best restaurant -> French restaurant would be
such a delta (assuming there are no restaurants all would also close he gap,
however, not in a minimal way). This usage scenario complies with the concept
of weakening and strengthening that is realized by Refiners as
top-level elements in the UMPL framework for describing Problem Solving
Methods [Fensel et al. 2003] that allows to make
resources applicable for a broader range of problems.
Goal Ontologies for Efficient Management of WSMO Elements
A third functional purpose of usage Δ-relations in GG Mediators is
defining goal-ontologies as collections of goals semantically connected via
GG Mediators. Imagine that from previous runs of a Web Service discovery
engine, we have determined a set of Web Services
SG1 = {WS1, WS2, ..., WSn} that are
applicable for resolving goal G1. Because G2 is a proper
semantic refinement of G1, we know that the set of applicable Web
Service for resolving G2 can only be equal or a subset of those
applicable for G1, i.e: SG2 ⊆
SG1. By having defined ΔG1,
G2 in a ggMediator with G1 as the source and
G2 as the target, we can omit invocation of a discoverer for
determining SG2 as it holds that those Web
Services are applicable for resolving goal G2 that are in
SG1 and satisfy ΔG1,
G2, so that WS ∈ SG2 ← WS ∈
SG1 ∧ match(WS, ΔG1,
G2). Assuming that most probably the invocation of a
discoverer is more expensive than this rule, we can utilize Δ-relations
in mediators to reduce the number of expensive operations in order to make
Semantic Web Service technologies for discovery, selection, and composition
more effective. Thereby, Δ-relations provide additional knowledge that
can be used for minimizing the number of elements that need to be inspected
in expensive operations. Following the approach of additional constraints for
gaining efficiency on the reasoning process for automated problem solving as
presented in [Fensel and Straatman, 1998], this
allows efficient management of WSMO elements as further described in [Stollberg et al., 2005].
With respect to the above examinations, the following listing provides the complete definition of GG Mediators with further explanation of the description elements below.
Class ggMediator sub-Class mediator
hasNonFunctionalProperties type nonFunctionalProperties
|
While we discuss the definition of usage of Δ-relations as a mediation technique below, the following illustrates modeling of GG Mediators and Δ-relations between the source and target goals.
Let's consider the following goals: G0 for buying a product (i.e. receiving a contract of purchase for some product), and G1 for buying a ticket between two locations whereby ticket is a special type of product and thus defined as a sub-concept in the respective domain ontology. Obviously, G0 and G1 are correlated to each other. Hence, we can define a GG Mediator that link the goals and explicitly denote the logical relationship between them in a Δ-relation.
The following listings provide the element listings for the example, i.e. the goals and GG Mediators in WSML [de Bruijn et al., 2005]. For simplicity reasons, we assume that all elements of the example use the same ontology; in case they use different ontologies, potentially occurring data level heterogeneities are handled by usage of appropriate OO Mediators in the GG Mediators. Listing 9 gives the ontology used as the terminology definition in this use case (this is not a well-engineered ontology, but a simplification that satisfies the needs for academic showcasing).
namespace{ _"http://www.wsmo.org/ontologies/ggOntologyExample#",
dc _"http://purl.org/dc/elements/1.1#"}
ontology _"http://www.wsmo.org/ontologies/ggOntologyExample"
nonFunctionalProperties
dc#description hasValue "ontology snippet for exemplification"
endNonFunctionalProperties
concept person
nonFunctionalProperties
dc#description hasValue "concept of a person"
endNonFunctionalProperties
name ofType _string
requestId ofType _integer
concept city
nonFunctionalProperties
dc#description hasValue "concept of a city"
endNonFunctionalProperties
name ofType _string
code ofType _integer
concept route
nonFunctionalProperties
dc#description hasValue "route between two locations"
endNonFunctionalProperties
startLocation ofType city
destinationLocation ofType city
|
The following listings provide the specification of the goals in the example as described above in natural language.
namespace {_"http://www.wsmo.org/ontologies/G0#", wgOnt _"http://www.wsmo.org/ontologies/ggOntologyExample#"} goal _"http://www.wsmo.org/ontologies/G0" nonFunctionalProperties dc#description hasValue "goal of buying a product" endNonFunctionalProperties importsOntology _"http://www.wsmo.org/ontologies/ggOntologyExample.wsml" capability sharedVariables {?client, ?product} precondition nonFunctionalProperties dc#description hasValue "information abou the buyer and the product to be purchased are given" endNonFunctionalProperties definedBy ?client memberOf ggOnt#person and ?product memberOf ggOnt#product. postcondition nonFunctionalProperties dc#description hasValue "a contract for the product is generated" endNonFunctionalProperties definedBy ?contract [buyer hasValue ?client, seller hasValue ?seller, product hasValue ?product] memberOf ggOnt#contract . interface choreography _"http://www.wsmo.org/ontologies/G1Choreography" |
namespace {_"http://www.wsmo.org/ontologies/G1#", wgOnt _"http://www.wsmo.org/ontologies/ggOntologyExample#"} goal _"http://www.wsmo.org/ontologies/G1" nonFunctionalProperties dc#description hasValue "goal of buying a ticket" endNonFunctionalProperties importsOntology _"http://www.wsmo.org/ontologies/ggOntologyExample.wsml" capability sharedVariables {?client, ?route} precondition nonFunctionalProperties dc#description hasValue "information about the client and the route are given" endNonFunctionalProperties definedBy ?client memberOf ggOnt#person and ?route memberOf ggOnt#route . postcondition nonFunctionalProperties dc#description hasValue "a contract for the ticket is to be provided" endNonFunctionalProperties definedBy ?ticket memberOf ggOnt#ticket and ?ticket[forRoute hasValue ?route] and ?ticketContract memberOf ggOnt#contract and ?ticketContract[buyer hasValue ?client, seller hasValue ?seller, product hasValue ?ticket] . interface choreography _"http://www.wsmo.org/ontologies/G1Choreography" |
The GG Mediator ggMG0,G1 defined below connects G0 and G1, including a Δ-relation that denotes the logical difference between them. The difference between G0 and G1 is that the former specifies any kind of product while the latter requests a ticket as a special kind of product, so that intuitively the Δ-relation denotes "all products that are not tickets". The next section explain the definition, computation, and usage of Δ-relations in detail.
namespace {_"http://www.wsmo.org/ontologies/ggm1#", ggOnt _"http://www.wsmo.org/ontologies/ggOntologyExample#"} ggMediator _"http://www.wsmo.org/ontologies/ggm1" nonFunctionalProperties dc#description hasValue "GG mediator between G1 and G2" endNonFunctionalProperties importsOntology _"http://www.wsmo.org/ontologies/ggOntologyExample.wsml" source _"http://www.wsmo.org/ontologies/G1" target _"http://www.wsmo.org/ontologies/G2" ΔRelation nonFunctionalProperties dc#type hasValue "refinement" |
The mediation techniques required for GG Mediators are data level mediation for resolving terminological mismatches between the source and target Goals, and Δ relation mediation for defining and handling logical relations between the source and source and target Goals explicitly. While OO Mediators as described in Section 2 are used for the former, the latter is a new type of mediation technique that we expose in the following in more detail
WSMO defines a Goal to represent the objective that some client wants to achieve by using Web services. Currently, WSMO Goal descriptions consist of a requestedCapability that specifies the functionality a client expects from a Web service in order to solve the objective, and a requestedInterface that is intended to define how the client wants to interact with a Web service [Roman et al., 2005]. The former can also be understood as the client's objective specification, while the latter defines the possible behavior of a Goal for consuming a Web service via its choreography interface. In order to attain additional information on the relationship of Goals with respect to the client's objective, the primary aspect of interest is the relationship between the requestedCapability descriptions of Goals. The relationship between requestedInterface descriptions of Goals is omitted at this point in time (also with respect to that this notion possibly will be refined in future versions of WSMO Goal definitions).
The relationship between client's objective specification of Goals that we are interested in coincides with the logical relationship between the requestedCapability descriptions of Goals. For clarification let's consider the following example. Consider two Goals: G1 defines "buy product", and the target Goal G2 defines "buy ticket", whereby "ticket" is sub-concept of "product" in the used domain ontology. The requestedCapability descriptions of G1 and G2 have the same structure; the difference is that G2 restricts the object to be purchased to tickets as a subset of products. We can define this relationship as the explicit logical difference between the capability descriptions of G1 and G2. This is what we refer to as a Δ-relation whose definition and properties we discuss below in detail. A GG Mediator then connects G1 and G2 including the Δ-relation between them, so that we obtain an element that precisely denotes the logical relationship between goals.
The mediation technique of Δ-relations can also be used beneficially within WG and WW Mediators. In the former, Δ-relations can be defined for explicitly defining the logical differences between capability descriptions of Goals and Web Services, and in the latter as the difference between capabilities of Web Services. In case that the same elements are connected by GG, WG, and WW Mediators, certain relationships hold between the Δ-relations in the mediators. Referring to the above example, consider a Web service WS1 for purchasing train tickets as a sub-class of 'tickets' in the used domain ontology. Given G1 and WS1, the Δ-relation in a respective WG Mediator specifies "all products that are not train tickets" as the explicit logical difference between G1 and WS1. Having also given the Δ-relation between G1 and G2 as "all products that are not tickets", we can determine the Δ-relation between G2 and WS1 on basis of the known Δ-relations between G1, G2, and G1, WS1 - we discuss this in more detail below.
It is to remark that mediation by Δ-relations is different from data and process level mediation. While the latter are concerned with techniques for establishing interoperability if this is not given a priori by resolving mismatches, mediation with Δ-relations is concerned with improving the efficiency of Semantic Web service technologies. The elements that are connected via mediators in an goal or element ontology can reside in a functional manner without the additional teleological information. However, efficiency of core technologies for handling Semantic Web services is a crucial issue with respect to large-scale, industrial strength applicability. As mediation with Δ-relations can significantly improve efficiency, we consider this to be a beneficial mediation technique for Semantic Web services.
As additional information for enabling efficient resource management, a Δ-relation specifies the explicit logical relationship between the functional descriptions of correlated resources. By functional descriptions we refer to black box descriptions of the functionality provided by a Web service or the one requested by a service requests, i.e. capabilities of Web Services or Goals in WSMO. In order to attain the desired information for beneficial resource management techniques, we understand a Δ-relation to describe additional information for establishing logical equivalence between functional resource descriptions that have some commonality but are not equivalent.
That is, it should hold for a Δ-relation between two formal capability descriptions X and Y:
not X |- Y Δ, X |- Y Δ', X |- Y andΔ |- Δ’Alternatively, this can be formalized through the following implications:
Such delta can be found through inverse verification (cf. [Fensel and Schönegge, 1998]), i.e., one tries to proof X |- Y and the gaps in the proof indicate candidates for such deltas.