Information Technology Reference
In-Depth Information
Class goal
hasNonFunctionalProperty type nonFunctionalProperty
importsOntology type ontology
usesMediator type
}
requestsCapability type capability multiplicity = single
{
ooMediator, ggMediator
valued
requestsInterface type interface
Nonfunctional properties. Given the fact that a goal can represent a service
that would potentially satisfy the user's desires, the set of nonfunctional
properties that can be attached to a goal is similar to that attached to
a Web services (see Section 6.2). An extra nonfunctional property can be
attached to a goal, namely type of match , which represents the type of
match desired for a particular goal (under the assumption of set-based
modeling, this can be an exact match, a match where the goal description
is a subset of the Web service description or a match where the Web Service
description is a subset of the goal description). For a detailed discussion,
see Section 9.2.
Imported ontologies. A goal uses imported ontologies as a terminology to
define the other elements that are part of the goal, as long as no conflicts
need to be resolved.
Nonfunctional properties. A goal uses mediators in the following situations.
(1) When heterogeneous terminologies are used, conflicts between them
may arise; in these cases, a service can import ontologies using ontology
mediators ( OO mediators ). (2) When a goal reuses already existing goals,
for example by refining them, GG mediators are used (these are explained
in more detail in Section 6.4).
Requested Capability. The requested capability in the definition of a goal
describes the capability of the services that the user would like to have.
Interface. The interface in the definition of a goal describes the interface
of the service that the user would like to have and interact with.
6.4 Mediators
Mediation is concerned with handling heterogeneity, i.e. resolving possible
mismatches between resources that ought to be interoperable. Heterogeneity
naturally arises in open and distributed environments, and thus in the applica-
tion areas of Semantic Web services, WSMO defines the concept of mediators
as a top-level concept.
Mediator-orientated architectures, as introduced in [135], specify a media-
tor as an entity for establishing interoperability of resources that are not com-
patible prior to resolving mismatches between them at run time. The approach
to mediation that is aspired to relies on declarative description of resources,
whereupon mechanisms for resolving mismatches work on a structural and
semantic level. This allows the defining of generic, domain-independent medi-
ation facilities and the reuse of mediators. Concerning the need for mediation
within Semantic Web services, WSMO identifies three levels of mediation:
Search WWH ::




Custom Search