Giving Meaning to GI Web Service Descriptions

Florian Probst and Michael Lutz

Institute for Geoinformatics, Robert Koch Str. 26-28,

48149 Münster, Germany

Abstract. Composition of web services based on currently available descrip-

tions such as WSDL are error-prone because the meaning (or semantics) of the

labels used in these syntactic descriptions is unclear. We identify three types of

problems that can result from semantically heterogeneous descriptions during

service composition. These problems call for a Semantic Reference System for

semantically annotating symbols, i.e. referencing symbols to concepts and se-

mantically grounding these concepts. We present a three-level architecture for

such a Semantic Reference System and illustrate how it can be used for solving

the problems identified. Our example for illustration purposes is taken from the

domain of disaster management and focuses on the composition of geographic

information services.

1 Introduction

Composability is often seen as one of the main strengths of web services. In the geo-

spatial domain, after focusing mainly on services providing data and maps, the first

(geo) processing services are currently emerging.

To enable meaningful composability of web services not only syntactic descrip-

tions such as WSDL [1] are needed. A further step has to be taken in providing the

user with descriptions telling him what the labels of data types and operations used in

a syntactic service description actually mean. This calls for a Semantic Reference

System [2] allowing for semantic annotation of symbols, referencing of symbols to

concepts and semantic grounding of concepts with image schemata (Fig. 1).

Fig. 1. A Semantic Reference System provides (grounded) semantics for standard service de-

scriptions

Probst F. and Lutz M. (2004).

Giving Meaning to GI Web Service Descriptions.

In Proceedings of the 2nd International Workshop on Web Services: Modeling, Architecture and Infrastructure, pages 23-35

DOI: 10.5220/0002665700230035

 SciTePress

In this paper we introduce the architecture for a three-level Semantic Reference Sys-

tem consisting of application ontology, domain ontology and semantic grounding

levels. We focus on data types that are used as operation input and output, rather than

on the functionality of the operation. We illustrate the conceptual results with a real

world example. We show that, by evaluating references of service descriptions to a

Semantic Reference System, meaningful interoperability between services can be

ensured during service discovery.

The following short scenario

is used to explain in which context we encountered

and solved semantic problems: A service provider is about to build a composite ser-

vice for the management of accidents involving toxic gas releases from a chemical

plant. He builds the composite service starting with the most specialized service

and

subsequently adding further services until the composite service meets the user’s

requirements. The user already has the central, most specialized service of the com-

posite service available. This is a service for calculating a toxic plume (subsequently

called CalculateGasDispersionService). The first step is to check the input and output

of the plume service. It requires information about the wind speed, the wind direction,

the location of the gas emission and the emission rate as input. The output is a poly-

gon indicating the dispersion of the gas. The user chooses as next step to find an addi-

tional service providing information on the wind direction and therefore searches for

services providing weather information in a UDDI registry [3]. He discovers two

services: the GlobalWeatherService and the AirportWeatherService provided by

