ACE-GIS. Adaptable and Composable E-commerce and Geographic Information Services IST

Transcription

1 Adaptable and Composable E-commerce and Geographic Information Services IST D Report and Refereed Conference and Journal Publications on Algebraic Model and Pilot Prototype. Project Deliverable Date: Author(s): Florian Probst, Patrick Maué, Kean Huat Soon, Sven Schade, Sumit Sen, Werner Kuhn Distribution: All partners WP: 6 Version: 1 Keywords: semantic annotation, ontology engineering, representation formalisms, service discovery Description: Work package 6, phase 3 Composability and dynamic adaptability in software, systems and services

2 Executive Summary In phase III, investigations on four formalization approaches for ontologies were conducted. One study was comparing approaches for semantic service description and matchmaking. A second study investigated Haskell- UML mappings. A third study investigated semantic grounding of localization relationships with image schemata. A fourth study investigated Formal Concept Analysis (FCA) and Entailment theory to construct a conceptual structure of user actions for ontologies. Apart from the investigations on formalization methods, the core workload in phase III was the development of a prototypical tool for semantics-based service discovery incorporating the development of suitable domain and application ontologies. These domain ontologies are partly based on ISO and OGC standards. Central to the approach is the dynamic merging of ontologies depending on the information need of the user. The grounding level of the ontology architecture proposed the incorporation of theories form cognitive science. Therefore image schemas were investigated, as to which extent they can be employed for the semantic grounding of locating relationships. The developed prototype enhances UDDI based service discovery. Organized in the form of a Wizard, the Semantics-based Service Discovery Assistant (SeDA) helps users to align their own understanding of a concept with that of service developers. The tool provides the user with the ability to browse through a dynamically created ontology and select the concept of interest. Finally, it returns the service description of that service that is referenced to the concept identified by the user D-6-3.doc Project Deliverable Page 2/72

3 Table of Contents 1 Introduction 4 2 Investigations on Formalization Methods Comparing Approaches for Semantic Service Description and Matchmaking Haskell UML mapping Semantic Grounding of Locating Relationships Formalizing User Actions for Ontologies 9 3 Ontology Engineering Design Decisions Application Ontologies Informal Terminology Turning WSDL files into Application Ontologies Domain Ontologies Carving up Domains How Application Ontologies inherit Semantics form Domain Ontologies Connecting ISO and OGC Models to the Semantic Web 12 4 SeDA - Semantics-based Service Discovery Assistant Functionality and Benefits How to use SeDA Step 1 Select Domain of Interest Step 2 Specify Focus of Discovery Process Step 3 Browse merged Application and Domain Ontologies Step 4 Retrieve Information Architecture WSDL Extension Parsing UDDI, WSDL and OWL context Assumptions made References: 22 5 Appendix D-6-3.doc Project Deliverable Page 3/72

4 1 Introduction In workpackage 6 of phase III different formalization approaches for ontology engineering were investigated. Therefore the two threads of the ontology architecture (figure 1) developed in phase II were compared by using ontologies developed for the e-emergency composite service. The ontologies cover the same information content; however one ontology is based on algebraic specifications the other is based on OWL. Additionally the mapping between thread one and two were investigated by implementing a prototypical tool for mapping between the functional language Haskell and the objectoriented UML. The grounding level of the ontology architecture proposed the incorporation of theories form cognitive science. Therefore image schemas were investigated to which extend they can be employed for the semantic grounding of locating relationships. Grounding Level Thread I Thread II preconceptual GOAL Number of Ontologies Changes Ontology Engineering Approach Grounding Level reference to Semantic datum one (?) none Image schamata based Conceptual Level reference the domain concepts Domain Ontology build Domain Experts conceptual Stable meaning few rare Blending based domain theory reference to Application Ontology Application Level references the application concepts to the domain ontology describes service provides dynamic symbols many frequent Axiomatic model WSDL Web Service (Data or Application) Service Provider / Developer symbolic Figure 1: Overview of the two threaded ontology architecture. Core workload in phase III was the development of a prototypical tool for semantics-based service discovery incorporating the development of suitable domain and application ontologies. These domain ontologies are partly based on ISO and OGC standards. After an evaluation phase, the design decision was to use OWL for ontology engineering. According to the ontology architecture, proposed in phase II, ontologies were built and integrated. In order to cover the concepts needed for describing the services of the e-emergency pilot composite service, six different domain ontologies were developed. The Semantics-based Service Discovery Assistant (SeDA) enhances UDDI based service discovery. The services developed in the e-emergency pilot are described with WSDL (provided by partners). As proof of concept, the developed ontologies, capturing the semantics of the WSDL descriptions were registered in the modified UDDI. This allows the SeDA to semantically enhance UDDI-based service discovery. Organized in the form of a Wizard, SeDA helps users to align their own understanding of a term with that of service developers. Guiding the user through four steps, the discovery tool offers the following benefits: It creates a merged ontology which contains both, concepts defined in a user selected domain D-6-3.doc Project Deliverable Page 4/72

