CRUMPET. Creation of user-friendly mobile services personalised for tourism

Transcription

1 CRUMPET Creation of user-friendly mobile services personalised for tourism Project Number: Project Title: Deliverable Type: IST CRUMPET, Creation of User Friendly Mobile Services Personalised for Tourism P CEC Deliverable Number: Contractual Date of Delivery to CEC: 30/08/01 Actual Date of Delivery to CEC: Title of Deliverable: WP Contributing to Deliverable: Nature of Deliverable: Authors: IST /GMD/WP1/D1.5 XX/XX/2001 Smart Tourism Taxonomy WP1 Report Barbara Schmidt-Belz, and Achim Nick (Fraunhofer FIT), Steve Robertshaw (Emorphia), Alex Zipf (EML) Abstract: This deliverable describes and comments the tourism taxonomy developed in CRUMPET. The Taxonomy describes the content space, and clusters the objects of the domain in terms of their relation and their structure. CRUMPET has used the modelling methods UML, and OIL; we explain the reasons and benefits of both methods. This deliverable also describes how the taxonomy will be used by the different components of the CRUMPET system. The relation between the CRUMPET taxonomy and the reference model of IFITT is clarified. We finally report on our additional study to model services in DAML-S. Keyword List: taxonomy, tourism services, agent interaction, user interest modelling, service brokerage Copyright by Partners of CRUMPET

2 EXECUTIVE SUMMARY The overall aim of CRUMPET is to implement, validate, and trial tourism-related value-added services for nomadic users (across mobile and fixed networks). The services offered to the tourist, as an enduser, are realised by a multi agent system (MAS). A society of distributed agents, each with different roles and instantiated for a special user or event, takes care of the use cases and finally delivers the required service to the user. The exploited contents and other tourist services, such as maps, personalised sightseeing tours, or restaurant recommendations, shall be provided by local, heterogeneous business partners. As a precondition that users and agents and content providers will understand each other, i.e. interact in a sensible and reasonable way, they need a common taxonomy. For the application field, a taxonomy describes the content space, and clusters the objects of the domain in terms of their relation and their structure. For the taxonomy, the application domain has to be analysed in order to identify objects and relations relevant for services of the envisaged system. For the tourism domain, objects such as restaurant, events, sights, tours, and maps, have to be structured, and items of interest for information and communication have to be identified. The taxonomy will be used for inferences from user navigation in the physical and in the information space to adapt the information selection and presentation. The CRUMPET taxonomy has been modelled both in UML and in OIL. UML has been chosen as a widespread modelling standard, which also has the advantage of the availability of commercial tools offering a good graphical representation. We have furthermore encoded the taxonomy in OIL. This is one of the modern ontology modelling methods. OIL is also a close relative to OPAL, which is basis for the tool SymOntos developed and used in FETISH. As an additional study in the ontological approach to service interoperability, CRUMPET has used DAML-S to model an example service. The services deployed across the CRUMPET system can make good use of DAML-S, as the abstract notion of a service maps directly into the concept of the concrete tourism services that CRUMPET will deliver. It also maps onto the notion of intention, in the semantics of the FIPA formal model, upon which FIPA-OS is built. CRUMPET has developed a taxonomy that is "understood" by the currently involved content providers; it is basis of the agent communication, and it serves to instantiate the user interest model. The future scaling-up of CRUMPET in order to involve more providers of local content and other business partners can be achieved in several ways. The legacy systems could be wrapped by agents in a way that they use the CRUMPET taxonomy. The CRUMPET taxonomy should be elaborated in compliance with a standard, such as the reference model of IFITT. Or the interface between CRUMPET and legacy systems is supported by more sophisticated mechanisms that allow for a variety of taxonomies. Such mechanisms will be developed by the EU-funded IST projects FETISH and HARMONISE in the near future. Page 2 of 52

3 Table of contents 1 INTRODUCTION TAXONOMY OVERVIEW TOURIST DOMAIN MODEL DOCUMENTATION OF CONCEPTS AND RELATIONS THE DOMAIN MODEL OF USER INTERESTS GENERIC DOMAIN MODEL FOR INTEREST MODELLING AND SERVICE BROKERAGE DOCUMENTATION OF CONCEPTS AND RELATIONS CRUMPET TAXONOMY AND IFITT REFERENCE MODEL USING THE REFERENCE MODEL TO SPECIFY A NEW SERVICE EXAMPLE: ATTRACTION (REFERENCE MODEL) AND SIGHT (CRUMPET) MODELLING THE CRUMPET TAXONOMY WITH OIL MODELING SERVICES WITH DAML-S AGENT COMMUNICATION AND INTERFACE TO LOCAL SERVICES CONCLUSIONS REFERENCES ABBREVIATIONS GLOSSARY...10 APPENDIX A: ACL AGENT COMMUNICATION - EXAMPLE...10 APPENDIX B: OIL ENCODING OF CRUMPET TAXONOMY...10 APPENDIX C: DAML-S EXAMPLE OF SERVICE DESCRIPTION...10 CRUMPET-P-TOY.DAML...10 CRUMPET-PM-TOY.DAML...10 Page 3 of 52