CapeScience (http://www.capescience.com). The user now has to determine whether

these services actually match (syntactically and semantically) the requirements of the

CalculateGasDispersionService. The semantic problems he encounters are explained

in the following chapter.

2 Types of Semantic Problems

Currently service discovery relies on the labels of input and output descriptions and

on the labels of data types given in WSDL (or similar service metadata) descriptions.

It is generally assumed that if the labels are the same, the transported information is,

too. However, this is not always the case. Different types of semantic heterogeneity

have been identified for GIS [4] and GI web services in general [5]. In the following,

we present three types of heterogeneity problems that play a role during GI web ser-

vice composition. Each problem type is illustrated by relating it to the scenario given

above (Fig. 2).

This scenario was developed in conjunction with the ACE-GIS e-Emergency composite

service (http://www.acegis.net/).

To keep things simple, we assume that each web service has only one operation. We therefore

use the terms web service and operation interchangeably.

2.1 Problem Type I (Naming Heterogeneity)

The output of a web service and the input of a second web service are represented

with the same data type and refer to the same domain concept, but have different

labels (names).

The AirportWeatherService and the GlobalWeatherService both provide informa-

tion about the wind direction. However, the labels of the data types containing the

required information are different. The GlobalWeatherService refers to the informa-

tion as prevailing_direction while the AirportWeatherService labels the information

as wind. However, both elements represent the same (domain) concept of wind direc-

tion.

This problem can be solved by annotating the elements used in the WSDL descrip-

tions with concepts from an application ontology. The application concepts are al-

ways referenced to (or derived from) more general domain concepts. The reference

includes additional restrictions on the properties of the domain concept, thus con-

straining the meaning of the application concept. If two application concepts refer to

the same domain concept and their restrictions are identical, the meaning of the anno-

tated symbols is the same.

Fig. 2. Types of semantic problems. Restrictions on a domain concept change its meaning

2.2 Problem Type II (Data Type Heterogeneity)

The output of a web service and the input of a second web service have the same

labels (names) and refer to the same domain concept, but are represented with differ-

ent data types.

The example given above is further complicated by a second source of heterogene-

ity. The GlobalWeatherService provides the wind direction information represented

as a complex type labeled Direction. The AirportWeatherService provides this infor-

mation contained in a String. However, both elements represent the same domain

concept

This problem is not simply to be considered syntactical heterogeneity since the

meaning of the information contained in a complex type is not explicit to the user.

When dealing with complex data types, a semantic description of their structure and

content can help in supplying rules for transforming them or for extracting the re-

quired information. How to semantically describe complex types such that these rules

can be generated automatically from the descriptions will be a topic for future re-

search. In our current approach we assume that appropriate parsers are available for

transforming the information into the required data type of the preceding service.

2.3 Problem Type III (Conceptual Heterogeneity)

The output of a web service and the input of a second web service have the same

labels (names), are represented with the same data type, but refer to different domain

concepts.

Consider now the wind information represented as a String provided by the Air-

portWeatherService as described above. And consider further that the CalculateGas-

DispersionService also requires wind information represented as a String. However,

the CalculateGasDispersionService interprets the provided String not as degrees

characterizing the direction the wind is blowing from. Instead it interprets the String

as characterizing the direction the wind is blowing to. This misinterpretation intro-

duces a 180-degree mismatch.

This can lead to the creation of composite services that produce results not in-

tended by the user. This is due to the fact that currently most composite services are

built manually using WSDL-based service descriptions. If inputs and outputs of op-

erations have the same name and data type, the user cannot tell that these operations

refer to different domain concepts. The underlying assumption causing this problem is

that if something is described identically, it must have the same meaning.

By referencing the application level concepts to different domain concepts, or by

using different restrictions on the same domain concepts, it can be prevented that

services whose inputs and outputs do not match (on the conceptual level) are com-

bined in a service chain.

Note that in the example which is taken from existing web services, problem types I and II

occur simultaneously. For clarification, the example problem is split into two problems types.

3 Semantic Reference System

This chapter gives a brief introduction of the three levels of the Semantic Reference

System and how they are related to each other. The application and domain levels

consist of ontologies, i.e. “explicit specifications of a conceptualization” [6]. The

necessity of introducing three levels is explained in the following section, which re-

lates the user’s tasks during service composition to the semantic problems identified

in the previous section. For better comprehension we start with describing the middle

section on the architecture, the Conceptual Level. Fig. 3 gives an overview of the

three-leveled architecture of a Semantic Reference System.

Fig. 3. Three-level Semantic Reference System; left: the levels meet different requirements

3.1 Conceptual Level

The Conceptual Level is the level of human concepts. A domain ontology provides an

agreed-upon conceptualization of a certain part of the world; in our example a small

part of the domain of meteorology. Such a domain ontology will never be complete

since the meteorological knowledge evolves and the terms used change. But it will

serve to describe a particular worldview on this domain and the vocabulary humans

use to communicate about it.

The domain ontology makes a world view explicit and presents it in a machine- in-

terpretable way. It is important to note, that the task of connecting a symbol with a

concept in the human mind, in other words assigning meaning to a symbol, remains

partly with the user. However, the important contribution of a domain ontology is that

the many possible conceptualizations an English speaking user could assign to sym-

bols such as wind are restricted via a set of relations to other symbols and by classify-

ing the symbols in a subsumption hierarchy. In this way, the domain ontology re-

stricts the meaning of a known symbol (term).

Thus, while the domain ontology assigns meaning to a symbol by providing a con-

ceptualization for it, this conceptualization is based on the use of other symbols. The

meaning of these symbols is either given by yet other symbols or by assuming that the

user knows the meaning of these symbols. The latter may work within a small user

community, but for larger communities this assumption will not hold.

3.2 Semantic Grounding Level

To escape the vicious circle of defining concepts with other concepts on an ever

higher level of abstraction or by assuming the user knows the meaning of symbols a

Semantic Grounding Level is required. Semantic grounding is the process of referenc-

ing a concept described on the conceptual level to concepts form which is assumed

that their meaning is common to the user and thus needs no further definition.

We propose image schemata to semantically ground the concepts used on the Do-

main Ontology Level. Image schemas fall between abstract propositional structures

(such as predicates) and concrete images (such as the spatial mental images in [7]).

They are developed through bodily experiences and influence our reasoning through

the recurrence of form and function. They stand in a long tradition of representing

elements of knowledge into patterns or schemas. An image schema can be seen as a

generic and abstract structure that helps people establish a connection between differ-

ent experiences that have this same recurring structure. Therefore, meaning involves

image-schematic structures [8, 9].

After defining the meaning of a symbol via the restrictions posed on it on the Con-

ceptual Level, references to image schemata which are represented using similar

methods as employed for the domain ontologies will further reduce semantic ambigu-

ity. These references will be based on non-taxonomic relations, avoiding the sub-

sumption of domain concepts under image schemata. We intend to restrict the mean-

ing of domain concepts by using the shared and thus common understanding of image

schemata. Image schemata are seen as semantic datum in a Semantic Reference Sys-

tem, in analogy to the datum of spatial reference systems.

3.3 Application Level

On the application level, meaning is assigned to web service descriptions, i.e. the

symbols (labels) used in the WSDL-based service description are captured in an ap-

plication ontology. The method to build an application ontology is similar of such for

building domain ontologies. However, in the domain ontology the meaning for the

general vocabulary of a certain domain is captured. The application ontology now

makes use of the symbols to which meaning is already assigned and connects these to

the semantics-free symbols of the WSDL descriptions.

The reason for introducing an application level is that the domain ontology may

define concepts in a way which is to general for a certain application. Therefore the

application level provides a possibility for further restricting the meaning of domain

ontology concepts. It is also possible to introduce concepts not contained in the do-

main ontology by using non-taxonomic relations to domain ontology concepts. This is

why application ontologies should not be understood as specializations of domain

ontologies as could be inferred from [10; figure 4].

Since meaning is passed from the Groundling Level via the Conceptual Level to

the Application Level consistency issues are to be considered on the Grounding and

Conceptual Level. We argue that domain and grounding ontology provider are re-

sponsible for keeping updates of their ontologies consistent with prior versions. Ex-

tending domain or grounding ontologies with new concepts will cause no problems on

application level. However extending existing concepts with new restrictions or

changing existing restrictions can cause consistency problems on the application

level. Since domain and grounding ontologies are considered to be relatively stable

constructs with only few changes after an initial development phase, comparable to

agreed upon meta data standards. Therefore we consider the three-leveled architecture

as good solution for guaranteeing consistency and at the same time allowing for

evolving semantics over time.

4 Semantic Problem Types Related to User Tasks during Service

Composition

The types of semantic problems identified in the previous section will now be related

to the user’s tasks during service composition in order to explain the need of a three-

level semantic reference system. Each of the levels and the references between them

will be illustrated by providing formal definitions of concepts for the example sce-

nario. The ontologies containing these definitions can be found at http://musil.uni-

muenster.de/onto/.

For enhanced readability these concepts are imported from the different ontologies

(e.g. grounding.owl or domain1.owl) into one ontology. The prefixes of the concepts

(e.g. grounding:) shown indicate from which ontology they are taken (Fig. 4 and 5).

The prefixes, e.g. domain1 can be extended to the full XML namespace.

The ontology language employed is the Web Ontology Language OWL [11]. To

build the ontologies we employed the ontology editor Protégé 2.0 [12] in combination

with an plug-in supporting OWL [13].

Defining the concept of “wind direction”. As starting point of service discovery, the

user needs the possibility to specify his concept of wind direction. This is performed

by querying a domain ontology (for meteorology). In the example, the user will find

the concept WindDirection with all properties relevant in the domain of meteorology

(Fig. 4). The property hasReferenceSystem relates WindDirection to the concept

ReferenceSystem. Its sub-concept DirectionReferenceSystem in turn has the properties

rotation, origin, and unit of measure. Via the concept DirectionReferenceSystem the

user could, for example, specify that the concept of WindDirection he is looking for

takes north as origin, turns clockwise and uses degrees as a unit of measure.

To further decrease the ambiguity of domain ontology concepts, properties using or

based on image schemata are employed. For example, compulsion is identified as an

image schema by [8]. The domain ontology property pointsToCompulsion is therefore

referenced to the grounding level. The possibility of referencing domain ontology

concepts to image schemata decreases the likelihood of ambiguously interpreted do-

main ontology concepts. The (yet incomplete) set of image schemata, their internal

structure and how they can serve as semantic grounding level need further investiga-

tion. However, the possibility to break the vicious circle of defining concepts with

other (undefined) concepts is appealing.

Fig. 4. Definition of the domain ontology concept wind direction in the ontology editor Protégé

using the OWL plug-in (modified screenshot).

Finding services dealing with the identified concept. With the chosen concept

“wind direction” the user discovers all three services in an application ontology

registry since the labels used in their WSDL service descriptions refer to application

ontology concepts. The WSDL labels wind (from AirportWeatherService) and

prevailing_direction (from GlobalWeatherService) both refer to the application

ontology concept application1:WindDirection. The WSDL label wind (from

CalculateGasDispersionService) refers to application2:WindDirection.

Although both application ontology concepts are defined using the same domain

ontology concept, the restrictions put on their references reveal that the two concepts

are different. They represent the direction in which respectively from which the wind

is blowing. Discovering whether two concept definitions are equivalent or similar and

whether concepts are related in a subsumption hierarchy is easy in the simple example

we use for illustration. However, when using more complex definitions, it becomes

much more difficult. In such cases a reasoning engine such as RACER [14] can be

used to compute a subsumption hierarchy and to identify equivalent concepts.

With the currently existing WSDL descriptions the user has to judge whether the

application concepts differ in such a way that chaining the services will produce

wrong results. In this example, chaining the AirportWeatherService or the Global-

WeatherService to the CalculateGasDispersionService both would result in a 180-

degree mismatch.

Fig. 5. Definition of two application ontology concepts representing two different conceptuali-

zation of wind direction

The domain ontology concept plus the restrictions on its interpretation provide mean-

ing to the labels used in the WSDL service descriptions. Here it becomes obvious why

domain ontology and application ontology need to form separate levels. The domain

ontology provides a stable source of broadly defined (domain) concepts. The applica-

tion ontology provides the service developer with a flexible means to restrict the

meaning of the domain ontology concepts. Finding services using the same restric-

tions on domain concepts solves naming problems (problem type I). The possibility

for the user to be aware of different restrictions solves conceptual problems (problem

type III).

Alternative Search. Consider a user which belongs to a user community different

form that which built the domain ontology. It is likely that such a user has difficulties

in “finding the right words” to start a search on a domain ontology which is based on

unfamiliar vocabulary. Instead he specifies a query “find concepts which describes

wind”, by using the describes property and the wind concept from the domain

ontology. This approach follows the user-defined query concept introduced by [15].

The reasoning engine RACER returns application ontology concepts which

implement such property. Our ontology architecture application ontologies contain

references to the services they describe. Finding an application ontology concept

which is a sub-concept of the user-defined query immediately indicates a web service

potentially interesting to the user. The two application ontologies in our example can

be distinguished by a user-defined query which is asking for a service which

understands a wind direction as pointing to the compulsion the wind creates. This is

achieved by searching for concepts implementing the pointsToCompulsion property

with the value true.

Learn how the service represents the needed information. Consider the user

searches for services dealing with wind direction where the property

domain1:pointsToCompulsion is true. Such a query would result in finding the

AirportWeather-Service and the GlobalWeatherService which reference to the

application ontology called application1. Now the user needs to know which data

types are used to represent the information he requires. For this purpose the

application ontology of the services is queried. The resulting human-readable

description of the data types employed in the service can be used to deal with

problems of type II. How to automatically derive rules for transforming complex

types or for extracting the required information automatically from the descriptions

will be a topic for future research.

5 Related Work

With the maturation of service-oriented computing, several approaches to service

discovery that are based on service descriptions referring to ontologies have been

proposed (e.g. [16-18]). We share with these approaches the use of inference engines

for evaluating subsumption relationships between the ontology concepts that are used

for annotating syntactic service descriptions. However, we differ from these ap-

proaches in the ontology architecture applied.

In [19] a classification of different ontology architectures used for making the se-

mantics of information sources explicit is introduced (Fig. 6).

Fig. 6. Different ontology architectures for information integration [19]

( ) Single Ontology approaches use one global ontology providing a shared vocabu-

lary for the specification of the semantics. All information sources are related to

the global ontology. Such approaches can be applied to problems where all in-

formation sources to be integrated provide a very similar view on a domain.

( ) In multiple ontology approaches, each information source is described by its own

ontology. In principle, each of these application ontologies can be a combination

of several other ontologies. However, it can not be assumed that several applica-

tion ontologies share the same vocabulary. While each application ontology can

be developed independently, the lack of a common vocabulary makes it difficult

to compare different application ontologies.

( ) Hybrid approaches are similar to multiple ontology approaches in that the se-

mantics of each source is described by its own ontology. But in order to make the

local ontologies comparable to each other they are built from a global shared vo-

cabulary. The shared vocabulary contains basic terms (the primitives) of a do-

main which are combined in the local ontologies in order to describe more com-

plex semantics. Sometimes the shared vocabulary is also an ontology.

The approaches currently proposed for semantic service discovery employ simple

ontology architectures that can be classified as single ontology approaches. The use of

ontologies on multiple levels is not intended. In contrast, the ontology architecture in

this paper can be seen refinement of the hybrid ontology approach. Our domain on-

tology corresponds to a shared vocabulary as shown in Fig. 6c. In addition, the image-

schemata-based ontology on the grounding level provides a means for comparing

concepts form different domains on the one hand, and for grounding domain concepts

in human cognition on the other hand.

6 Conclusion and Future Work

We have identified three types of semantic problems that may occur during web ser-

vice composition: Naming heterogeneity, conceptual heterogeneity and data type

heterogeneity. We have illustrated these types by relating them to a real world exam-

ple based on services employed in a composite service for the management of acci-

dents involving toxic gas releases from a chemical plant. Meaningful composability

of web services needs semantic interoperability between web services. We argue that

semantic interoperability needs a sound theory of semantic grounding.

Therefore we have introduced a three-level Semantic Reference System for tack-

ling the identified problem types. It allows the user to

− discover appropriate services, even when they are named differently than expected,

− identify data type heterogeneity and take further syntactical integration steps, and

− Discover conceptual heterogeneity problems and thus avoid the construction of

composite services producing unintended results.

We have shown in an example ontology how to give meaning to the symbols (labels

of data types) used in WSDL descriptions. This is done by referencing the symbols to

an application ontology, which in turn derives meaning for its concepts from a do-

main ontology, which in turn grounds its concepts on an image schemata-based

grounding level.

We argue that the introduced Semantic Reference System allows for the different

degrees of flexibility, unambiguity and stability such a system has to provide. Apart

from the grounding of meaning with image schemata on the grounding level, the

innovation of this approach lies in the flexibility of the application ontology level. On

this level, a service developer can model virtually anything (including totally fictive

worlds) using restrictions on domain ontology concepts. Likewise, a user can find a

certain concept based on a domain ontology vocabulary and learn how its meaning is

restricted on the application ontology level. While this avoids that statements that are

valid in a certain application ontology need to be valid in another one, they can still be

traced back to their common domain ontology concept.

Future work includes the exploration of the reliability and usability of image sche-

mata for grounding the semantics of domain ontology concepts. Also, we aim to es-

tablish a working prototype of the described Semantic Reference System. This in-

volves the implementation of an environment for testing the semantics of inputs and

outputs of composite services.

Acknowledgements

The work presented in this paper has been supported by the European Commission

through the ACE-GIS project (grant number IST-2002-37724) and the German Fed-

eral Ministry for Education and Research as part of the GEOTECHNOLOGIEN pro-

gram (grant number 03F0369A). It can be referenced as publication no. GEOTECH-

52.

References

1. Chinnici, R., Moreau, J.-J., Gudgin, M., Schlimmer, J., Weerawarana, S. Web Services

Description Language (WSDL) Version 2.0 Part 1: Core Language.[Online]. Available:

http://www.w3.org/TR/2003/WD-wsdl20-20031110/

2. Kuhn, W.: Semantic Reference Systems. International Journal of Geographical Information

Science (2003)

3. Bellwood, T., Clément, L., von Riegen, C. (2003) UDDI Version 3.0.1.[Online]. Available:

http://uddi.org/pubs/uddi-v3.0.1-20031014.htm

4. Bishr, Y.: Overcoming the semantic and other barriers to GIS interoperability. International

Journal of Geographical Information Science 12 (1998) 299-314

5. Lutz, M., Riedemann, C., Probst, F.: A Classification Framework for Approaches to

Achieving Semantic Interoperability. In: S. Timpf, (ed.) COSIT 2003 (Conference on Spa-

tial Information Theory). Springer (2003) 200-217

6. Gruber, T.: A Translation Approach to Portable Ontology Specifications. Knowledge Ac-

quisition 5 (1993) 199-220

7. Barkowsky, T.: Mental Processing of Geographic Knowledge. In: D. Montello, (ed.) Spa-

tial Information Theory - Foundations of Geographic Information Science, Proceedings of

COSIT 2001, Morro Bay, CA, USA, September 2001. Springer (2001) 371-386

8. Johnson, M.: The Body in the Mind: The Bodily Basis of Meaning, Imagination, and Rea-

son. The University of Chicago Press, Chicago (1987)

9. Gärdenfors, P.: Conceptual Spaces - The Geometry of Thought. Bradford Books, MIT

Press, Cambridge, MA (2000)

10. Guarino, N.: Formal Ontology and Information Systems. In: Proc. Formal Ontology in

Information Systems (1998) 3-15

11. McGuinness, D. L., Van Harmelen, F. (2004) OWL Web Ontology Language, W3C Can-

didate Recommendation.[Online]. Available: http://www.w3.org/TR/2003/CR-owl-

features-20030818/

12. Noy, N. F., Sintek, M., Decker, S., Crubezy, M., Fergerson, R. W., Musen, M. A.: Creating

Semantic Web Contents with Protege-2000. IEEE Intelligent Systems 16 (2001) 60-70

13. Knublauch, H. (2004) Editing OWL Ontologies with Protégé.[Online]. Available:

http://protege.stanford.edu/plugins/owl/tutorial/index.html

14. Haarslev, V., Möller, R. (2003) RACER User’s Guide and Reference Manual Version

1.7.7.[Online]. Available: http://www.sts.tu-harburg.de/~r.f.moeller/racer/racer-manual-1-

7-7.pdf

15. Visser, U., Stuckenschmidt, H.: Interoperability in GIS - Enabling Technologies. In: Proc.

5th AGILE Conference on Geographic Information Science (2002) 291-297

16. Kawamura, T., De Blasio, J.-A., Hasegawa, T., Paolucci, M., Sycara, K.: Preliminary Re-

port of Public Experiment of Semantic Service Matchmaker with UDDI Business Registry.

In: Proc. First International Conference on Service-Oriented Computing (ICSOC 2003)

(2003)

17. Paolucci, M., Kawamura, T., Payne, T. R., Sycara, K.: Semantic Matching of Web Service

Capabilities. In: Proc. 1st International Semantic Web Conference (ISWC2002) (2002)

333-347

18. Sirin, E., Hendler, J., Parsia, B.: Semi-automatic Composition of Web Services using Se-

mantic Descriptions. In: Proc. "Web Services: Modeling, Architecture and Infrastructure"

Workshop (in Conjunction with ICEIS2003) (2003)

19. Wache, H., Vögele, T., Visser, U., Stuckenschmidt, H., Schuster, G., Neumann, H., Hüb-

ner, S.: Ontology-Based Integration of Information — A Survey of Existing Approaches.

In: Proc. IJCAI-01 Workshop: Ontologies and Information Sharing (2001) 108-117