5 and concepts defined application ontologies that are referenced to this user selected domain ontology. The tool provides the user with the ability to browse through the created ontology, and select the concept of interest. Finally, it returns the service description of the service that uses the concept identified by the user. The remainder of this report is structured as follows. In section 2 the investigations on formulisation methods are summed up. Section 3 is illustrated the ontology development process. As a central point OGC and ISO standards are used to develop the required domain ontologies. The use, functionality, and architecture of the developed prototype for semantics-based service discovery are introduced in detail in section 4. 2 Investigations on Formalization Methods This chapter summarises four studies investigating knowledge formalization methods and mapping between those. The studies draw on the experiences made in the previous phases and are mainly based to the e-emergency use case. Three studies resulted in articles submitted to conferences. The articles can be found in the appendix. 2.1 Comparing Approaches for Semantic Service Description and Matchmaking The approach for semantic service description and matchmaking, which is currently focused in the Semantic Web community, was compared to an alternative based on the use of functional languages and algebraic specification. Concerning the ontology architecture developed in phase II (figure 1), the formulization methods underlying the two threads are compared. The discovery of an appropriate wind information service as a component of the e-emergency composite service was taken as the illustrating example. The result of this work was accepted as a full paper at the ODBASE The article can be found in the appendix. Summary Matching descriptions of user requirements against descriptions of service capabilities is crucial for the discovery of appropriate services for a given task. To improve the precision of approaches that consider only syntactical aspects of matchmaking (e.g. UDDI) several approaches for semantic matchmaking have been proposed. This work compared two of them with respect to their potentials for matchmaking between semantic descriptions of geoinformation services. The State-based Approach is characterised by a combination of several ideas currently discussed in the Semantic Web community. The functionality of a service is captured by describing the parameters before and after the execution of the service s operation. Each parameter refers to a concept of an OWL DL ontology (typically called input and output) and is constrained by a rule or a fact, stated, for example, with the Rule Mark-up Language (called preconditions and effects). Since the semantics of the operation itself cannot be captured directly, a service operation is seen as a black box. The main characteristics of the Algebraic Approach are the utilization of an executable programming language to describe ontologies and the similarities to the method of algebraic specification. Functionality is described via operators relating to abstract data types. The semantics of these operators are defined by axioms, which serve as interpretation rules for the offered functionality. In this way the dynamic behaviour of the abstract data type is formally specified. Inputs and outputs of an operator belong to this direct functionality description. In recent years, the functional language Haskell has been used for specifying concepts in the domain of geospatial information D-6-3.doc Project Deliverable Page 5/72

6 In this study, both approaches were used to implement matchmaking between user requirements and service capabilities for the is specialisation of type of match, i.e. the discovered service is more specific than required, but can be used directly in a service composition. The example implementations revealed that neither the State-based nor the Algebraic Approach is able to express all relationships between concepts in an unambiguous way. While the first suites formalising static concepts that are mainly related taxonomically, the latter serves formalising dynamic behaviour and features more kinds of relations. In the Algebraic Approach part/whole and arithmetic relations can be addressed additionally, but the approach fails in specifying disjointness between two concepts, while the State-based Approach does not. In general, a set of mature tools is available for the State-based Approach, e.g., for validation and consistency checking of ontologies. However, the Web Service Matchmaker, which was chosen as a representative matchmaking tool for this approach did not meet the expected results for the is specialisation of type of match, although the rules contained in the State-based Approach generally provide the possibility to query dynamic behaviour. Concerning the Algebraic Approach, the Haskell compiler can be used to check the consistency of domain ontologies, where violations of the type system result in error messages. The Haskell interpreter (Hugs98) was used to investigate requirements for tools supporting matchmaking based on the Algebraic Approach. It can already be used to identify the type of match investigated in this work. The State-based Approach is suitable as long as static concepts are focused, e.g. if concepts, which are underlying the offered feature data have to be described (e.g. wind speed in knots). As soon as dynamic aspects become important, e.g. if the kind of data acquisition (like measuring wind speed using an anemometer) needs to be formalised, the Algebraic Approach is a noteworthy alternative. 2.2 Haskell UML mapping As a first investigation on how to bridge the gap between the different modelling approaches of thread one and two of the ontology architecture (figure 1), mappings between the functional programming language Haskell and the object- oriented UML were investigated and implemented prototypically. The investigation was conducted by Dominik Grüning as part of his diploma thesis (D. Grüning (2004): Ein Werkzeug zur automatischen Ontologie-Übertragung zwischen Haskell und UML, Diploma thesis, Institute for Geoinformatics, University of Münster, only German version available.) Summary A crucial point in the development of environments for service discovery is a formal specification of semantics. Formal methods need to be employed to fulfil the requirements of correctness, uniqueness and completeness. Such methods are not integrated into the widely used UML, where only syntactic aspects can be specified. The Object Constraint Language (OCL), as an extension of UML, provides a formalism to annotate a UML model with semantic information; however it seems not to satisfy the basic requirements of a specification language. Those requirements are to allow precise description of semantics, to be easy to read and write for the human user and to enable rapid prototyping. Since the functional language Haskell satisfies these requirements, it would be promising to have methods at hand, which enable to import the Haskell-specified objects into UML and thus placing them neatly into the overall model. Such method would combine the strength of both languages. During this study, a tool was implemented, which can load UML class model information via the XML Metadata Interchange (XMI) Standard. The model information is interpreted and displayed via an entry masks and by clicking the appropriate button the model information is mapped to a Haskell script. In a similar procedure, the reverse process can be performed, mapping Haskell code to UML. The UML information is saved in an XMI stream and thus can be used in any development D-6-3.doc Project Deliverable Page 6/72

7 environment offering an XMI interface. In the context of the e-emergency management pilot, an example ontology for capturing wind, wind speed and wind direction was developed in Haskell and successfully mapped to UML and back. The investigation showed that the mapping between Haskell and UML is possible for the basic constructs of the languages and that most of these mappings can be automated. On the one hand, UML ontologies can be mapped without loss of information to Haskell; thus the mapping is complete. However, the automatic translation is ambiguous at some points. In these cases, user interactions are required, leading to a semi-automatic mapping. Table 1 shows the major mapping decisions for mappings from UML to Haskell. Table 1: Major mapping decisions for mappings from UML to Haskell UML UML:Package UML:abstractClass UML:Class UML:Generalization UML:Attribute UML:Method Haskell Haskell:Module Haskell:Class Haskell:Data, Haskell:Instance Haskell:Class, Haskell:Instance Haskell:Type Haskell:Function Mapping from Haskell to UML, on the other hand, leads to losing the axioms, which define the semantics in Haskell, thus this translation is incomplete. Nevertheless, the mapping is unambiguous, because the structure, typing and naming of a Haskell ontology can be mapped to UML without any loss. Table 2 shows the Haskell elements that can be mapped unambiguously to UML. For more complex Haskell structures, which contain axioms and constrains for data type, no mapping rules were developed. Table 2 Major mapping decisions for mappings from Haskell to UML Haskell Haskell:Module Haskell:Data Haskell:Class Haskell:Instance Haskell:Type Haskell:Function UML UML:Package UML:Class UML:abstractClass, UML:subClassOf UML:Class, UML:subClassOf UML:Attribute UML:Method The characteristics of the two kinds of matching are summed up in figure D-6-3.doc Project Deliverable Page 7/72