4 1 INTRODUCTION The overall aim of CRUMPET [CRUMPET 2001a] is to implement, validate, and trial tourism-related value-added services for nomadic users (across mobile and fixed networks). The services offered to the tourist, as an end-user, are realised by a multi agent system (MAS). A society of distributed agents, each with different roles and instantiated for a special user or event, takes care of the use cases and finally delivers the required service to the user. The exploited contents and other tourist services, such as maps, personalised sight seeing tours, or restaurant recommendations, shall be provided by local, heterogeneous business partners. As a precondition that users and agents and content providers will understand each other, i.e. interact in a sensible and reasonable way, they need a common ontology. For the tourism domain, there is unfortunately no taxonomy standard available. The International Federation of Information Technology and Tourism has undertaken to develop a framework of tourism ontology, referred to as the RMSIG reference model [RMSIG 2001]. This has not yet become an accepted standard but has the potential to become one, at least for systems that need to interact with other systems, and therefore need to agree on interfaces and data exchange specification. IFITT and RMSIG will also play an essential role in the EU-funded IST project HARMONISE [HARMONISE 2001]. CRUMPET has contributed to the reviewing process of RMSIG reference model Versions 0.9 and 0.95, and is compliant with Version 1.0. We report this in chapter 4. A taxonomy standard can be used in different ways to make inhomogeneous legacy systems interoperable. The straightforward method is that legacy systems have to offer standard-compliant interfaces to their systems. More sophisticated approaches, originating in artificial intelligence ideas, ask for systems that can interpret "strange" ontologies and reason about them, and learn to refer to ontologies that have not been familiar to them hitherto. Realising this in a generic way would be a research and development challenge far beyond the scope of CRUMPET. The projects FETISH and HARMONISE have ambitions in that direction, but unfortunately both will achieve their results too late for CUMPET's timeline. CRUMPET is willing to contribute its taxonomy and services to FETISH and thus achieve a certain interoperability with other European tourist support systems. CRUMPET has developed a taxonomy that is "understood" by the currently involved content providers; it is used for agent communication, and for instantiation of the use interest model. The future scaling-up of CRUMPET to involve more local content providers and business partners can be achieved either by wrapping the legacy systems in a way that they understand the CRUMPET taxonomy, or by using mechanisms that will be developed by FETISH and HARMONISE in the near future. The CRUMPET taxonomy has been modelled both in UML and in OIL. UML has been chosen as a widespread modelling standard and because of its graphical representation. We have also encoded the taxonomy in OIL. This is one of the modern ontology modelling methods. OIL is also a close relative to OPAL, which is basis for the tool SymOntos developed and used in FETISH. As SymOntos was not ready and accessible in time for CRUMPET, we used OILed instead. We hope that no major transcoding problems will occur when eventually switching to SymOntos. This is reported in more detail in chapter 5. The CRUMPET taxonomy covers the contents space that is handled by the CRUMPET services. Therefore, it includes maps and restaurants, for instance. Another, additional, goal could have been to model the services themselves. This would have to include concepts such as request and retrieved information, also state of a process, for instance. This has not been necessary and required within the CRUMPET project. We have, however, gone a first step in that direction with respect to future agency implementation and our project's contribution to FETISH. We have studied an example of service description in DAML-S, which is reported in chapter 6. As a general precondition we show the agent architecture of CRUMPET in figure 1, see also [CRUMPET 2001b]. We will refer to this functional agent architecture whenever, in this deliverable, we refer to certain agents, their interaction and their use of the taxonomy. Page 4 of 52

5 Mobile device A/V Player CRUMPET Access Node HTML Browser GP S Wrapper Client- Agent Control Agent Monitor Agent P res entation Performer Monitor Agent Control Agent Wireless Transport Service Wireline Transport Service Wireless Transport Service Wireless connection Wireline connection Back-end Content Brokering Dialogue Controlling Broker Agent Dialogue Control Agent Service and Contents Wrapping Sights Agent Restauran t Agent Local Events Agent Environmental Modelling Tour Planner Agent Map Agent Localization Agent User Modelling User Modelling Agent GIS Wrapping GIS Server Agent Local Services & Contents Local GIS Servers User Models Web Service Sights Web Service Restaurants Web Service Cinemas Helsinki GIS Server London GIS Server Heidelberg GIS Server User M odel Server Figure 1 Agent Architecture in CRUMPET 2 TAXONOMY OVERVIEW The core of the CRUMPET tourism taxonomy is a conceptual view on the real world objects that are relevant for the CRUMPET services, the tourism services offered in CRUMPET, including information services concepts and semantics to relate information services with real world objects and tourism services. This core taxonomy is modelled in UML. UML has been chosen here because this standard is widely used and understood, and there are tools for a graphic representation of the model. The UML model is easy to inspect and understand for human readers, hence a good basis for documentation, further discussion, and elaboration of the model. This core model was basis for further elaboration for special needs in CRUMPET and has been encoded in other ontology modelling methods. The resulting additional parts of the CRUMPET taxonomies are The "domain model" which is basis of the user model, modelling the generic concepts of user modelling and information brokering. This "domain model" has been modelled in UML; the classes are implemented in Java and are constituents of the user-modelling agent UMA. Page 5 of 52

