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 resource 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 through 5 specify the distinct types of Mediators in detail, and Section 6 summerizes and 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 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 of 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, here we briefly examine work related to general 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 1990s. 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 the 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 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 was presented in the MedMaker project in the mid-1990s [Papakonstantinou et al., 1996]. The approach is based on a proprietary, non-ontology-based description language for resources called the Object Exchange Model (OEM), and a Mediator Specification Language (MSL), which are both 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 these basic patterns. However, all these basic patterns and their combinations/refinements are defined using hard-coded Abstract State Machines [Borger, 1998] and predefined predicates, resulting in an inflexible, rigid model. In our approach, we would like to be more flexible by allowing easy 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.
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 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 specify the definition of each of its constituents presented in [Roman et al., 2005]. In doing so, 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 to by the above non-functional property can be thoroughly described 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.
The source of an ooMediator can be 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:
| namespace {_"http://example.org/ooMediators#" , dc _"http://purl.org/dc/elements/1.1#"} 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 rule, 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 the component using the ooMediator in both a heterogeneity-free and consistent way . By going around the ooMediator and directly referring to 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:
| namespace {_"http://example.org/ooMediators#" , dc _"http://purl.org/dc/elements/1.1#"} 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 our 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.
| namespace {_"http://example.org/ooMediators#" , dc _"http://purl.org/dc/elements/1.1#"} 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.
| namespace {_"http://example.org/ooMediators#" , dc _"http://purl.org/dc/elements/1.1#"} 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 to 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. Although, 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: the location ontology and the addresses ontology and vice versa. 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 _"http://www.wsmx.org/webservices/DataMediator/capability" assumption postcondition |
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 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 researched 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 set the requirements such a mediator has to meet (subsection 2.3.1) in order to suit 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 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 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 is 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 to 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 outputs 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 the degree of accuracy for these approaches 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 cal 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 to 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 the implementation of these transformation functions is wrapped 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 called Δ-relations which defines 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
(meaning 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 using 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 when a client specifies a Goal that
cannot 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 French would anyway
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 the 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] which allows the application of
resources applicable to a broader range of problems.
Goal Ontologies for Efficient Management of WSMO Elements
A third functional purpose of Δ-relations usage 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
Services for resolving G2 can only be equal to 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 the invocation of a discoverer is most
likely 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 links 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#", ggOnt _"http://www.wsmo.org/ontologies/ggOntologyExample#", dc _"http://purl.org/dc/elements/1.1#"} 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 _"http://www.wsmo.org/ontologies/G0-capability" sharedVariables {?client, ?product} precondition nonFunctionalProperties dc#description hasValue "information about 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 . |
namespace {_"http://www.wsmo.org/ontologies/G1#", ggOnt _"http://www.wsmo.org/ontologies/ggOntologyExample#", dc _"http://purl.org/dc/elements/1.1#"} 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 _"http://www.wsmo.org/ontologies/G1-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] . |
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 explains the definition, computation, and usage of Δ-relations in detail.
namespace {_"http://www.wsmo.org/ontologies/ggm1#", ggOnt _"http://www.wsmo.org/ontologies/ggOntologyExample#", dc _"http://purl.org/dc/elements/1.1#"} 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" deltaRelation nonFunctionalProperties dc#type hasValue "source (G1) subsumes target (G2)" |
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 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 about 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 ( this notion will most likely 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 the 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 prove X |- Y and the gaps in the proof indicate candidates for such deltas.
A WSMO wgMediator explicitly states the relation between a Web Service and a Goal and resolves the possible mismatches between them. These mismatches may appear between the requested and the provided capabilities, as well as between the requested and provided choreographies. Considering the levels of mediation described in the beginning of this deliverable, the capabilities mismatches can be addressed using data mediation techniques (by means of an ooMediator), while the choreographies mismatches can be address only by combining both data and process level mediation technologies (using an ooMediator for data heterogeneity, a ggMediator for expressing the logical relationships, and process mediation for solving the communication mismatches).
In this section we first describe the usage of wgMediators, continuing with their definition as WSMO elements and the possible mediation techniques related to wgMediators.
Depending on which are the source and target of the mediator the wgMediator may serve two different purposes:
For this, the wgMediators have the following functionalities:
The following listing provides the wgMediator’s definition
Class wgMediator sub-Class mediator hasNonFunctionalProperties type nonFunctionalProperties importsOntology type ontology hasSource type {webService, Goal, wgMediator, ggMediator} hasTarget type {webService, Goal, ggMediator, wgMediator} usesMediator type {ooMediator, ggMediator} hasΔRelationDefinition type axiom hasMediationService type {webService} |
The mediation techniques for WG Mediators are first data mediation by usage of OO Mediators, Δ relation mediation for expressing the logical relationship between the source and target elements, and communication mediation for resolving mismatches between the Choreography Interface definitions of the source and target components.
The data level mediation and the Δ relation mediation are described in the previous chapters of this deliverable and they will not be further addressed in this section. This section describes the communication level mediation between the two participants.
We consider the communication mediation as being that level of mediation which is solving the heterogeneity problem from the communication point of view. A Communication Mediator should be able to both analyze the public processes of the two communication partners (as declared in their interfaces), and determine how these two partners can actually communicate. Since it is dealing with public processes heterogeneity, the communication mediator is also called process mediator in WSMX.
[Fensel and Bussler, 2002] identifies three possible cases that may appear during the message exchange:
[Cimpian and Mocan, 2005] propose an architecture and an algorithm for a Process Mediation prototype able to solve a number of resolvable message mismatches:
Since the architecture and implementation of this prototype are out of the scope of this document, no details are presented here, but only an example for illustrating the types of mismatches addressed by this prototype.
The runtime process mediation is based on the following assumption: since the Goal contains the requested interface which is the interface of the service it wants to invoke, a different component (or a subcomponent of the process mediator) will have to inverse this requestedInterface in order to obtain the actual interface of the Goal. That is, if in the choreography requested by the Goal, the out list contains the concept x, this actually means that the service will have to send to the Goal instances of this concept. In the Goal’s choreography that will be sent to the process mediator, concept x will be part of the in list, not of the out list. This is needed in order to treat both the requestor and the provider of the service as equal partners, disregarding the fact that one of them is the client and the other one the service.
Additionally, we assume that the two choreographies are correctly modelled, the process mediation not being able to compensate for the incorrect or insufficient information (for example the Goal’s choreography cannot state that a name, that is a string, has to be sent; instead, the person or the city with that certain name will be sent).
In order to illustrate the functionality of the process mediator, we will define a part of the choreography of a Web Service offering travel tickets between two locations and accommodation in the destination city, and a part of the inversed choreography of G3 (the description of the entire choreographies of both the requestor and the provider would complicate the example too much).
namespace {_"http://www.wsmo.org/ontologies/G3#",
ggOnt _"http://www.wsmo.org/ontologies/ggOntologyExample#",
dc _"http://purl.org/dc/elements/1.1#"}
Goal _"http://www.wsmo.org/ontologies/G3"
nonFunctionalProperties
dc#description hasValue "Goal of buying a ticket and finding accommodation"
endNonFunctionalProperties
capability _"http://www.wsmo.org/ontologies/G3Capability"
interface G3Interface
choreography G3Choreography
stateSignature
importsOntology _"http://www.wsmo.org/ontologies/ggOntologyExample"
in ggOnt#contract withGrounding _""
out
ggOnt#person withGrounding _""
ggOnt#route withGrounding _""
ggOntology#completed withGrounding _""
transitionRules
/*
* a route is created and sent only after a person has a request
*/
forall ?person with (?person[
requestId hasValue ?requestId
] memberOf ggOnt#person)
do
add(?route[
requestId hasValue ?requestId
] memberOf ggOnt#route)
endForall
/*
* expect contract after route exists
*/
forall ?contract with (?contract[
product hasValue ?route,
buyer hasValue ?person
] memberOf ggOnt#contract)
do
add(?completed[
requestId hasValue ?requestId
] memberOf completed)
endForall
|
namespace {_"http://www.wsmo.org/ontologies/WebService#",
ggOnt _"http://www.wsmo.org/ontologies/ggOntologyExample#",
dc _"http://purl.org/dc/elements/1.1#"}
webService _"http://www.wsmo.org/ontologies/WebService"
nonFunctionalProperties
dc#description hasValue "Web Service offering a ticket and finding accommodation"
endNonFunctionalProperties
capability _"http://www.wsmo.org/ontologies/WSCapability"
interface TicketsAndHotelsInterface
choreography TicketsAndHotelsChoreography
stateSignature
importsOntology _"http://www.wsmo.org/ontologies/ggOntologyExample"
in
ggOnt#route withGrounding _""
ggOnt#person withGrounding _""
out
ggOnt#contract withGrounding _""
ggOntology#confirmation withGrounding _""
transitionRules
/*
* when route is received, create an instance of confirmation
*/
forall ?route with (?route[
requestId hasValue ?requestId
] memberOf ggOnt#route)
do
add(?confirnation[
forRoute hasValue ?route
] memberOf confirmation)
endForall
/*
* when person is received, having the same requestId, the contract is sent
*/
forall ?person with (?person[
requestId hasValue ?requestId
] memberOf ggOnt#person)
do
add(?contract[
product hasValue ?route,
buyer hasValue ?person,
seller hasValue "http://www.wsmo.org/ontologies/TicketsAndHotels#"
] memberOf ggOnt#contract)
endForall
|
A graphical representation of the messages exchanged between the two parties is illustrated in the following figure:
Figure 2. Web Service - G3 interaction
In this case, the Process Mediator will have to:
Details about how the process mediator will perform all these tasks can be found in WSMX deliverable D13.7 ([Cimpian and Mocan, 2005]).
The forth type of WSMO mediators, the WWMediators, have the task of solving heterogeneity problems between Web Services. This heterogeneity may occur when a Web Service needs to combine (invoke) multiple Web Services in order to achieve its capability. A WWMediator operates between the Orchestration of this Web Service and the choreographies of the invoked Web Services.
Since the WSMO orchestration is not yet completely defined, the WWMediators are going to be addressed in future versions of this deliverable.
This document presented a refinement of the Mediator, one of the four top level elements of the Web Service Modeling Ontology (WSMO). The four types of mediators presented here ooMediator, wwMediator, wgMediator and ggMediator, are used to cope with the heterogeneity problems that potentially arise at different levels. We gave a definition and indication of usage for these mediators to which a reference implementation may be found in the Web Service Modeling Execution Environment WSMX [WSMX].
[Altenhofen et al., 2005]
Altenhofen, M.; Börger, E.; Lemcke, J.: An Execution Semantics for
Mediation Patterns. In Proceedings of the WIW 2005 Workshop on
WSMO Implementations, Innsbruck, Austria, 2005; available at CEUR Workshop
Proceedings Vol 134 (http://sunsite.informatik.rwth-aachen.de/Publications/CEUR-WS//Vol-134/).
[Barros and Borger, 2005] A. Barros and E. Börger: A Compositional Framework for Service Interaction Patterns and Interaction Flows, available at http://sky.fit.qut.edu.au/~dumas/ServiceInteractionPatterns/InteractionPatternsFormalisation.pdf.
[Benjamins et al., 1996] Benjamin, V. R.; Fensel, D.; Straatman, R: Assumptions of Problem-Solving Methods and their Role in Knowledge Engineering. In Proc. of the ECAI 1996, pp. 408-412, John Wiley and Sons, 1996.
[Börger, 1998] Egon Börger: "High Level System Design and Analysis Using Abstract State Machines", Proceedings of the International Workshop on Current Trends in Applied Formal Method: Applied Formal Methods, p.1-43, October 07-09, 1998
[BPT, 2003] Business process Trends, Glossary, available at http://www.bptrends.com/resources_glossary.cfm, 2003
[Cimpian and Mocan, 2005] E. Cimpian and A. Mocan: Process Mediation in WSMX. WSMX Working Draft v0.1. available at http://www.wsmo.org/TR/d13/d13.7/v0.1
[de Bruijn et al., 2004]Jos de Bruijn and Francisco Martin-Recuerda and Dimitar Manov and Marc Ehrig : State-of-the-art Survey on Ontology Merging and Aligning V1. Technical Report, SEKT project deliverable D4.2.1
[de Bruijn et al., 2004b] J. de Bruijn, Douglas Foxvog, Kerstin Zimmerman: Ontology mediation patterns library v1. Technical Report, SEKT project deliverable D4.3.1, 2004.
[de Bruijn et al., 2005] J. de Bruijn (ed.): The Web Service Modeling Language WSML. WSML Final Working Draft v0.2, 20 March 2005, available at http://www.wsmo.org/TR/d16/d16.1/v0.2/
[Ding et al., 2002] Ying Ding, Dieter Fensel, Michel C. A. Klein, and Borys Omelayenko. The semantic web: yet another hip? Data Knowledge Engineering, 41(2- 3):205–227, 2002.
[Doan et al., 2002] A. Doan, J. Madhavan, P. Domingos, A. Halevy: Learning to Map Between Ontologies on the Semantic Web. In WWW2002, 2002.
[Euzenat et al., 2004] J. Euzenat, D. Loup, M. Touzani, P. Valtchev: Ontology alignment with OLA. In Proc. 3rd ISWC2004 workshop on Evaluation of Ontology-based tools (EON), Hiroshima, Japan, pp59-68, 2004
[Feier et al., 2005] Feier, C.; Roman, D.; Polleres, A.; Domingue, J.; Stollberg, M. and Fensel, D.: Towards Intelligent web Services: Web Service Modeling Ontology (WSMO). In Proceedings of the International Conference on Intelligent Computing (ICIC) 2005, Hefei, China, August 23-26, 2005.
[Fensel, 2000] D. Fensel: Problem-Solving Methods: Understanding, Development, Description, and Reuse. Lecture Notes on Artificial Intelligence, no 1791, Springer-Verlag, Berlin, 2000.
[Fensel and Bussler, 2002] D. Fensel and C. Bussler: The Web Service Modeling Framework WSMF, In Electronic Commerce Research and Applications, 1(2), 2002.
[Fensel et al. 2003] Fensel, D. et al.: The Unified Problem Solving Method Development Language UPML. In Knowledge and Information Systems Journal (KAIS) 5(1), 2003.
[Fensel and Straatman, 1998] Fensel, D. and Straatman, R.: The Essence of Problem-Solving Methods: Making Assumptions to Gain Efficiency International Journal of Human-Computer Studies 48(2): 181-215, 1998.
[Fensel and Schönegge, 1998] Fensel, D. and Schönegge, A.: Inverse Verification of Problem-Solving Methods. International Journal of Human-Computer Studies (IJHCS), 49(4):339-362, 1998.
[Kalfoglou et al., 2003] Yannis Kalfoglou and Marco Schorlemmer : Ontology Mapping: the State of the Art, Knowledge Engineering Review, volume 18, p 1-31
[Keller et al., 2004] U. Keller, R. Lara, A. Polleres, I. Toma, M. Kifer and D. Fensel: WSMO Web Service Discovery, WSMO deliverable D5.1 v0.1 available at http://www.wsmo.org/2004/d5/d5.1/v0.1/20041112/d5.1v0.1_20041112.pdf.
[Kiryakov et al., 2005] A. Kiryakov, C. Drumm, L. Al-Jadir, A. Boukottaya, E. Kilgarriff, J. Quantz : D5.2 Mediation Module Specification: Buisness Data-Level Mediation - Dip project deliverable
[Kiryakov et al., 2005b] A. Kiryakov (Edt), Stoyan Atanassov, Dimitar Manov : Ontology Mapping Store : http://www.omwg.org/tools/omapstore/v0.1/FactSheet.html
[Lausen, 2005] Lausen, H. (ed.): Functional Description of Web Services. WSML Working Draft D28.1, 2005-10-20; most recent version available at: http://www.wsmo.org/TR/d28/d28.1/v0.1/.
[Li and Horrocks, 2003] Lei Li and Ian Horrocks. A software framework for matchmaking based on semantic web technology, 2003.
[Mocan and Cimpian, 2005] A. Mocan and E. Cimpian: WSMX Data Mediation.WSMX Working Draft v0.2.available at http://www.wsmo.org/TR/d13/d13.3/v0.2/
[Papakonstantinou et al., 1996] Papakonstantinou, Y; Garcia-Molina, H.; Ullman, J. D.: MedMaker: A Mediation System Based on Declarative Specifications. In Proceedings of the Twelfth International Conference on Data Engineering, 1966, pp 132 - 141.
[Predoiu et al, 2004] Livia Predoiu, Francisco Martin-Recuerda, Axel Polleres, Cristina Feier, Fabio Porto, Jos de Bruijn, Adrian Mocan and Kerstin Zimmermann. Framework for representing ontology networks with mappings that deal with conflicting and complementary concept definitions. Deliverable D1.5, DIP, 2004. Available at http://dip.semanticweb.org/.
[Roman et al., 2005] D. Roman, U. Keller, H. Lausen (eds.): Web Service Modeling Ontology, WSMO Final Draft, version 1.2 available at http://www.wsmo.org/TR/d2/v1.2/
[Scicluna et al., 2005] J. Scicluna, A. Polleres, D. Roman, C. Feier (eds.): Ontology-based Choreography and Orchestration of WSMO Services, WSMO deliverable D14 v0.1. available at http://www.wsmo.org/TR/d14/v0.2/, 2005.
[Stollberg et al., 2004] M. Stollberg, U. Keller, A. Mocan : On WSMO Mediators - WSMO internal study.
[Stollberg et al, 2005] Stollberg, M.; Cimpian, E.; Fensel, D,Mediating Capabilities with Delta-Relations.. Submitted to the First International Workshop on Mediation in Semantic Web Services, co-located with the Third International Conference on Service Oriented Computing (ICSOC 2005), Amsterdam, the Netherlands, December 2005.
[Wiederhold, 1994] Wiederhold, G.: Mediators in the architecture of the future information systems Computer 25(3), 1994, pp. 38-49.
This Appendix contains the Abstract Syntax of the mapping language developed in [de Bruijn et al., 2004b] and it is a direct copy of the corresponding appendix in the indicated document in order to provide an insight to the reader reversing the possible mapping language that can be used by the mediation services.
The abstract syntax is written in the form of EBNF, similar to the OWL Abstract Syntax. Any element between square brackets ‘[’ and ‘]’ is optional. Any element between curly brackets ‘{’ and ‘}’ can have multiple occurrences.
Each element of an ontology on the Semantic Web, whether it is a class, attribute, instance, or relation, is identified using a URI. In the abstract syntax, a URI is denoted with the name URIReference. We define the following identifiers:
mappingDocumentId ::= URIReference ontologyId::= URIReference classId::= URIReference propertyId::= URIReference attributeId::= URIReference relationId::= URIReference individualId::= URIReference |
We allow concrete data values. The abstract syntax for data values is taken from the OWL abstract syntax:
dataLiteral ::= typedLiteral|plainLiteral |
The lexical form is a sequence of unicode characters in normal form C, as in RDF. The language tag is an XML language tag, as in RDF.
First of all, the mapping itself is declared, along with the ontologies participating in the mapping.
mapping ::= ’Mapping(’ [ mappingId ] |
A mapping consists of a number of annotations, corresponding to non-functional properties in WSMO [Roman et al., 2005], and a number of mapping rules. The creator of the mapping is advised to include a version identifier in the non-functional properties.
directive ::= annotation |expression |
Expressions are either class mappings, relation mappings, instance mappings or arbitrary logical expressions. The syntax for the logical expressions is not specified; it depends on the actual logical language to which the language is grounded.
A special kind of relation mappings are attribute mappings. Attributes are binary relations with a defined domain and are thus associated with a particular class. In the mapping itself the attribute can be either associated with the domain defined in the (source or target) ontology or with a subclass of this domain.
A mapping can be either uni- or bidirectional. In the case of a class mapping, this corresponds with class equivalence and class subsumption, respectively. In order to distinguish these kinds of mappings, we introduce two different keywords for class, relation and attribute mappings, namely ‘unidirectional’ and ‘bidirectional’. Individual mappings are always bidirectional. Unidirectional and bidirectional mappings are differentiated with the use of a switch. The use of this switch is required.
It is possible, although not required, to nest attribute mappings inside class mappings. Furthermore, it is possible to write an axiom, in the form of a class condition, which defines general conditions over the mapping, possibly involving terms of both source and target ontologies. Notice that this class condition is a general precondition for the mapping and thus is applied in both directions if the class mapping is a bidirectional mapping. Notice that we allow arbitrary axioms in the form of a logical expression. The form of such a logical expression depends on the logical language being used for the mappings and is thus not further specified here.
expression ::= ’classMapping(’
’unidirectional’|’bidirectional’
{ annotation }
classExpr classExpr
{ attributeMapping }
{ classCondition }
|
There is a distinction between attributes mapping in the context of a class and attributes mapped outside the context of a particular class. Because attributes are defined locally for a specific class, we expect the attribute mappings to occur mostly inside class mappings. The keywords for the mappings are the same. However, attribute mappings outside of the context of a class mappings need to be preceded with the class identifier, followed by a dot ’.’.
attributeMapping ::= ’attributeMapping(’
’unidirectional’|’bidirectional’
attributeExpr attributeExpr
|
expression ::= ’attributeMapping(’
’unidirectional’|’bidirectional’
attributeExpr attributeExpr
|
expression ::= ’relationMapping(’
’unidirectional’|’bidirectional’
|
expression ::= ’instanceMapping(’ individualID individualID ’)’ |
expression ::= ’classAttributeMapping(’
’unidirectional’|’bidirectional’
classExpr attributeExpr
|
expression ::= ’classRelationMapping(’
’unidirectional’|’bidirectional’
classExpr relationExpr
|
expression ::= ’classInstanceMapping(
’unidirectional’|’bidirectional’
classExpr individualId
[ ’{’ logicalExpression ’}’ ] ’)’
|
expression ::= ’{’ logicalExpression ’}’
|
For class expressions we allow basic boolean algebra. This corresponds loosely with Wiederhold’s ontology algebra [37]. Wiederhold included the basic intersection and union, which correspond with our and and or operators. Wiederhold’s difference operator corresponds with a conjunction of two class expressions, where one is negated, i.e. for two class expressions C and D, the different C-D corresponds with and(C,not(D)).
The join expression is a specific kind of disjunction, namely a disjunction with an additional logical expression which contains the precondition for instances to be included in the join.
classExpr ::= classId |
Attribute expressions are defined as such, allowing for inverse, transitive close, symmetric closure and reflexive closure, where inverse(A) stands for the inverse of A, symmetric(A) stands for the symmetric closure of A (notice that the symmetric closure of an attribute is equivalent to the union of the attribute and its inverse: or(A inverse(A))), reflexive(A) stands for the reflexive closure of A (the reflexive closure of an attribute includes for each value in the domain a tuple with equivalent domain and range v: <v, v>) and trans(A) stands for the transitive closure of A:
attributeExpr ::= attributeId |
Relation expressions are defined similar to class expressions:
relationExpr ::= relationId |
classCondition ::= ’attributeValueCondition(’
attributeId
( individualID | dataLiteral )
’)’
classCondition ::= ’attributeTypeCondition(’
attributeID
classExpr
’)’
classCondition ::= ’attributeOccurrenceCondition(’
attributeID
’)’
|
attributeCondition ::= ’valueCondition(’
(individualID
| dataLiteral)
’)’
attributeCondition ::= ’typeCondition(’
classExpression
’)’
|
The work is funded by the European Commission under the projects DIP, Knowledge Web, Ontoweb, SEKT, SWWS, Esperonto, and h-TechSight; by Science Foundation Ireland under the DERI-Lion project; and by the Vienna city government in the projects RW2 and TCP under the FIT-IT programme.
The editors would like to thank to all the members of the WSMO working group for their advice and input to this document.