8 unambiguous incomplete ambiguous complete Figure 2: Relation of elements mapped between the tow languages 2.3 Semantic Grounding of Locating Relationships The investigation of image schemata as means of semantic grounding was conducted for the special case of localization problems of spatial entities. The result of this work was submitted as extended abstract to GIScience The article can be found in the appendix. Summary Computing the location of an entity means determining the locating relationship it has with another entity. When combining data from multiple sources, the question arises which locating relationships can be computed among their feature types. Answering this question is crucial for discovering suitable spatial data sets and services in open and distributed environments, such as the one of GI web services. Image schemas are assumed to serve as smallest common denominator for the conceptualization of spatial entities. Thus they appear as prime candidates for semantic grounding of more complex spatial concepts. Based on this assumption, the hypothesis of this work is, that semantic ambiguity of locating relationships can be reduced when data or service provider make their conceptualization explicit by using image schema. Within the e-emergency use case, the locating relationships of a gas plume and a town were used to show the ambiguities in locating relationships which can arise, if the conceptualization of the service provider does not match the conceptualization of the service requester. Locating relationships like ON or IN are usually assumed to be understood correctly by the service provider respectively by the service requester. However, the operations which can be computed on a spatial representation of a real world entity differ considerably with its underlying conceptualization. We show that this ambiguity can be reduced significantly if the service requester is asked to formulate his query considering the real world setting. E.G. Is the town IN the plume? The service provider in turn has to annotate his data source in two steps. First he has to specify the dimensionality of the embedding space, in most cases 2D or 3D. Second he has to specify the image schemata with which the feature type under consideration was conceptualized. E.g. stating that a plume was conceptualized with the image schema CONTAINER reveals that containment operations (IN) can be performed on it. These two annotation steps are considerably fast to perform compared to full semantic specification of the feature type s spatial representation, (if this is possible at all). The benefit of this approach is to judge quickly and with high precision, whether the spatial structure of a feature type offered by a service matches the user request semantically. E.g. it answers questions like Can I perform IN operations on that feature type? This approach ensures that the semantics of locating relationships are used consistently; it does not provide any translation or conversion of feature types in order to enable syntactical interoperability between data sets D-6-3.doc Project Deliverable Page 8/72

9 2.4 Formalizing User Actions for Ontologies In the following a study on formalizing user actions for ontologies in the geographic domain is summarized. The work has been accepted for publication as full paper at the GIScience The article can be found in the appendix. Summary Semantic interoperability has received attention in the geospatial information community as well as in Artificial Intelligence (AI) and Knowledge Engineering. The ontologies have been proposed as means to achieve it. An ontology describes the contents of a particular domain or task setting, so that different contents can be matched and integrated during decision-making. So far, most ontologies for geospatial information and most ontology languages are limited to entities, leaving out the conceptualization of actions. We propose a method using ideas from Formal Concept Analysis (FCA) and Entailment theory to construct a conceptual structure of user actions for ontologies. An action lattice is built from the relations found between the user actions through FCA. Complementing the action lattice, Fellbaum s notion of entailment between two actions is adopted. The subconcept-superconcept relations between two user actions are thus supplemented by entailment relations. A case study is introduced to present the construction of an action structure from the user perspective. An official document, which contains the user actions, is selected as the main knowledge source. This document describes all user actions that are to be performed during surface water monitoring in the context of the European Water Framework Directive (WFD). The user actions are extracted from the verb and noun phrases in the document. The overall goal of this ongoing research is to bring task-related knowledge to ontology engineering, resulting in the development of ontologies that support user actions. With the developed action lattice, we aim to enhance the context specification in semantic similarity assessment. We call the result of our knowledge extraction and formalization process an action structure, as it does not yet have the form of an ontology expressed in a standard language (such as OWL, the web ontology language). 3 Ontology Engineering In this section the development process of the ontologies is documented. OWL is taken as the language of choice. Problems encountered and decisions taken are documented. Finally, the use of existing OGC and ISO standards for developing ontologies of the geospatial domain is discussed. 3.1 Design Decisions Currently the Web Ontology Language OWL is developing as standard ontology for the semantic web. On the basis of description logics, it allows describing the information content of a service. In parallel OWL-S as an ontology for service description, written in OWL, is under development. OWL-S is intended to serve as a semantic description of the service s structure itself, additionally to the information content the service is offering. However OWL-S appears premature and inefficiently difficult to handle. Therefore we rely on WSDL for syntactic description of the service s structure. Hence, our approach provides no semantics on what a message, an operation, or binding is itself. In contrast, the type definition in which the input and output types of the service are described, deal with the information content, the service delivers as output, respectively requires as input. Here, we decided that a first attempt to capture the semantics of the service s information content should come into play. For service content description, OWL appeared appropriate D-6-3.doc Project Deliverable Page 9/72