6 The core model has been encoded with the OIL methodology using OilEd as the editor and browser tool. OIL is a frame-based modelling language. CRUMPET has chosen OIL because it is similar to OPAL, and OPAL is basis for the FETISH integration framework. OPAL, unfortunately, was not accessible in time for the taxonomy development and encoding in CRUMPET. First examples of a CRUMPET service ontology using DAML-S. The current agent architecture of CRUMPET has predefined agent interfaces, which allow the agents to interact in a well-specified way. It has not been necessary so far to provide an ontology of the services of these agents. It is, however, an interesting research and integration issue to do so. CRUMPET has undertaken a first study in service description, using DAML-S, which would be an appropriate language for agent interaction. The result is included as an Appendix to this deliverable. The Deliverable 1.9 has specified the low-level data base structure available in CRUMPET. It has mainly been inspired by the legacy tourism database that is successfully in use at Heidelberg, which is the main CRUMPET trial site. Meanwhile a XML interface to access this content is realised. This interface is compatible with the CRUMPET core taxonomy, and has been included as an Appendix of this deliverable. In the rest of this first chapter, we document the core taxonomy, before we describe the other parts of the CRUMPET taxonomy and their respective use in CRUMPET. 2.1 Tourist domain model The tourist domain is modelled here with respect to information services that are offered to the tourist. Such information services may include very concrete services such as Restaurant and meal, but we explicitly did not undertake to model the tourism business in general. We also confined the model to services that do have relevance for the intended CRUMPET system. This model can, however, be extended to more services. In the following we successively introduce the model, explaining its components and the rationale behind it. Page 6 of 52

7 Figure 2 High-level concepts with relevance for information services, as part of the core taxonomy. Figure 2 shows mainly the relevance of InformationObject and Feature for the model. Service is one specialisation of DescribedObjects, i.e. an object about which there is one or more InformationObjects available. There are other specialisations of DescribedObjects. For CRUMPET, the concepts Person and HistoricEvent are relevant DescribedObjects with respect to the description of sights. Services are also ServiceTypes as it is mainly by types that services are offered, requested and brokered. In Figure 3 the Service and its specialistions in CRUMPET are shown in more detail. The services shown here are Sights and Events. There are several sorts of Events, such as Restaurant, FilmEvent and SpecialTour. This figure also shows that SpatialObject plays an important role in the taxonomy. Restaurant and Cinema and some others are SpatialObject. To distinguish such SpatialObject that are described by information objects and features from SpatialObject in general, we introduced the specialisation CRUMPETSpatialObject that is a SpatialObject and a DescribedObject. Page 7 of 52

8 Figure 3 ServiceTypes and SpatialObjects and their specialisations. In Figure 4 shows that part of the taxonomy that is closely related to SpatialObjects. There are mainly Map and Tour, that are the objects of CRUMPET services. A Map is the graphical representation of one or more spatial objects. Tours are aggregations of SpatialObjects, usually sequences with spatial objects as starting point and end point, respectively, and also a representation of the route as the connection between two spatial objects 1. The concept of a SpecialTour has been introduced to distinguish between a tour in general and a special tour for a tourist. The latter gets the character of an Event when it is offered for booking (guided tour) or when the tourist actually is on a sight seeing tour being supported by CRUMPET services. The concept of time has several relations to the other concepts, such as start and end of an event, or as a period of availability of events (opening time, e.g.). Usually, for the purpose of implementation, this would be captured as attributes of the other classes. We have modelled it as an interface of its own with relations to other concepts, for reasons of clarity. For similar reasons, we have explicitly modelled GeoCoordinates and Address as interfaces with diverse association relations to other concepts. Spatial objects need to relate to geo-co-ordinates (centre, or edge of bounding box, e.g.) so as to allow location-aware services. Some types of spatial object (restaurant, or cinema, e.g.) also have addresses, which is necessary to support location aware look-up services. 1 The route may also be a sequence of spatial objects, e.g., a sequnece of sections of streets that connect spatial objects A and B. Page 8 of 52

9 Figure 4 SpatialObjects and their diverse specialisations. Finally, the comprehensive view of these high-level concepts and their relations is given in Figure 5. Page 9 of 52

10 Figure 5 CRUMPET Taxonomy in overview. 2.2 Documentation of Concepts and Relations Address An Address is the postal address or other reference to known spatial objects such as buildings, streets, towns, areas, countries or the like. Address has the role of address in association relation with SpatialObject, [0,*] addresses for [1] spatial object. Cinema A Cinema is a place or institution where films are shown. Cinema is a CRUMPETSpatialObject (and, therefore, is a SpatialObject and is a ServiceType.) Cinema has the role of organiser in association relation with FilmEvent, [0,*] cinemas for [0,*] film events. Cinema is connected by association relation with Time (see Time). ServiceType An object that is classified by features, such as categories or keywords. All Objects that are services brokered in CRUMPET or subject to information services in CRUMPET need to be ServiceTypes. Unclassified objects cannot be retrieved upon a user's request, cannot be brokered, and cannot be covered by user interest modelling. Page 10 of 52