10 3.2 Application Ontologies Application ontologies are intended to directly capture the meaning of labels used in the WSDL descriptions. Since the labels stand for information represented in data-bases, or calculated by the service based on a model, e.g. the plume of toxic gas, the labels stand for highly abstracted representations of real world entities or phenomena. These abstractions are accounted for in an application ontology. Here, the alerted meaning of gas plume is captured. For example, a real world gas plume is conceptualized with a three-dimensional extent, fuzzy boundaries and changing extend is represented by a service as polygon with sharp boundaries and no dynamic change over time. This example shows the need for two separate layers of semantic description for the same term gas plume. The domain ontology serves as a starting point for the human user in his search for a certain concept. The application ontologies in turn account for the semantics of the data representation implemented by a certain service. The two distinct semantic layers allow several application ontologies to draw (or inherit) the semantics for their definition of e.g. gas plume from a single domain ontology concept Informal Terminology The type definitions of the WSDL files were skimmed for all terms contained in the name attributes of elements and complex types. This resulted in a first list of terms, which should be incorporated as concepts into the application ontologies. Similarly, informal terminologies were created for the domain ontologies. The informal terminologies served also as starting point for deciding how to draw domain boundaries Turning WSDL files into Application Ontologies The different styles of writing WSDL files caused problems in deciding which terms are to be taken into the application ontologies and which are not. In a first attempt, only terms from the WSDL files' type definition were included into the application ontologies. This turned out to be insufficient, since some developers used only strings in the definitions of messages. Therefore all messages where analysed too, in order to include these labels into the application ontologies. In some cases, theses strings were meaningful only to the WSDL developer, e.g. arg0. Such cases caused intensive personal communications in order to find suitable terms for the informal terminology. These cases show impressively how different the understandings of labels in WSDL files can be. 3.3 Domain Ontologies The human user has to specify his information requirements when searching for a suitable service. As proposed in the ontology architecture, domain ontologies serve as starting point for this search. Since there are infinitely many ways of modelling and representing information, it may be difficult to search directly for the required data representation. Therefore domain ontologies are supposed to provide a more general description of the real world entities and phenomena the user is interested in. If the user has found a potentially fitting concept on domain level, the search is extended to application ontology level to find services which reference their data representation to the identified domain ontology concept. In this way, the meaning of the real world entity or phenomenon gets transferred to the data representation Carving up Domains Carving up domains turned out to be more art than science. A domain can be seen as the context in which service discovery takes place. The question arises, how to efficiently carving up theses domains? We followed the general guideline, defining domains as special areas of interest, hence using heuristics to define the domains for the pilot services. When a certain community can be identified to have established a special vocabulary to communicate about objects and tasks, it appears D-6-3.doc Project Deliverable Page 10/72

11 useful to summarize these objects and tasks as belonging to the same domain. This may result in such prominent domains as medicine, physics or computer science, where non-community members have doubtlessly problems in communication, simply due to the matter that they do not share the same vocabulary. In this sense (1) introduced the term of a shared vocabulary needed to communicate about a certain subject matter. Domain ontologies serve as starting point for service discovery, therefore the user has to select the appropriate domain by relating the information he requires to the offered domain ontologies. It turned out quickly, that some concepts are easily and exclusively assigned to a certain domain but most are not. One could argue that depending on the task in mind, a user will select the appropriate domain. For example, a user with the task of modelling a gas plume may locate this concept in the domain of chemistry as well as in the domain of disaster management or the domain of geographic entities. Depending on the context of this modelling task, the correct domain is selected. However, with regards to adaptable and reusable web services, the challenge is to allow users to judge whether a service developed for modelling gas dispersion from a chemical point of view is suitable for a modelling task in a geographic context. Currently the challenge of changing contexts remains an open question. During the process of defining the domain ontologies that are needed to capture the terms used in the pilot s WSDL files, it turned out that the granularity of domains is crucial for allowing the user to efficiently select the appropriate domain. Too many domains will complicate the user s selection of a domain, few but therefore large domain ontologies will complicate the user s search within an ontology. We decided to allow inheritance of concepts between domain ontologies. This decision allows building domain ontologies according to the definition given above. However these domain ontologies will need more general terms in order to define the vocabulary of that domain. Therefore, these specialized or starting point ontologies reference to concepts in more abstract domain ontologies. For example, the rather abstract domain ontology observation and measurement will provide concepts used in the starting point domain ontology metrology. Additional to the starting point domain ontologies, domain ontologies describing spatial representation aspects and data representation aspects are needed to allow the application ontologies to refine the concepts inherited from the starting point ontologies. For example: The user starts his search in the starting point ontology geographic entity, which contains the concept gas plume. The application ontology of a web service calculating gas plums will inherit the semantics of gas plume form the geographic entity domain ontology. Additionally it will reference to concepts defined in the spatial representation domain ontology, in order to make clear how this real world phenomenon is modelled. In order to provide semantics for the terms of the pilot services, six ontologies for the domains of data representation, spatial representation, meteorology, localization, observation & measurement and geographic entities. This number seems large compared to the small number of twelve input/output messages of the services, however, if the number of semantically annotated messages (services) increases, the number of additionally needed domain ontology will finally come to halt How Application Ontologies inherit Semantics form Domain Ontologies Two types of relations can be employed to connect a concept from an application ontology to an domain ontology: taxonomic and non-taxonomic relations. We employed taxonomic relations (so called is-a relations) as main anchor for the semantics of application ontology concepts. For example, the application ontology concept AirportCode is defined to be a GeographicIdentifier (is-a relation), a concept of the domain ontology Localization. Additionally, we employed non-taxonomic relations to enhance the definitions of application ontology concepts. E.g. the application ontology concept AirportCode has the non-taxonomic relation is_managed_by to the domain ontology concept Organization. This concept in turn can be specialized to Aviation Organization D-6-3.doc Project Deliverable Page 11/72

12 Application ontology concepts are supposed to be found via domain ontology concepts. This is currently done via the established is-a relations. Consequently the application ontology concept inherits all properties of the domain ontology. Adding new properties to the application ontology concept is unproblematic; however stating that the application ontology concept does not implement all properties of the domain ontology concept is impossible due to the paradigm of inheritance. Currently we solve this problem in allowing critical properties in the domain ontology to have the cardinality 0. The application ontology concept thus inherits the property, but the cardinality is set to 0, indicating that this property (or role) does not exist in the application ontology view. Another possibility to avoid this problem is to avoid the use of is-a relations, but instead to use nontaxonomic relations to define the semantic dependency between application and domain ontology concepts. Following this approach, non-taxonomic relations like is_similar_to are established between application and domain ontology concepts. This type of relation does not force the application ontology developer to use all domain ontology properties for defining a certain application ontology concept. Closely related to the problems of how to efficiently carve up domains and how to connect application and domain ontologies, is the problem of appropriately specifying domain ontology concepts. If a domain ontology concept is modelled with large number of properties, an application ontology developer might have problems in assigning the service s model to that highly specified concept (see inheritance problem above). On the other hand, if the domain ontology concept is modelled with a small number of properties, the user might have difficulties in finding the correct concept since its semantics are underspecified. In the pilot implementation, we tend to have rather specific domain descriptions and application ontology concepts adding only few or non extra properties. We are aware that an increasing number of application ontologies will require to reduce the number of properties, a domain ontology concept contains, in order to facilitate application ontology to accept domain ontology concepts as super concepts. 3.4 Connecting ISO and OGC Models to the Semantic Web In the following, work conducted in conjunction with six participants of the ALFA summer 2004 is described. The work is compiled in an article which is accepted as extended abstract at the GIScience The article can be found in the appendix. Summary OGC and ISO have developed extensive standards for geospatial applications, providing well-founded definitions of concepts related to the geospatial domain. Currently these standards are available in textual descriptions supported by UML static structure diagrams, giving guidance to developers to implement applications. However, in an open and distributed environment, the possibility to assess the interoperability of applications and data sources without human intervention is becoming increasingly important. Focus of the work was to translate the ISO Spatial Referencing by Coordinates, ISO Spatial Referencing by Geographic Identifiers, ISO Spatial Schema and OGC Observation and Measurement into ontologies, which are then integrated in the ontology architecture. First available UML diagrams were investigated and informal terminologies were created. It appears that the UML diagrams were optimized in order to use as few classes as possible. In contrast ontologies as supposed to provide sound semantics of the mapped classes. For that reason new concepts needed to be included into the ontology in order to improve the reasoning capability. Second, suitable mappings from UML to OWL were investigated. The relatively small number of 80 terms employed in the WSDL files of the web services caused 915 concepts to be included into the domain ontologies. This result gives rise to new research questions addressing the merging of larger ontologies. Although the functionality of importing ontologies is given in OWL, handling and performance of reasoning operations suggests that methods D-6-3.doc Project Deliverable Page 12/72