11 ServiceType has the role of classified-by in association relation with Feature, [1,*] classified objects are classified by [1,*] classifiers. Feature A Feature is a term that may serve for classification of objects. Examples would be the type of a service and special attributes of each object. Whether features are structured (like a thesaurus) or unstructured (like a flat list of catchwords), and whether they are predefined (like a fixed set of attribute values) or dynamically used at runtime (like a term in a full-text search), is not modelled here but left for implementation decisions. Feature has the role of classifies in association relation with ServiceTypes; [0,*] classifier classifies [1,*] service types. CrumpetSpatialObject A CrumpetSpatialObject is a SpatialObject and is a DescribedObject. As a SpatialObject it has a GeoCoordinate, or may be part of a Tour. Being a DescribedObject, there is at least one information object describing it. DescribedObject A DescribedObject is any object about which there exists at least one InformationObject. In essence, this has been introduced to stress the fact that only described objects can be subject to a CRUMPET service, i.e., to an information service. DescribedObject has the role of described-by in association relation with InformationObject, [0,*] described objects are described by [1,*] information objects. Event Event is a Service that has the character of an event, e.g., which has starting time and end time. Event is connected by association relation with Time (see Time). FilmEvent FilmEvent is an Event, meaning the performance of a certain film. As an event, it has begin and end time. By the association to a certain Cinema it has a venue. FilmEvent has the role of is-organised-by in association relation with Cinema, [0,*] film events are organised by [0,*] cinemas. GeoCoordinate The geographical co-ordinate of a point in physical space, referring to one of the standards for geo-coordinates. GeoCoordinate is a triple (x, y, z) indicating the longitude, latitude, and altitude of a point in physical space. GeoCoordinate has the role of end-point and starting-point in association relations with Tour, [1] co-ordinate being end-point or starting-point, respectively, for [0,*] tours. GeoCoordinate is connected by association relation with SpatialObject (see SpatialObject). Group Group is meant as a group of tourists. Some CRUMPET scenarios involve groups of tourists. Group has the role of is-aggregation-of in association relation with Tourist, [0,*] groups containing [1,*] tourists. HistoricEvent HistoricEvent is a DescribedObject. It is modelled here because it makes some CrunpetSpatialObject a Sight, i.e. a site worth being visited by tourists because of its historic relevance. HistoricEvent has the role of connected-with in association relation with Sight, [0,*] historic events being connected with [0,*] sights. HistoricEvent has the role of connected-with in association relation with Person, [0,*] historic events being connected with [0,*] persons. Page 11 of 52

12 InformationObject InformationObject is a piece of information, such as a text, a video-clip, or a picture in a database. InformationObject has the role of describes in association relation with DescribedObject, [1,*] information objects describing [1,*] described objects. Map A Map is the graphical representation of a set of spatial objects. Apart from this relation, the ontology of maps is not modelled here. Map has the role of consists-of in association relation with SpatialObject, [1,*] information objects describing [1,*] described objects. Meal Meal is included in this model because a restaurant has the character of an Event when someone takes a meal at this restaurant, and restaurants can be classified by the kind of meal they offer. Meal is connected by association relation with Restaurant (see Restaurant). Person Person is a DescribedObject. It is modelled here because it makes some CRUMPETSpatialObject a Sight, i.e. a site worth being visited by tourists because of its connection to an important person via a historic event. Person has the role of connected-with in association relation with HistoricEvent, [0,*] persons being connected with [0,*] historic events. Restaurant A Restaurant is a CRUMPETSpatialObject and is an Event. Restaurant is connected by association relation with Time (see Time). Service Service is a DescribedObject and is a ServiceType. Service covers several types of tourist services that are offered in CRUMPET. Note that the services as such are not modelled here, but Service has been introduced as a child of both DescribedObject and ServiceType. Sight Sight is a CrumnpetSpatialObject and is a Service. It is a spatial object that is supposed to be of interest for tourists, often because of its relation to some historic event or important person. Sight has the role of took-place-at in association relation with HistoricEvent, [0,*] historic events being connected with [0,*] sights. Sight is only indirectly related to Person, via its relation to historic events. SpatialObject A SpatialObject is a physical object in space, such as a building, a place, a mountain, or a whole town. It may also be a virtual object in space, such as a view. SpatialObject has an association relation with GeoCoordinate, each spatial object having [1,*] co-ordinates. SpatialObject has an association relation with Address, each spatial object having [0,*] addresses. SpatialObject has an association relation with Map (see Map). SpatialObject has an association relation with Tour (see Tour). SpecialTour SpecialTour is a Tour and is an Event. It has been introduced to distinguish tours in general from tours that have event character, i.e., that take place at a certain time and have certain participants. Page 12 of 52

13 SpecialTour has an association relation with Tourist (see Tourist). Time Time plays a role for several other objects. Time has an end-time and a begin-time association relation, respectively, with Tour (see Tour). Time has an end-time and a begin-time association relation, respectively, with Event (see Event). Tour A tour is a sequence of spatial objects, connected by a path 2. A tour may be predefined, such as a standard sight seeing tour in a town, or it can be personalised, such as a tour according to a tourist's personal interest, time and current location. Tour has role of includes by association relations with GeoCoordinate, [1,*] tours including [1,*] spatial objects. Tour has end-point and starting-point by association relations with GeoCoordinate, [1] coordinate being end-point or starting-point, respectively, for [0,*] tours. Tourist Tourist is a travelling human. Tourists are the users of CRUMPET services. Tourist has the role of is-member-of in association relation with Group, [0,*] groups containing [1,*] tourists. 3 THE DOMAIN MODEL OF USER INTERESTS The user modelling component in CRUMPET is based on a domain-independent concept of information and service brokering. The user interest is perceived as a domain specific interest. Therefore, for each domain that is included in the user interest model, a domain-specific model has to be created, before any user's interest concerning this domain can be automatically learned. In this chapter, the generic modelling concept is introduced and its use for user interest modelling is explained. User s Interest Model instantiate per user special Domain Model (sight seeing, e.g.) instantiate per domain Generic Domain Model for user interest modelling and information brokerage Figure 6 Use of generic domain model of user interest 2 The path is itself a sequence of spatial objects, such as sections of streets. Page 13 of 52