13 for efficiently carving up domain ontologies are needed. 4 SeDA - Semantics-based Service Discovery Assistant Composition of web services based on currently available descriptions such as WSDL is error-prone because the meaning (or semantics) of the labels used in these syntactic descriptions is unclear. In the previous phase of the project, three problem types have been identified as resulting from semantically heterogeneous service descriptions. SeDA facilitates the discovery of semantic heterogeneities between web service descriptions and thus helps to avoid the problem of composing web services in a way that may lead to unintended results. In this chapter the use of SeDA (see tutorial), its functionality and architecture is described. The ontologies described in chapter 3 were utilized to develop and test the prototype. 4.1 Functionality and Benefits Organized in the form of a Wizard, the Semantics-Based Service Discovery Assistant helps users to align their own understanding of a term with that of service developers. Guiding the user through a fixed number of steps, the discovery tool offers the following benefits: 1. It creates a merged ontology, containing terms that are: Used in the domain that the user has selected; Used in application ontologies describing either service output or service input 2. It provides the user with the ability to: Browse through the newly created ontology, which is merged from ontologies according to the user s selection, and Select the concept of interest. 3. It returns information about of the service that references its WSDL-terms to the concept identified by the user. 4.2 How to use SeDA The tool provides a wizard user interface, which guides the user through four steps. Within these four steps the user s requirements (input or output) are semantically aligned with the capabilities of the available services Step 1 Select Domain of Interest In step one the user is presented with a list of domain ontologies. Each of the domain ontologies comes with a short description to give you some orientation (figure 3). Selecting a domain can be understood as selecting the area of interest on which the discovery process will be focused. By selecting a domain, you select the context-domain in which your search will take place. Each different domain will have its own understanding, depending on the context for which it has been defined. E.g. if you are looking for information about wind speed at a certain location, selecting the meteorology domain is appropriate. If you are looking for a service providing a gas plume calculation, selecting either the domain of chemistry or the domain of geographic entities may be appropriate. However, you always search in a certain context in which the service will be used, and thus will be able to distinguish whether the domain of chemistry or geographic entities is appropriate. In both domains, services about gas plumes may be provided, but with very different modelling approaches D-6-3.doc Project Deliverable Page 13/72

14 There are two reasons for selection of a domain. 1. A domain is characterised by the use of specialised vocabulary. For example, some terms may be used exclusively by the members of that domain; some terms may have a special meaning in that domain compared to others. 2. Selecting a domain, reduced number of potentially suitable services on offer. The number of ontologies available depends on how many domain ontologies are registered with the UDDI. Figure 3: The user selects the domain, which is identified by the user as setting the context for the service discovery Step 2 Specify Focus of Discovery Process Each atomic service has an input data type and an output data type for the operation it offers. The meaning of the data type a service requires as input or the data type it provides as output are described in its applications ontology. Depending on the approach chosen to build a composite service, there are two ways to identify a service (figure 4). The user can either specify that the discovery process should focus on the data type which the service accepts as input or on the data type which is returned as result (output). Similar to step one, the specification whether input concepts or output concepts are in the focus of the discovery process reduces the amount inappropriate search results. This decision is needed to enable selection of the appropriate application ontologies, and later to mark the terms used to describe the input (output) appropriately in order to increase the readability of the provided information D-6-3.doc Project Deliverable Page 14/72

15 Figure 4: The user specifies whether the focus of the discovery process is on the information requested by the service (input) or provided by the service (output) Step 3 Browse merged Application and Domain Ontologies The Semantics-based Service Discovery Assistant searches in the UDDI for all Operation tmodels which reference either their input concept or output concept to the domain ontology the user specified in step 1. Since the Operation tmodel is linked to the WSDL file describing the service to which the operations belongs to, the application ontology which provides the semantics for that service (and its operation(s)) is identified. All application ontologies that are found during this process are imported and merged with the user selected domain ontologies. This results in a concept hierarchy, (figure 5) containing only the relevant concepts form the domain ontology needed to define the application ontology concepts describing either operation input or output. Such reduction of complexity appears to be crucial if one considers a large number of ontology to exist. The user s task in step 3 is to browse the newly created ontology and identify concepts of interest. By clicking on any of the concepts (highlighting), the right hand windowpane displays that concept s definition based on DL (description logic) statements. This enables the user to learn about the meaning of a particular term in a particular service. The user learns about the differences between the services, discover semantic heterogeneities and thus avoid errors D-6-3.doc Project Deliverable Page 15/72