14 3.1 Generic domain model for interest modelling and service brokerage Figure 7 shows the generic concept of information and service brokering. DomainModel is the root class; the central class is Service. Note, that not Services are modelled but ServiceTypes; user interests as well as service brokering are mainly referring to types (or classes, categories, e.g.) rather than to services themselves (instances of services). Feature and Category supply the means to build service type-specific classifications 3, the equivalent to what is indicated as ServiceType in the tourist taxonomy. SingleItem is meant to model instances of services. InformationObject is meant to model information objects describing SingleItems. Some of the classes explicitly model relations between other classes 4. These are CategoriesForFeature, ItemRelationsByType, ServiceTypeRelation, ItemRelation, and SingleItemsByType. Figure 7 Generic concept of domain modelling for interest modelling and information brokering. 3 The classic realization of this could have been by keyword-attributes in a database, plus a thesaurus, i.e. a structured search index. 4 Alternatively, they could be modelled as relations, such as associations. Page 14 of 52

15 Type Level Feature has ServiceType CategoryForFeature SingleItemByType Instance Level Category CategoryOfFeature SingleItem Figure 8 Type and Instance Level in the generic Domain Model. 3.2 Documentation of Concepts and Relations CategoriesForFeature CategoriesForFeature relates Categories and Features, allowing for a structure of features over the set of all categories. For example, the Service "Hotel" could have the features "Quality" and "Equipment", and the categories for feature "Quality" could be "simple, economy, quality, luxury" while the categories for a feature "Equipment" could be "car parking, restaurant, bar, lounge, fitness". Category Categorie allows describing the items in the domain. The modelling of hierarchies of categories is essential for a rich, meaningful domain and interest model. DomainModel DomainModel is the root class (or container) of all domain models, allowing for several models for different domains. Feature Feature is the common concept to distinguish all ServiceTypes by attributes from the class Feature. InformationObject InformationObject allows to explicitly refer to information available describing SingelItems. Examples are Web pages about a hotel, or a video clip of a historic event in Heidelberg. ItemRelation ItemRelation relates certain clients and certain suppliers with respect to a certain SingleItem. For example,??? ItemRelationByType ItemRelationByType relates several ServiceTypes. ServiceType The concept of ServiceType is the central concept for interest modelling and information service brokerage. Examples for ServiceType could be hotel, sight seeing, or restaurant. The use of this concept is quite flexible, it allows to model interest in/brokerage of Hotels as well as interest in/brokerage of Hotel Reservation Services, for instance. Page 15 of 52

16 Single Item SingleItem allows to model single (instances of) services. Examples could be a certain concrete hotel, or a certain Hotel reservation service. SingleItemByType SingleItemByType allows building indexes of services according to service types. 4 CRUMPET TAXONOMY AND IFITT REFERENCE MODEL The International Federation for IT and Travel & Tourism (IFITT) aims at the promotion of the international discussion about information technologies in the field of tourism [IFITT 2000]. One of their activities is the development of a taxonomy standard, referred to as the reference model, which is developed by the reference model special interest group (RMSIG) within IFITT. The RMSIG reference model is currently available as version 1.0 [RMSIG 2001]. 4.1 Using the reference model to specify a new service The reference model aims at supporting concrete tourism services in modelling their service in a way that can be understood by other systems. For this purpose it offers several constructs that can be used to specify a new, concrete service. The reference model comprises the content space of tourism services, (such as accommodation, hotel, single room, and mode of payment) as well as services (e.g., booking) and processes (i.e. a single request to a service and its state). Concerning the content space, building blocks constitute the central part of the reference model. When modelling a special service in compliance with the reference model, it is recommended to reuse as many building blocks as are applicable for this service. It may be necessary to add such constructs that are not provided by the reference model. In this way, new concrete tourism services can be specified. The reuse of concepts that are defined in the reference model eases the understanding between all RMSIG-compliant services, while the single service's need to distinguish in certain features is satisfied. The reference model is modelled in UML, which has the advantages of graphical representation, mature tools for editing, and several import/export facilities to other modelling languages. Page 16 of 52

17 Figure 9: The elementary tourism services of the IFITT reference model. From the elementary services covered by the reference model the CRUMPET system will offer: Attraction.Sight Event.CulturalEvent Gastronomy A future CRUMPET system shall combine more of these elementary services, but this is not within the scope of the current project. The services covered by RMSIG reflect the point of view of tourism business, while the CRUMPET system has been designed from the point of view of the individual tourist and the destination city or area. CRUMPET services such as individualised maps, tours, or directions, are essential support for mobile users, but are missing in a business-biased view of tourism. Furthermore, a central point in the specification of the CRUMPET system is that services should be offered in a location-aware and personalised manner. Location awareness, personalization, and Page 17 of 52