16 Figure 5: The domain and application ontologies selected in the previous steps are merged Step 4 Retrieve Information In step 3 the user selects a concept that describes the input (or output) information he requests. The Semantics-based Discovery Assistant uses the WSDL file of a service registered in the UDDI to import the application ontology of that service. Therefore it is possible to trace back which service makes use of the user-selected concept. Step 4 retrieves from the UDDI all available information about that service. The user is provided with the information needed to invoke the service (figure 6) D-6-3.doc Project Deliverable Page 16/72

17 Figure 6: From the UDDI, the information for service invokation is retrived and presented. Step 4 concludes the search for a service. In the case of building a composite, the search is repeated. If the backward chaining approach is used, the input concept from the discovered service is now used as output concept for the next service to be discovered. If the forward chaining approach is used, the output concept of the discovered service is used as the required input concept of the next service to be discovered. 4.3 Architecture The architecture of SeDA focuses on incorporating existing standards. For registering services, we use and extend the Universal Description, Discovery and Integration (UDDI) protocol. Services are described using the Web Service Description Language (WSDL) (provided by partners). Domain and application ontologies are built using the Web Ontology Language (OWL). Figure 7 shows how the different components of SeDA collaborate. Enhanced use of UDDI Registry The Universal Description, Discovery and Integration (UDDI) protocol is currently one of the major building blocks required for web service registration and discovery. UDDI provides a standard interoperable platform that enables companies and applications to dynamically find and use web services over the Internet ( We employ a UDDI registry as basis for semantically enhanced service discovery. However, several changes to the standard procedure of registering a service were made. Instead of using tmodels to describe web services as atomic units, we introduced Operation tmodels in order to perform searches for service operations directly. This results in registering several Operation tmodels if the service offers several operations. Additionally we introduced Domain Ontology tmodels as a means of registering domain ontologies in a UDDI registry. In the following the functionality of a tmodel in general as well as the specific functionalities of the newly introduced Operation - and Domain Ontology tmodels is described D-6-3.doc Project Deliverable Page 17/72

18 User 2. displays descriptions of domain ontologies 7. display the merged ontologies 11. displays service descriptions 3. selects the domain ontology 4. selects to search for concept describing service <input> OR <output> 8 browses displayed merged ontology 9. selects concept of interest SeDA 1. requests URLs of registered domain ontologies 5. searches for application ontologies referenced to user specified domain ontology 10. requests description of service which are referenced to application ontology containing user selected concept Domain Ontology responses to SeDA requests has Domain Ontology tmodel is referenced to UDDI Registry searches in Operation tmodel Operation Output Operation Input 6 Imports and merges selected domain and application ontologies derives semantics Application Ontology references to WSDL references all terms to application ontology concepts describes Web Service Figure 7: Collaboration of the SeDA components. tmodels provide the ability to describe compliance with a specification, a concept, or a shared design ( TModels have various uses in the UDDI registry. We are interested here in the use of tmodels to represent technical specification of the operations of the web services and domain ontologies. Each tmodel should consist of a name, a description, one or several identification scheme, which contain a keyname and a keyvalue, and an overviewurl that identifies the location of a document describing the service e.g. a WSDL file. Domain Ontology tmodels are introduced to allow the registration of domain ontologies at the UDDI registry in analogy to registering a web service. Each Domain Ontology tmodel contains domain ontology name, domain ontology description, and domain ontology URL (as overviewurl) and a unique tmodelkey used for identification. The domain ontology name and description provide the name of the domain ontology (e.g. meteorology) and a natural language description of the content to facilitate the user to select the appropriate ontology D-6-3.doc Project Deliverable Page 18/72

19 Operation tmodel Operation Name Operation Description 1..n Identification Schema KeyName: ``Input``or``Output`` KeyValue: Domain Ontology tmodelkey overviewurl: WSDL URL references references Domain Ontology tmodel Domain Ontology tmodelkey (Unique Identifier) Domain Ontology Name Domain Ontology Description overviewurl: Domain Ontology URL WSDL references Domain Ontology Figure 8: Connection between tmodels, WSDL and Domain Ontology Operation tmodels, in contrast to common tmodels, employ one or several identification schema in order to install a link between the terms describing that operation in the WSDL file and domain ontologies from which theses terms derive their semantics. Since each operation has an input message and an output message, at least two terms need to be semantically annotated. If the two messages are described by terms that are linked to different domains, two identification schemas are installed in the Operation tmodel. One of the two identification schemas has the keyname input; the other has the keyname output. Their keyvalues are the unique tmodelkeys of the Domain Ontology tmodels. The Domain Ontology tmodels in turn allow identifying the location of the domain ontologies (see figure 8). The reason why we need to introduce Operation tmodels is that a service can provide several operations with two messages each, which could contain several parts. These parts finally need to be semantically annotated. Operation tmodels provide the flexibility to account for such detailed reference to different domain ontologies. These references provide the possibility to quickly identify which input messages (or output messages respectively) refer to the domain ontology the user has identified as focus of his search. This increases the usability of the ontology browser since only terms describing input messages (or output messages respectively) are presented. Figure 9 depicts the relationship between domain ontologies, operations, WSDL files, and application ontologies. It illustrates five of the six domain ontologies developed for the prototype, which have been registered as domain ontology tmodel at our UDDI registry. The sixth domain ontology has no direct link to the terms of the registered operations; hence it is not showing up in the drawing. The user starts a service discovery iteration by selecting one or more domain ontologies. Then the Operation tmodels referenced to the selected domain ontologies are identified via the Domain Ontology tmodels. The Operation tmodels in turn identify the WSDL of the services. The WSDL files, providing syntactic descriptions of the services are semantically annotated via application ontologies. The WSDL extension described in identifies the application ontologies D-6-3.doc Project Deliverable Page 19/72

20 Domain Ontology Localization Meteorology Spatial Representation Observation and Measurement Geographic Entities Input GetPlantLocationSoapIn LocateNearestAirportSoapIn getnearestairportcoderequest getsummary calculateplum erequest GasDispersionMapRequest Output GetPlantLocationSoapOut LocateNearestAirportSoapOut getnearestairportcoderesponse getsummaryresponse calculateplumeresponse GasDispersionMapResponse Operation GetPlantLocation LocateNearestAirport GetNearestAirportCode GetSummary calculateplume portrayplume WSDL Description WSDL WSDL WSDL WSDL WSDL PreEmergencyPlan AirportWeather GetNearestAirport Code CalculateGas DispersionPlume CreateGas DispersionMap Application Ontology Figure 9: The relationship between domain ontologies, operations, WSDL files, and application ontologies employed in the prototype WSDL Extension Our goal of adding semantics to WSDL descriptions is to annotate those elements describing the information content provided by the service. We identified the need of referencing the tags <ComplexType>, <element> (within a ComplexType) and <part> (within a message) to the application ontology, in order to capture the semantics of the tag s name. A new attribute was introduced to reference these tag the application ontology. This attribute is called <semref> and is defined in the following short XSD file (listing 1): Listing 1: XSD file for defining the attribute needed to reference WSDL terms to application ontologies. <xs:schema targetnamespace=" xmlns=" xmlns:xs=" <xs:annotation> <xs:documentation xml:lang="en">schema for the semantic reference of WSDL Files. The attribute semref allows to connect elements and complextypes from a WSDL file with an application ontology (OWL). </xs:documentation> </xs:annotation> <xs:attribute name="semref" type="xs:string" use="optional"/> </xs:schema> This attribute allows inserting the application ontology s URL in which the annotated element is explicitly described. Listing 2 gives an example of how the parts of the message calculateplumerequest of the CalculateGasPlume Service provided by ionic is referenced to the application ontology D-6-3.doc Project Deliverable Page 20/72

21 Listing 2: Example for WSDL parts referenced to an application ontology. wsdl:message name="calculateplumerequest"> <wsdl:part name="origin" type="tns1:point" SeDA:semRef=" <wsdl:part name="windspeed" type="xsd:float" SeDA:semRef=" muenster.de/onto/ace/a_calpl.owl#windspeed"/> <wsdl:part name="winddirection" type="xsd:float" SeDA:semRef=" muenster.de/onto/ace/a_calpl.owl#winddirection"/> <wsdl:part name="emissionrate" type="xsd:float" SeDA:semRef=" muenster.de/onto/ace/a_calpl.owl#emissionrate"/> </wsdl:message> Parsing UDDI, WSDL and OWL We decided to use the Xerces (2) SAX parser. The increased performance compared to DOM parsers, justifies the more complex handling of the parser. First, the parser reads messages, message parts and types of the WSDL files under consideration. In the second step, the tool combines the parsed information and provides a list of items. Each item provides the following information, combined of the WSDL and UDDI parsing steps: The WSDL parsing returns - the location of the application ontology file (e.g. " - the concept within the application ontology, to which the parsed WSDL element references ("e.g. GasPlume") - the name of the message part ("calculateplumeresturn") - the name of the message with this message part ("calculateplumeresponse") - the name of the operation containing this message ("calculateplume") After the previous three steps, information can be provided about - the type of message to which the parsed WSDL element belongs to. The parsed element can either belong to an input message or an output message. information returned by UDDI query - the natural language description of the operation - the name of the selected domain ontology. ("Meteorology") - the location of the domain ontology (" - natural language description of the service and the service provider With this data, the tool gathered sufficient information for the import of the application ontologies and a user-friendly presentation of the concepts. The first step of the OWL parsing is to construct an Ontology model. To do this, the tool imports all application ontologies, whose URLs are given in the list of items returned by the WSDL parser. The D-6-3.doc Project Deliverable Page 21/72

22 imports are directly added to the model. The resulting ontology model includes therefore the concepts of the domain ontologies too, since those are imported internally by the application ontologies. The wizard does not present to the user all concepts of the model, but only the concepts resulted in of the WSDL parsing step. Each concept is added to the tree, as well as its super- and subconcepts. The Jena2 Java Framework (3) is used for the parsing and handling of OWL files. Jena2 is originally a library, to simplify the work with files written in RDF (4), on which OWL builds. Since Jena2 provides an RDFS reasoner, it has capabilities to work directly with the ontology model. The Jena 2 Inference subsystem currently comprises inference engines structured as graph and includes a number of predefined reasoners (5). One of the important tasks of the reasoner is to check RDFS closure rules by translating each domain range, sub property and sub concept declarations into a single query rewrite rule. The inference engine also supports rule based RDF (using both forward and backward chaining methods). However since the Rule based approach is computationally expensive in large or complex ontologies Jena also provides a description logic reasoner interface. However, this reasoner is still under development and therefore not yet applicable. In the SeDA tool, the right hand windowpane in step three (figure 5) presents the user information about relations of a concept which the user selected in the tree. The relations include taxonomic relations between the concepts, as well as non-taxonomic relations. These are mainly restrictions of the class properties. The information of the right field is drawn from the inference model, constructed by the RDFS reasoner. It allows displaying all statements where a class (concept) is used as subject of an RDF triple. The inference model improves the expressiveness of the ontology model and simplifies the analysis of the result. 4.4 context The Semantics-based Service Discovery Assistant offers improved UDDI (Universal Description, Discovery and Integration) based discovery of web services, and can therefore be of benefit to any current UDDI user. More specifically within, intended users of this tool are service developers who wish to build a composite service or service chain. These users do not need any deeper understanding of ontology engineering. However, current browsing of the ontology is done on a GUI that, at this time, still contains DL (description logic) statements and users would currently need to be able to read DL statements. 4.5 Assumptions made To be practically applicable, services registered in a UDDI have to be described by application ontologies, which in turn draw their semantics from domain ontologies. We assume these ontologies to exist. For proof of concept, application and domain ontologies were developed within the pilot ACE- GIS Emergency Management System (EMS). 4.6 References: (1) Visser, U. and H. Stuckenschmidt (2002). Interoperability in GIS - Enabling Technologies. 5th AGILE Conference on Geographic Information Science, Palma de Mallorca, Spain. (2) Xerces Java parser Documentation ( (3) Jena2- A Semantic Web Framework ( D-6-3.doc Project Deliverable Page 22/72

23 (4) Resource Description Framework (RDF) ( (5) Caroll J. J., et al (2004) Jena: Implementing the RDF Model and Syntax Specification, Conference, NY D-6-3.doc Project Deliverable Page 23/72

24 5 Appendix Table A1 lists all articles funded by the project. Complete copies are included only for the articles produced during phases III. Table A1: Articles funded by the project, those with page numbers were produced during phases III Articles Kuhn, W. (2003). Semantic Reference Systems. International Journal of Geographical Information Science 17 (5): Raubal, M. and W. Kuhn (2003). Implementing Semantic Reference Systems. AGILE th AGILE Conference on Geographic Information Science, Lyon, France, Presses Polytechniques et Universitaires Romandes. Probst, F. and M. Lutz (2004). Giving Meaning to GI Web Service Descriptions (extended abstract). 7th Conference on Geographic Information Science (AGILE 2004), Heraklion, Greece. Kuhn, W. (2004). Elements of a Computational Theory of Location. 7th Conference on Geographic Information Science (AGILE 2004), Heraklion, Crete. Raubal, M. and W. Kuhn (2004). Ontology-Based Task Simulation. Spatial Cognition and Computation 4 (1): Page Probst, F. and M. Lutz (2004). Giving Meaning to GI Web Service Descriptions. 2nd International Workshop on Web Services: Modeling, Architecture and Infrastructure (WSMAI-2004), Porto, Portugal. Schade, S., A. Sahlmann, M. Lutz, F. Probst and W. Kuhn (2004). Comparing Approaches for Semantic Service Description and Matchmaking (full paper). 3 rd International Conference on Ontologies, DataBases, and Applications of Semantics for Large Scale Information Systems 2 12 (ODBASE 2004), Larnaca, Cyprus. Probst, F. and W. Kuhn (2004). Localization with Image Schemas. Submitted to GIScinece, Washington, USA. Soon, K and Werner Kuhn (2004) Formalizing User Actions for Ontologies. 3 rd International Conference on Geographic Information Science (GIScience 2004), Maryland, USA. Probst, F., F. R. Gibotti, A. M. Prazos Morantes, M. A. Esbri, M. B. B. de Barros Filho, M. Gutierrez and W. Kuhn (2004). Connecting ISO and OGC Standards to the Semantic Web. Submitted to GIScience, Washington, USA D-6-3.doc Project Deliverable Page 24/72

25 Giving Meaning to GI Web Service Descriptions Florian Probst, and Michael Lutz Institute for Geoinformatics, Robert Koch Str , Münster, Germany {f.probst, Abstract. Composition of web services based on currently available descriptions such as WSDL is errorprone 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 semantically 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 geospatial 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 descriptions 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 descriptions In this paper we introduce the architecture for a three-level Semantic Reference System 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 1 is used to explain in which context we encountered and solved semantic problems: A service provider is about to build a composite service for the management of accidents involving toxic gas releases from a chemical plant. He builds the composite service starting with the 1 This scenario was developed in conjunction with the e-emergency composite service ( D-6-3.doc Project Deliverable Page 25/72

26 most specialized service 2 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 composite 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 polygon indicating the dispersion of the gas. The user chooses as next step to find an additional 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 ( 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 service composition. Each problem type is illustrated by relating it to the scenario given above (Fig. 2). 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 information about the wind direction. However, the labels of the data types containing the required information are different. The GlobalWeatherService refers to the information as prevailing_direction while the AirportWeatherService labels the information as wind. However, both elements represent the same (domain) concept of wind direction. This problem can be solved by annotating the elements used in the WSDL descriptions with concepts from an application ontology. The application concepts are always referenced to (or derived from) more general domain concepts. The reference includes additional restrictions on the properties of the domain concept, thus constraining 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 annotated symbols is the same. 2 To keep things simple, we assume that each web service has only one operation. We therefore use the terms web service and operation interchangeably D-6-3.doc Project Deliverable Page 26/72

27 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 different data types. The example given above is further complicated by a second source of heterogeneity. The GlobalWeatherService provides the wind direction information represented as a complex type labeled Direction. The AirportWeatherService provides this information contained in a String. However, both elements represent the same domain concept 3. 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 required information. How to semantically describe complex types such that these rules can be generated automatically from the descriptions will be a topic for future research. 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 AirportWeatherService as described above. And consider further that the CalculateGasDispersionService also requires wind information represented as a String. However, the CalculateGasDispersionService interprets the 3 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 D-6-3.doc Project Deliverable Page 27/72

28 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 introduces a 180-degree mismatch. This can lead to the creation of composite services that produce results not intended 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 operations 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 combined in a service chain. 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 relates 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 D-6-3.doc Project Deliverable Page 28/72

29 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 worldview explicit and presents it in a machine- interpretable 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 symbols such as wind are restricted via a set of relations to other symbols and by classifying the symbols in a subsumption hierarchy. In this way, the domain ontology restricts the meaning of a known symbol (term). Thus, while the domain ontology assigns meaning to a symbol by providing a conceptualization 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 referencing 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 Domain 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 different 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 Conceptual Level, references to image schemata, which are represented using similar methods, as employed for the domain ontologies will further reduce semantic ambiguity. These references will be based on nontaxonomic relations, avoiding the subsumption of domain concepts under image schemata. We intend to restrict the meaning 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 System, 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 application 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 D-6-3.doc Project Deliverable Page 29/72

30 for further restricting the meaning of domain ontology concepts. It is also possible to introduce concepts not contained in the domain 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 responsible for keeping updates of their ontologies consistent with prior versions. Extending 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 scenario. The ontologies containing these definitions can be found at 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 domain ontology concepts. The (yet incomplete) set of image schemata, their internal structure and how they can serve as semantic grounding level need further investigation. However, the possibility to break the vicious circle of defining concepts with other (undefined) concepts is appealing D-6-3.doc Project Deliverable Page 30/72

31 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 GlobalWeatherService to the CalculateGasDispersionService both would result in a 180-degree mismatch D-6-3.doc Project Deliverable Page 31/72

32 Fig. 5. Definition of two application ontology concepts representing two different conceptualization of wind direction The domain ontology concept plus the restrictions on its interpretation provide meaning 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 application ontology provides the service developer with a flexible means to restrict the meaning of the domain ontology concepts. Finding services using the same restrictions 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 D-6-3.doc Project Deliverable Page 32/72