18 integration are added values of CRUMPET, which could not be achieved by a mere combination of such elementary services. However, CRUMPET has to exploit such elementary services, which are referred to as "local service" or "legacy system". When the CRUMPET system scales up to different service types and more contents and service providers, it can further profit from the IFITT reference model for interface definitions. 4.2 Example: Attraction (reference model) and Sight (CRUMPET) The concepts of "Attraction" (reference model) and "Sight" (CRUMPET) may serve to illustrate the relation between the CRUMPET taxonomy and the IFITT reference model. Figure 10: the tourism service attraction of the IFITT reference model. "Attraction" in RMSIG and "Sight" in CRUMPET can be understood as being synonyms, but both concepts also differ in the semantics. An "Attraction" as seen in the reference model is mainly something that can be booked. The "PeriodOfTime" specifies the period of time for which an attraction can be booked, an "Attraction" may be composed of other attractions, and "Institution" is the business partner organising and selling this service. A "Sight" in CRUMPET is both a "Service" and a "SpatialObject", see figure 5. As a service, it is a DescribedObject and therefore described by information objects (e.g. a tourist can get information about a sight). As a SpatialObject, a sight has a location (i.e., address, geo co-ordinates), may be included in a tour, or highlighted in a map. Once the two terms "Attraction"[RMSIG] and "Sight [CRUMPET] are identified as being synonyms, they can inherit the semantics of both ontologies. Currently, there is no need to further harmonise the two ontologies, because their overlap is restricted to a few such synonyms and the structure of both is mutually exclusive; there are no seriously inhomogenities in concepts or structures. When the CRUMPET taxonomy is elaborated in the future to cover more tourist services or more types of services, it shall use the existing concepts and building blocks of the IFITT reference model. On the other hand, the reference model could be elaborated taking over some of the CRUMPET concepts, especially those concerning space and spatial objects. The CRUMPET taxonomy reflects the importance of spatial objects for tourist services, which goes beyond the needs of ecommerce. 5 MODELLING THE CRUMPET TAXONOMY WITH OIL We have also encoded the taxonomy in OIL [OIL 2000a]. This is one of the modern ontology modelling methods. OIL is also a close relative to OPAL, which is basis for the tool SymOntos developed and used in FETISH. As the tool SymOntos has not been available for CRUMPET in time, we chose OIL instead to model our taxonomy in a closely related modelling language, in order to prepare its future export to the FETISH system. Page 18 of 52

19 OIL Ontology Inference Layer is one of the first spin-offs of the EU-funded IST Key Action On-To- Knowledge [Ontoknowledge, 2001]. OIL is extensible, the language has been designed so that: It provides most of the modelling primitives commonly used in frame-based Ontologies. It has a simple, clean, and well-defined semantics based on Description Logic. Automated reasoning support (e.g., class consistency and subsumption checking) can be provided. The core of the OIL language is described in [OIL 2001b]. OIL unifies three important aspects provided by different communities: formal semantics and efficient reasoning support as provided by Description Logics, epistemologically rich modelling primitives as provided by the Frame community, and a standard proposal for syntactical exchange notations as provided by the Web community (XML and RDF). The encoding of the original UML model in OIL has set no problems at all. We chose the tool OILed to edit and maintain the CRUMPET taxonomy. OILed is freely available at The OIL encoded CRUMPET taxonomy is documented as Appendix B of this deliverable. 6 MODELING SERVICES WITH DAML-S The DAML Services arm of the DAML program 5 is developing a DAML-based Web Service Ontology (currently named DAML-S), as well as supporting tools and agent technology to enable automation of services on the Semantic Web. DAML-S supplies Web service providers with a core set of mark-up language constructs for describing the properties and capabilities of their Web services in unambiguous, computer-interpretable form. DAML-S mark-up of Web services will facilitate the automation of Web service tasks including automated Web service discovery, execution, interoperation, composition and execution monitoring. Following the layered approach to mark-up language development, the current version of DAML-S builds on top of DAML+OIL. The DAML project aims at making web-based resources available to software agents for automated reasoning and the retrieval of information based on conceptual association rather than mere keywords. In pursuing this goal, the DAML project brings the realisation of the Semantic Web one step further. DAML extends the RDF, and incorporates the OIL, models to enable the creation of ontologies for any domain. DAML also supports the instantiation of these ontologies through the description of resources, specifically web sites. Ontologies, in this context, have traditionally been domain specific information structures describing the relations between elements in the structure along with the nature of these relations. As the benefits of ecommerce activity continues to impact on the lifestyles of Internet users, the old static form of information presentation will evolve into dynamic services in the truest sense of dynamic. Web resources will eventually appear that allow software agents to effect some action or change in the world, such as selling a product or controlling a physical device. In order to properly operate in this kind of environment, agents need to be able to locate, select, employ, compose, and monitor services autonomously and automatically. This requires that an agent get computer-interpretable descriptions of both the service as well as the mechanisms through which it is accessed. The DAML-S initiative in the DAML project seeks to establish a framework within which these descriptions are given and shared. DAML-S will provide an upper level ontology for declaring and describing services. The ontology structuring mechanisms of DAML already provide the appropriate framework for this purpose. The services deployed across the CRUMPET system can make good use of the work being carried out under the DAML-S initiative as the abstract notion of a service maps directly into the concept of the concrete tourism services that CRUMPET will deliver. It also maps onto the notion of intention, in the 5 The Joint United States / European Union ad hoc Agent Markup Language Committee was created in October 2000 by Jim Hendler of DARPA and Hans Georg Stork of the European Union Information Society Technologies Programme (IST). Page 19 of 52

20 semantics of the FIPA formal model, upon which FIPA-OS is built. Services can be described as primitive and composite. Services are primitive in the sense that they invoke only an atomic process, sensor, or device that does not rely upon another process, with no ongoing interaction between the agent and the service being required beyond a simple response. In the CRUMPET system such a service could be one that returns an address or the geo-co-ordinates for longitude and latitude when given a postal code. Services can also be described as composite. Composite services are aggregations of multiple primitive services, often requiring an interaction or conversation between the user and the services, so that the user can make choices and provide information conditionally. In the CRUMPET system such a service could be the interaction required by a number of agents in order to recommend a tour of local sites. This interaction would include primitive services such as: obtain current location, search for nearby sites, compose list of sites, obtain user preferences, compare sites on sites list with user preferences, trim the sites list, obtain time constraint, generate maximum achievable routing distance, compare site locations with current location, generate distances between sites, generate possible routes, compare possible routes with maximum achievable route, trim sites list, and display possible tours. The DAML-S model follows very closely the FIPA Agent Management model and even extends it. The FIPA model requires that an agent must register itself with the AMS before it can become active on the platform; however, in order to be effective as a service provider, an agent must advertise its services by registering the services it can deploy with the DF. Under the DAML-S model, services are advertised through the propagation of a service profile that is lodged in a well-known location so that it can be found easily. DAML-S also provides a declarative interface to service invocation. In traditional agent implementations the function calls that execute the interactions, which manage the processing of a service, are implemented through traditional, procedural APIs. Through a declarative interface, DAML-S gives the agent ontological awareness of the service and how to interacted with it, allowing the agent to understand how the service works and to decide, independently, what input is necessary, what information will be returned, and how to execute the service automatically. FIPA defines a goal driven model of agent behaviour. Goals are high-level descriptions of performance requirements. Goals are presently achieved through explicitly defined interactions, between agents within a MAS community, or tasks that run within a single agent. This is something that requires skill and patience on the part of the agent developer in that the abilities of agents and requirements of the services that each agent can deploy must be assessed with regard to the semantics of the ACL. This activity results in the identification of a domain of discourse that is modelled as a separate entity from the knowledge base of any particular agent, lending an ontological structure to the knowledge shared within an agent community, and facilitating reasoning over requests for service invocation and deployment. DAML-S loosens the constraints placed upon agent developers in that the domain of discourse becomes less important to the architecture of MAS. Employing DAML-S decouples the composition of complex services from the domain of discourse and makes it a feature of an agent s internal reasoning mechanism. Thus agents decide for themselves what to do (and how to do it), rather than discussing what to do with other agents, in so far as the automatic selection, composition and interoperation of appropriate services are concerned. Now all that is required of the agent developer (in the context of procedural programming) is to define the transformation rules that describe legal actions on the processes within the application domain, through the normal algorithmic implementation methods. These rules will define, for instance, what composite services can be aggregated from the available atomic services, as well as any dependencies atomic services may place on each other. Finally, in the future, DAMLS-S will provide a service monitoring ontology to define a process status feedback mechanism that will compare the current performance of services against an agreed performance standard so that policy decisions can be made in support of achieving long-term goals. It can be seen, therefore, that the CRUMPET project could benefit in a number of ways from the DAML-S initiative; namely: 1. Service visibility. CRUMPET services would be meaningfully advertised. Services that are easy to find and to use will be favoured over others. This will make the CRUMPET system attractive to service providers. 2. Service discovery. CRUMPET services would be easy to find and richly described. This will lead to automatic service discovery and increased personalisation to the end user s requirements. This would increase the usefulness of the CRUMPET system and make it more attractive to (nomadic) end users Page 20 of 52

21 3. Service invocation. An automatic interpretation of CRUMPET services through agent level understanding of their processes will greatly enhance the system. Automated processes will improve service completion through reducing the required end user commitment level and, correspondingly, increasing the service provider completion/retention rates. 4. Service composition and interoperation. The provision of declarative specifications for the prerequisites and consequences of service composition increases the success of the atomic service aggregation action. Successful service composition is crucial for both service providers and end users alike. Automation of composition and successful interoperation of service components further reduces the access threshold to the CRUMPET system. 5. Service execution monitoring. The ability for a user to change their mind and interact with the CRUMPET system, at a high level, to alter the status of their request will increase end user retention through delivering a previously unachievable and presently unparalleled degree of flexibility. CRUMPET seeks to deploy services in support of nomadic users in the tourism domain. Many of the use cases drawn out of the design stages in the project have demonstrated a need to dynamically generate composite services from an aggregation of primitive services. DAML-S provides an upper level ontological model to support the development of a knowledge-based relational declaration of the services and processes in such environments. Adopting this approach will allow CRUMPET developers to concentrate on refining the system functionality rather than invest unnecessary efforts in the integration of such functionality. As the CRUMPET project aims at a more sophisticated, production quality, multi agent system, which is scalable to include more services than are currently integrated in the prototype CRUMPET system, we included a first effort to explicitly model services. DAML-S has been available since May 2001, as a Version 0.5 pre-release. It is planned that, at a minimum, the CRUMPET system will, through the introduction of a DAML-S definition of the FIPA Agent Management Ontology, support this declarative approach by exploiting DAML-S Service Profiles as df-descriptions, they will be posted to the FIPA-OS df and any other, CRUMPET specific, middle agents. Appendix B shows the example of a notional service description, resulting from this study. Furthermore, ways have been investigated and illustrated, in which CRUMPET services might be extended to add to those services proposed with middle agents that are able to reason in this manner, through the exploitation of DAML-S. CRUMPET-P-Toy is basically an advert (Service visibility) provided by a service provider to the CRUMPET System in order to advertise its services and to describe how the service can be processed. CRUMPET-PM-Toy is the description of the processes model (an Action Ontology) (Service invocation and Service composition and interoperation) which is allowed on the Service described in *P-Toy. Both CRUMPET-P-Toy and CRUMPET-PM-Toy are based on, but extend, the examples found at the DAML web site. Neither has been validated and they are provided only as examples of service definitions and process models. Their construction concentrated on illustrative use of the rich relations that DAML provides, rather than on sufficient or necessary completeness. 7 AGENT COMMUNICATION AND INTERFACE TO LOCAL SERVICES The Deliverable 1.9 has specified the low-level data base structure available in CRUMPET. It has mainly been inspired by the legacy tourism database that is successfully in use at Heidelberg, which is the main CRUMPET trial site. Meanwhile a XML interface to access this content is realised. In the MAS, however, these XML data schemes are not known. Instead, the local, legacy service is wrapped as an agent and communicates with the other agents using ACL. The taxonomy in CRUMPET is used at development time to specify agent interfaces in a homogeneous and efficient way. In this chapter we describe in more detail the CRUMPET taxonomy, particularly regarding agent needs. Gruber has described 5 conditions that should be satisfied in designing an ontology: Clarity, Coherence, Extendibility, Minimal Encoding Bias and Minimal Ontological Commitment [Gruber 1995]. Page 21 of 52

22 Gruber's conditions for Ontology design: 1. Clarity: An ontology should effectively communicate the intended meaning of defined terms. Definitions should be objective. All definitions should be documented with natural language. 2. Coherence: An ontology should sanction inferences that are consistent with the definitions. 3. Extendibility: An ontology should be designed to anticipate the uses of the shared vocabulary. It should offer a conceptual foundation for a range of anticipated tasks, and the representation should be crafted so that one can extend and specialise the ontology monotonically. 4. Minimal encoding bias: The conceptualisation should be specified at the knowledge level without depending on a particular symbol-level encoding. 5. Minimal Ontological Commitment: An ontology should require the minimal ontological commitment sufficient to support the intended knowledge sharing activities. Since ontological commitment is based on consistent use of vocabulary, ontological commitment can be minimised by specifying the weakest theory (allowing the most models) and defining only those terms that are essential to the communication of knowledge consistent with that theory. In CRUMPET, points 1, 4 and 5 are particularly important. Point 1 demonstrates that the terms communicated can have meaning that is deeper in one agent than another, i.e., not all agents need to speak a language that describes the structure of all of the databases in the system. All there is to do is define the terms (and agree on the highest useful conceptual definition) in the vocabulary that is common to all agents. Agents requiring the in depth meaning will have local access to the appropriate data structures. Point 4 shows how an XML schema cannot be an ontology as it is inherently language dependent. Developers in CRUMPET (Emorphia) are working on generic databinding mechanisms that should remove these syntactic issues away from agent developers. Point 5 is the important one. The CRUMPET ontology needs to be defined in the fewest possible terms. This increases computational tractability, flexibility and (makes practicable) decidability. If the CRUMPET ontology were too big agents would not be able to reason with it. Agents do not need to know every data element in a database and their associated relation tables, merely the concepts that associate the data elements together and their combinatorial axioms. It is up to the specialist agent (such as the "SightsAgent" or the "Restaurant Agent") to turn the conceptualised agent level query into the appropriate syntactic query on the database it manages, using its own deeper domain knowledge. All agent developers in CRUMPET currently use the example model in appendix A as a template to define a minimum domain of discourse (i.e., the data that needs to move around the system, not the data contained within system repositories) for all of the agents they own (a domain of discourse exists between a minimum of two communicating agents). That is done in compliance with the CRUMPET taxonomy and will finally result in the agent ontology to be used at runtime. 8 CONCLUSIONS The tourism taxonomy of CRUMPET has been developed to allow integration and exploitation of legacy systems providing tourism services to the CRUMPET system. It is also the basis for the agent interaction within the multi-agent system. Furthermore, it will - at least in principle - reflect in the user interface, though the taxonomy has been developed for technical purposes rather than to reflect human cognitive concepts. This taxonomy will be used to diverse goals in CRUMPET: At development time, it will ensure that agent development is based on and deals with compatible concepts and objects. This has so far been the most important goal. It serves for initialisation of the user model, which is domain-specific. Some of the agents, such as the broker (DCA) and the service wrapper agents, could base their interaction on an explicitly modelled ontology used at runtime. This is one of the more sophisticated and challenging developments in multi-agent systems. Page 22 of 52