Using Ontologies in Personalized Mobile Applications Norbert Weißenberg
Agnès Voisard
Rüdiger Gartmann
Fraunhofer ISST P.O.Box 52 01 30 44207 Dortmund, Germany +49 231 97677 306
Fraunhofer ISST and FU Berlin Mollstr. 1 10178 Berlin, Germany +49 30 243 06 413
Fraunhofer ISST P.O.Box 52 01 30 44207 Dortmund, Germany +49 231 97677 305
[email protected]
[email protected]
[email protected]
ABSTRACT Mobile devices such as personal digital assistants (PDAs) and mobile phones are in widespread use already today and converging to mobile smart phones. They enable the users to access a wide range of services and information without guiding them through their actual demands. Especially during mass events like the Olympic Games 2008 in Beijing - which was initially the context of our work - a large service space is expected to support all mobile visitors, being athletes, journalists, or spectators. Current approaches tackling such problems are location-based (i.e., location-based services), meaning that a user’s location is taken into consideration for service provision, and even contextaware, meaning that beyond location other characteristics of a user’s environment are taken into account. Such information obviously helps to deliver relevant information at the right time to the mobile users. Going one step further, a situation-aware system abstracts from the context dimensions by translating specific contexts into logical situations (such as being in the car, in a stadium). Even though many context frameworks have been introduced in the past few years, what is usually missing is the notion of characteristic features of contexts which are invariant during certain time intervals. We refer to such features as situations. Knowing the situation end users are in allows the system to better target the information to be delivered to them. This paper presents the main concepts developed for a platform named FLAME2008, which is able to support its mobile users with personalized situation-aware services in push and pull mode.
Categories and Subject Descriptors H.3.4 [Systems and Software]: Current awareness systems (selective dissemination of information--SDI), user profiles and alert services.
General Terms Design, Experimentation, Human Factors.
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. GIS'04, November 12-13, 2004, Washington, DC, USA. Copyright 2004 ACM 1-58113-979-9/04/0011...$5.00.
Keywords Ontology, Inference, Mobile Application, Service, User Profile, Context, Situation.
1. INTRODUCTION The Internet has established itself as a communication and service medium even on the consumer level. Current and next generation wireless communication technologies (e.g., WLAN, UMTS) will foster the penetration of the Internet towards mobile use via a broad range of devices. In parallel the progress on Web service technology will lead to the global availability of services and to the ability to compose services from various sources into a more complex one. This leads to the availability of information and service anywhere at any time. To provide customers in general and mobile users in particular with an acceptable and affordable set of information and services the offered set must be custom-tailored to the individual needs. During the Olympic Games in Beijing, hundreds of thousands of foreigners - being athletes, spectators, or team staff - have to cope with information gathering on competitions, transportation, shopping, or sightseeing, with individual demands regarding language, Olympic disciplines, personal needs, and preferences. A broad range of electronic services will be available provided by Olympic or public authorities and private firms in Beijing, China and abroad. To navigate within such a large service space a user needs assistance. The basis of our work to support mobile users in such scenarios is given by the development of FLAME2008, a prototype of an integration platform for intelligent personalized Web services for the Olympics 2008 in Beijing. The development of FLAME20081 is the first joint project within SiGSIT (Sino-German Joint Laboratory of Software Integration Technologies, www.sigsit.org), a joint undertaking of the German Fraunhofer Institute for Software Engineering and Systems Engineering ISST, Berlin/Dortmund, and the Chinese Institute of Computing Technology ICT, Beijing. One approach to service customization is the use of information on the individual situation and personal demands when determining the appropriate set from the vast offer of Web-based information and services already available today. To enable a flexible
1
This project started in Q4/2002, supported by the German Ministry of Education and Research (BMBF Grant No. 01AK055).
selection on a semantic level, semantic descriptions of situations and offered services are needed. Location-based services (LBS) [26] aim at providing users with information related to a particular location. Typical applications include navigation systems or yellow maps (A combination of yellow pages and maps). A representative LBS query is “Return the nearest gas station from here”. LBS typically give a general framework in which further aspects are developed in order to meet users’ needs. In both mobile and static applications, user profiles are usually defined in specific ways, depending on the application. A wellknown, simple user profile is a vCard [30] – that is, a signaturelike collection of information related to users. A more complex type of profile is that of the security group of the WWW consortium, P3P [33]. However, it handles attributes that are not of interest in our FLAME application. A few approaches have been proposed in the area of location-based services, among them [1], which is an XML-based approach. In the area of tourism many profile definitions exist and we can cite for instance the approach described in [7] for personalized city tours. As far as contexts are concerned, many approaches were proposed, such as [5] and [12]. The situation model used here is described in [20]. It is based on a model of abstraction from sensor data to more semantic situations of the users in order to better match their demand in a precise situation. Many context-aware frameworks have been introduced in the past few years. What is missing, however, in most current approaches is the notion of characteristic “features” of contexts that are invariant during certain time intervals which we call situations. There are approaches that use so-called situation ontologies, e.g., [27], however, this is a simple context ontology in our view, covering also social context and device characteristics, but currently no reasoning. In [10] a context-aware middleware named SCAM is described, which already separates direct low-level context obtained from physical sensors (or set by users) from high-level context derived (by aggregation and reasoning) by a context interpreter based on an ontology. This approach is quite similar to ours, however, the authors intend context interpretation on mobile thin clients which cannot perform deep reasoning.
2.1 Objectives of FLAME2008 FLAME2008 [15] [9] is an approach for a Web-based information system intended for large user groups and large service sets. Typical examples of such applications are European or World Championships like the Olympic Games 2008, World Exhibitions, international fairs or cultural sites, which all attract hundreds of thousands or even million of visitors from many countries. Users should be served according to their demands, which is a prerequisite for the acceptance of such services and the underlying communication media. User acceptance on the other hand is crucial for the generation of revenue streams for service and communication providers. The main idea of FLAME2008 supporting this objective is an individual push of meaningful offers (pull possibilities) for information and services to the mobile frontend, based on the current situation and profile of each user. The situation is derived by information from different sensors and also user profile information is taken into account. This mechanism is based on offers and demands, which are matched by semantic technologies. Concerning the offer, service providers may describe (or use existing) situation profiles and then may bind their services to these situations. Both situations and services are described semantically, but the descriptions are profile-based, consisting of a set of structured attributes characterizing the situation or service using semantic categories. This means that the values for these attributes are taken from a set of semantic concepts and their instantiations in the ontology. As far as the demand is concerned, each user may maintain his/her user profile, consisting of a set of properties characterizing the user. Moreover, there are sensors, which obtain information concerning the user’s current environment, e.g., his location and the current time (many other sensors are also possible). Sensor data and user profile information are fed to the inference engine on-demand, they are accessed by logic predicates, returned as their parameters and abstracted by axioms which may also make use of external services. The resulting higher-level ontology instances are then used to implicitly construct a situation request profile being semantically matched with the profiles of all situations known by the system, and finally a service request profile is constructed implicitly and similarly matched to all registered service profiles. Thus we have two similar semantic matches, performed by a powerful inference engine: first situations, then services.
This paper is structured as follows. We first (Section 2) sketch the current FLAME2008 system, i.e., its objectives and architecture, before we go into some details. In Section 3, user profile and context concepts are discussed, as well as the way situations can in principle be derived from them. A modular ontology is needed for this purpose, and its architecture as well as the design of some main sub-ontologies are discussed in Section 4. We then (Section 5) describe how the ontologies are used to reach the objectives of FLAME2008: user profile and context data are accessed to instantiate the concepts of the ontology and enable the inference engine to derive situations for the user and to adapt the services offered at his/her mobile frontend according to his/her preference and his/her context-based actual situations. A conclusion follows in Section 6.
2.2 Architecture of FLAME2008
2. THE FLAME2008 PROTOTYPE
The FLAME2008 architecture is depicted in Figure 1. The FLAME2008 framework consists of a set of servers, namely:
FLAME2008 is a prototype integration platform for intelligent personalized Web services, intended for the Olympics 2008 in Beijing. Before discussing some technical aspects of the platform, we sketch its objectives and architecture.
All resulting services and information are then pushed to the user’s mobile device. About 80 demonstration services are currently available, mostly taken from the Web. They were registered with their main semantic metadata, and most of them were bound to different situations. These services exemplarily cover all basic, planning and situation-dependent needs of typical users in the demonstration scenario.
• An information-logistics engine, which implements the personalized push and pull mechanisms for information and service offers, based on semantic matching,
• a semantic registry and a situation detection component, which both use an inference engine and which are used by the service matching component, • a user profile component and a context component, which provide actual user-specific information especially for situation detection.
Figure 2. ER diagram of the user model Figure 1. FLAME2008 2008 system architecture On the client side, the users have a choice between using a smart phone with a Web browser (e.g., a SonyEricsson P800/900 with Opera browser), or a standard PDA with Windows Pocket PC™ operating system (e.g., iPAQ™ or Toshiba™), where special frontend components were installed which support e.g., dynamic menu generation, pop-ups and tickers, client side data storage and an intelligent data synchronization, intelligent power management and connection management. The functionality provided also includes an ontology browser with integrated semantic query functionality. Most sensors will also be placed at the end device, for instance, a user’s position can be determined by GPS sensor.
3. PERSONALISATION AND SITUATIONAWARENESS IN FLAME2008 A precondition for user-centric information services is a personalization of the information and services delivered to the mobile frontend. This implies the availability of user profiles as a basis. Such a profile consists of basic data like name and address, individual interests and preferences. This is a well-established approach for personalization.
As we can see from Figure 2, associated with a user are an identifier, an address book, a calendar, a profile, a situation, and a history. Relationships with other users are for the moment not described. On Figure 2, only one user is considered as we concentrate here on the demand of users taken individually. The identifier is unique for each user and will be used by the application (note the difference with some kind of National ID). Associated with each user is an address book. Even though the possible (entity-) relationships and interaction with other users are not detailed here, it is clear that basic information regarding communication partners needs to be stored in such applications. The calendar contains what the mobile user plans to do. This will be used in particular to anticipate situations hence anticipate the demand in terms of services (e.g., getting notified if the plane he or she planned to take is delayed). The first three entities are not detailed further here as they are pretty straightforward. The last ones, namely user profile, situation, and history, are described below.
Going one step further, context-specific demands of the user are taken into account [6]. Typical context information is a user’s location and the actual time. Location-based services are typically based on such context information [12]. We extend this approach by deriving the situation a user is in from the actual context information and additional context-related information sources like the user’s context history, for instance [20]. Hence, instead of knowing that a user is at location X we derive that he is riding on a bus or dining in a restaurant, for instance. Thus, by situationawareness a much higher precision of information and service offerings is possible.
3.1 Describing users Figure 2 depicts the entity-relationship diagram of our general user model.
Figure 3. Personal data
3.1.1 User Profile User Profile is the entity central to personalization. Looking back at Figure 2, the user profile is made of Personal data, Interests, and Preferences, which are detailed below. In our model all this information is visible from the application. A way to hide some information in order to insure privacy would be to associate a visibility Boolean with all the attributes. This is not our focus here.
3.1.1.1 Personal Data Personal data is made of static attributes and pseudo-static attributes, as depicted in Figure 3. The former do not – or are not likely to - change over time or during a period of time considered as valid2. They include a name of an address.
3.1.1.2 Interests Interests are application specific. In our application, for instance interests are of four kinds, extracted from the domain ontologies: Olympics, Shopping, Sightseeing, and Entertainment, as illustrated in Figure 4. Users interested in such topics and sub-topics can subscribe to them.
Figure 4. User interests
3.1.1.3 Preferences Preference of users in general is a rich notion. For simplification purposes we make the distinction between simple and complex preferences. Let us take an example. An end user would prefer for instance Italian or French food when he or she goes to the restaurant. This can be expressed as a simple preference. On the other hand she may prefer local food when she travels, and the French or Italian, as usual. The condition “when she travels” is related to the situation of the individual. It is what we refer to as complex preference. Another example of complex preferences is someone who would prefer an aisle seat if the plane is full and a window seat if the plane is not full. Such choices depend on external factors, which are not directly related to the users. A last example is that of complex preferences that depend on other individuals. For instance, Juliet prefers to communicate with her cell phone in general provided that her friends also have a cell phone and that she is in the country where she registered her phone.
2
Of course a period of validity for such attributes is applicationdependent. A highly-dynamic application will consider a shorter validation time than a more static one.
As we can see from these examples, such preferences are structured, complex, and might depend on many factors that range from one’s own location to a friend’s situation. This aspect is not detailed here. For the moment, we related “complex preference” and “situation” entities through a “related to” relationship and a tertiary entity, “condition”, not considered further at this point. Note the difference between interests and preferences. Interests are static and defined in advance for an application. Preferences may depend on the situation the user is in and on external factors such as a particular schedule. Situations themselves depend in particular on the (current) location and time (see further).
3.1.2 History Figure 5 depicts the notion of history, which is made of • A pair location/time (denoted “fact” in the diagram), • The information/service that was either asked or delivered at a certain location/time.
Figure 5. User history
3.2 Contexts and Situations As opposed to user profiles, contexts are dynamic. They are extracted from sensors and help to identify in which situation a user might be at a certain time. A situation is a complex notion that may be seen at different granularities. Context awareness and context sensitivity have become trendy topics with the emergence of mobile applications. We consider context as a set of parameters that influence a user’s situation, e.g., location, time, temperature. All these factors have a given value at a certain state. Following this definition the range of possible contexts forms an n-dimensional space, in which each factor forms one dimension within that space. Since a context is a kind of snapshot of those dimensions at a certain time, it can be regarded as a point within the context space. The critical information that eventually leads to an evaluation of a user’s needs is not the raw context data. It is in fact the situation a user currently is in. He/she might be driving a car, for instance, and therefore changing his/her context all the time. However, the situation “Driving a car” will not change during a certain time interval and one can describe a demand that occurs in this situation.
Following this assumption, in our approach we separate clearly contexts from situations and in particular we use a three-level approach, as follows:
tion dimension, e.g., one can be at the crossing of streets Wukesong Lu and Fucheng Lu in Beijing / in the Haidian district of Beijing / in Beijing / in China.
• A first level, at the bottom, is made of sensor values, such as the precise location of the user or a temperature.
The combination of these two aspects – multi dimensions and levels of granularity – allows us to consider rich collections of situations associated with one mobile user at a given time. A concrete model to represent situations is introduced in Section 4.5.2, together with some samples.
• A second level derives the context of the user, for instance, a geographic region the user is in (which allows one to derive the surroundings of the user) or a range of temperature. • A third level of abstraction is the situation level, which deals with the high levels of the systems and helps us to target precisely – and at different levels of granularity – the demand of the user at a certain time. Context variables are commonly used to express a subset of the universe. When they are instantiated they give a state of the universe according to some relevant factors (or characteristics). A context is an instantiation of context variables at a certain point in time. A characteristic feature is a property of a context that is invariant over a certain period of time. It can be expressed as a logical expression, such as LocationOfTheUser (Stadium), TemperatureCharacteristics (Warm), TypeOfMovement (Fast)
An expression such as TypeOfMovement above is a characteristic feature. It is derived from a sensor value (speed) following a certain interpretation. It stays constant over a certain time interval. If the speed decreases, then the TypeOfMovement will not be ‘fast’ anymore and the value of the characteristic feature will change from ‘fast’ to, e.g., ‘constant’. The mapping between context variables (e.g., speed) and characteristic features is made through aggregation rules and generalization/specification relationships. This means that one characteristic feature may be inferred from another one. For instance, if we know that a certain event takes place on a Saturday we can infer that it takes place on the weekend; or if someone is at location (x1, y1) then he is in a particular area, in a particular street/city and so on. In order to handle this aspect, subsume relationships are of prime importance. The notion of context encompasses many dimensions, such as time, location, activity, kind of movement as above, which should be handled separately. A dimension can be viewed as a type of characteristic feature and can be used in conjunction with common ontologies. At a more abstract level, a situation is formed by a sequence of contexts with invariant characteristics, e.g., S = (t1, t2, cs), with • t1: starting time of the situation • t2: end time of the situation • cs: a set of characteristic features that are invariant through the time interval, but may also include a time characterization. This definition allows us to describe precise situations of mobile users, e.g., “at the office”, “on Metro Line 1”, “on the phone”. At this point, two remarks are noteworthy: • The notion of situation can consider many dimensions at the same time – for instance, one can be both walking in the street and on the phone. • Through the associated generalization/specialization concepts different levels of granularity may be considered. For the loca-
Situations are manipulated through operators, which are defined as a collection of situation operators, but also rely on operators on characteristics. The main operators on characteristics are generalize (subsumption), fulfills (matching), and compare (similarity computation). Operators on situations are previous, next, and combine. For more information on the algebra the reader is reported to [20].
4. ONTOLOGIES IN FLAME2008 This section gives a short introduction to ontologies and inference and discusses the ontology architecture as well as some of its subontologies.
4.1 Ontologies and Inference Today, semantic technologies based on ontologies and inference are considered as a promising means towards the development of the Semantic Web. The original meaning of ontology is the study of being as a branch of philosophy. In information science an ontology is a knowledge model that describes a domain of interest with semantic detail and structure. The most prominent definition is an explicit formal specification of a shared conceptualization [2], meaning that the ontology is completely defined using a formal notation automatically interpretable by machines, and that the conceptualization should be shared by a group. A formal ontology consists of: • facts representing explicit knowledge, consisting of concepts, their properties (which can be subdivided into scalar attributes and non-scalar relations), and instances that represent entities described by concepts; and • axioms and predicates representing implicit knowledge, by rules used to add semantics and to derive knowledge from facts on demand. They represent the main add-ons to conventional information models like ER models and UML models. Although the most difficult part of ontology design is the conceptual structure, the ontology by itself is of minor value if there are no methods defined on it. Inference is an important method on ontologies: the axioms are used to derive implicit knowledge from facts on demand. Therefore the representation of the ontology should be such that inference is supported, e.g., by a language supporting the notation of axioms and rules. There are various ontology languages. The new W3C standard OWL [32] currently has no defined rule language and no query language. Since for our purpose we build on deep inference, F(rame)-Logic [18][23] is primarily used, being a very clear and powerful deductive, objectoriented ontology language which even supports expressing rules and queries. It also is the primary language of the Ontoprise OntoBroker® inference engine [24] used, and the facts part and some rule patterns can in principle be converted to and from OWL.
4.2 Ontology Architecture According to Guarino [11], an ontology can be structured into different sub-ontologies as depicted in Figure 6: • The upper or top-level ontology is limited to generic and abstract concepts, independent of and thus addressing a broad range of application domains. It covers reusable dimensions like location, time and content. • Domain ontologies specify concepts of different application domains (e.g., sports, tourism). • Task ontologies are similar, but contain knowledge about the usage of domain ontologies. • The application ontology at the lowest level in inheritance view combines, integrates and extends all sub-ontologies for the application. Moreover there are meta ontologies with general axioms and predicates supporting access to ontology meta data, as e.g., needed by an ontology browser. Most ontologies developed on each level are based on standards as far as possible, namely ontology pre-standards and metadata standards. In contrast to [31] where a first version of the ontology design was described, we no more use separate ontologies for standards like ISO 19115 (geo metadata [16]) and ISO 19119 (geo services [17]), but our location and service ontologies were influenced by these standards and may be refined accordingly. We now briefly discuss the main sub-ontologies. u p p e r:
D u b lin C o re (C o n ten t)
L o catio n
O W L -T im e
d o m a in o n to lo g ies :
ta sk o n to lo g ies: O W L -S (W eb S erv ice )
S p o rts
T o u ris m
W eath er
P u b lic T ran sp o rt
S itu a tio n s
ap p lic atio n o n to lo g y
Figure 6. FLAME2008’s modular ontology architecture
4.3 Upper Ontologies Existing upper or top-level ontologies like OpenCyc [3] and SUMO [21] are too huge for our scenarios. So we kept it simple, concentrating on the main aspects of time, location and content here, which are seen as the main dimensions of information logistics [4]. Refinements can be done in domain and task ontologies. The upper ontologies have been developed in cooperation with the ICT in Beijing.
4.3.1 Location Ontology For mobile applications, the location aspect is of utmost importance, and the use of ontologies for this purpose has been long-
praised (e.g., [8] summarizes several such approaches). The toplevel location ontology, however, is not a complete geo ontology, but provides basic concepts which may be refined in (geo) domain ontologies. In our location ontology, there are concepts at two layers, the logical cognitive location concepts and their lower-level geographic extent. The root concept of the logical layer is LocationName with sub-concepts like Continent, Country and AdministrativeArea, the latter having sub-concepts like State, City and District with special consideration of Chinese peculiarities, where problems of semantic vagueness as described e.g., in [28] may already arise. Multiple inheritance is used e.g., to model Muncipalities, being a city and state at the same time. Moreover there is an open category LocationWithAddress, which is supposed to be refined in different domain ontologies. Our Olympic ontology refines it into a hierarchy of different sports sites, while the tourism ontology adds sub-concepts like POI (point of interest), Hotel and Restaurant. Besides conceptual inheritance there are relationships of the following main kinds: instantiation, spatial containment and mapping. For spatial containment the transitive in relationship is inherited to all location concepts, but may be restricted in range by subclasses, e.g., that any City is located in a Country. When instantiating the higher-level concepts, they are mapped to GeographicExtents, e.g., a Restaurant instance is mapped to a Box instance with certain coordinates. Thus the lower-level concept GeographicExtent consists of subconcepts like Point, Box and Polygon, described by some coordinate system. Different geographic relationships like containment and overlapping are defined on these, implemented by axioms which use predicates written in Java, which themselves may make use of (geo) Web services. Using these relationships at the lower level, the corresponding relationship for the higher level instances can be inferred, and even a gazetteer service [22] can be implemented by using axioms. The ontology language used even allows to add parameterized methods to concepts, e.g., to derive the distance between two location instances. Inference may additional be essential for obtaining a logical location for a mobile user, when his physical position cannot be determined directly. E.g., for in-house positions of a user his logic location can only be derived, based e.g., on the last GPS positions known for the user. In [13], a quite similar ontology is described, which also has two levels: GeographicFeature corresponds to our LocationEntity, with sub-concepts like State and City (and many more, but no taxonomy) and SpatialDescription corresponds to our GeographicExtent, with sub-concepts like Point and Polygon. However, they use OWL (which currently has only limited rule support) and a simpler inference engine, thus all geographic relations are implemented externally.
4.3.2 Time Ontology For defining temporal aspects of services and situations a time ontology is needed, e.g., to define their temporal extents and to reason about them. Our time ontology is structured similar to the location ontology, both having an abstract and a physical layer. The mapping between both is analogously done by a ‘time gazetteer service’ implemented by axioms and predicates, which abstracts a time point to a set of periodic intervals.
The lower physical layer is a subset of OWL-Time [14], which consists of the TemporalObject sub-concepts Instant (a time point) and Interval, together with their basic relationships like after and before. Moreover there are special Interval concepts like Year, Month, Day and Minute, which may be instantiated to reflect a concrete interval of that length. The additional abstract layer consists of concept PeriodicInterval with sub-concepts like Yearly and Daily. E.g., the Yearly subconcept aMonth is instantiated by July, representing the month occurring every year, not a concrete month. The abstract layer moreover provides sub-concepts like Weekday, Monday, Morning, Sunrise, Daytime and Lunchtime. The instantiations of these concepts may even depend on a user‘s context/location (e.g., Sunrise) and/or on a user’s profile (e.g., Lunchtime). While the lower level of our time ontology is OWL-Time, the higher level (PeriodicInterval) is a simplification of concept CalendarDescription, found in some versions of OWL-Time. In the OpenCyc upper ontology [3] it is called RegularlyRepeatedEvent.
4.3.3 Content Ontology When looking at public UDDI [29] business registries today, there are only a few services registered. Additionally, Web service directories like SalCentral (www.salcentral.com) or Xmethods (www.xmethods.com) list many Web services, but only few of them are useful in our scenarios. Thus today, our scenarios cannot be covered by using only Web services, and we decided to also treat Web content as a kind of service. In our view a service is special content. Normal content may not have properties like input/precondition/effect, but most other properties from an extended OWL-S profile [25], like name, description, provider, date, geographicRadius. Inversely, content may be seen as a constant service (or better a parameter-less service, since it need not be constant, but the page may be dynamic). A content page (which then is a client of a service) may even have parameters, e.g., the zip code input field of a weather page, which can be submitted using html post/get. Of course this is not Web service technology, but may be seen as a service. For the content dimension Qualified Dublin Core [19] is often used, providing access to information and services at document metadata level. Declaring OWL-S service profile properties as sub-properties of Dublin Core properties has three advantages: the semantics of OWL-S properties becomes more defined, some OWL-S properties can be accessed by standard Dublin Core names, and services can be treated as special content, having content properties and service-specific properties. E.g., property textDescription of OWL-S is a special qdc:abstract (which is a special dc:description), serviceCategory is a special dc:subject (but a separate dc:subject property is also meaningful in a service profile), and geographicRegion is a qdc:spatial. This requires a Dublin Core ontology with object properties, not string-valued properties. As for time and location, also for the content dimension a separation of two layers might be meaningful, where e.g., a textual description is abstracted by text mining to some keywords or subjects being semantic categories.
4.4 Domain Ontologies The modular ontology is open for different domain ontologies to be added. Currently we have an extensive Olympia ontology,
which refines the location ontology by a hierarchy of sport site concepts and instances, and also focuses on knowledge about Olympic disciplines and schedules. Moreover there is a basic tourism ontology with some points of interests, restaurants, hotels and the like. The domain ontologies are mainly used as value pool for different properties in all other ontologies. Moreover the domain ontologies are of focal interest for ontology browsing and semantic queries on the mobile frontends. The facts for the domain ontologies may be imported on demand from data bases.
4.5 Task Ontologies The main task ontologies are a service and a situation ontology. Due to lack of space we concentrate on the situation ontology here, since it is the major factor for realizing personalized situation-aware applications.
4.5.1 Service Ontology Our service ontology is based on OWL-S [25], a pre-standard of a Web service ontology, consisting of three sub-ontologies: a profile for advertising and finding services, a process model for describing how different service steps cooperate, and a grounding supporting service execution. We extended its profile subontology by situation properties, and additional time, quality, cost, language properties which partially stem from the ISO 19119 geo service standard [17]. New service profile instances for describing additional services can easily be added.
4.5.2 Situation Ontology Situations are described by semantic situation profiles. They are determined by a semantic classification of an aggregate of abstracted user context, user profile and related information and thus can be inferred from these. At a given time, a user may be in 0, one or many situation known by the system. Situation detection requires a modular ontology with sub-ontologies for all the different context dimensions (like time and location), all combined in the situation ontology. Thus the situation ontology extensively builds and depends on its dimension ontologies. It consists of a hierarchy of situation profile concepts, which may be instantiated to characterize different situations. The top level situation profile concept only aggregates a time and a location dimension, i.e., it has two such properties. In simple F-Logic notation this is: Situation [
position time
=>> loc#Location; =>> time#Interval].
This describes the concept signature, having two multi-valued properties characterizing the location and time aspects of situations. Here loc and time are namespaces for the different dimension ontologies. From this concept more specific situation profiles with arbitrary additional dimensions may be derived as subconcepts (by an expert user to adapt FLAME2008 to a new application domain). For each dimension there may be a separate ontology, e.g., a calendar ontology and an action ontology if user calendar states and access to current local actions are added as new dimensions to the situation model, as follows: UserSituation :: Situation [ userState =>> cal#CalenderState; localAction =>> act#Action].
Together with the new situation profile concept some rules need to be provided which feed the new situation request slots with abstracted context and/or user data, and possibly the semantic
matching rules have to be extended as well. Additionally there may be taxonomic refinements of situation profiles: BeingAtEvent :: UserSituation. Sightseeing :: UserSituation.
Besides the inheritance relationship between situation profiles there may be other relations between situations: e.g., situations can be related by axioms to all other situations which may be valid at the same time or at the same location. Moreover the previous situation of a user may be recorded and provided by a relationship, and possible future situations may be derived by axioms. All these relationships can be used to improve the semantic matching and to find similar situations.
5. USING ONTOLOGIES FOR SITUATION-BASED SERVICE SELECTION We now describe how user profile and user context are combined using ontologies to infer first a set of situations and then a set of services which may be relevant in these situations for this user. As a basis, situations and services have to be described by profiles, which will be sketched for situations. Whenever a significant change in sensor data is detected for a user, his service space is re-evaluated, using the situation detection and service matching functionalities of the semantic registry. The new service menus are finally transferred to the user’s PDA or are available from the smartphone Web server.
5.1 Describing Situations Whenever non-expert users are intended to enter some descriptions to the system, FLAME2008 uses profiles, i.e., a set of structured attributes which characterize an entity, e.g., user profiles, situation profiles and service profiles. In this paper we concentrate on situation profiles. So in contrast to the provision of new dimensions for situation detection, the instantiation of these concepts to characterize relevant situations along the provided dimensions is easy and can be performed by e.g., a service provider. All a service provider has to do is to create a new situation profile instance and then set some properties by selecting the possible values (ontology instances stemming from the feeding rules) from some menus. The following simple examples indicate how we can define situation profiles: WatchingCompetition : BeingAtEvent [ position ->> loc#Stadium; localAction ->> act#AnyAction; userState ->> cal#Leisure]. ReportingCompetition: BeingAtEvent [ position ->> loc#Stadium; localAction ->> act#AnyAction; userState ->> cal#Job]. SightseeingInStadium : Sightseeing [ time ->> time#Daytime; position ->> loc#Stadium; localAction ->> act#NoAction; userState ->> cal#Leisure].
Service profiles look similar, but have more structure. These examples describe three situations instances. A user is ‘watching competition’ if he is in a sports stadium, and any action (like a competition) actually takes place here. Moreover his calendar says that he has Leisure time. In contrast he is in situation ‘report-
ing competition’ if he is a journalist and from the calendar ontology it can be obtained what he is in status Job, while the other properties are the same. A third variant is the situation ‘sightseeing in stadium’, which is characterized by stadium, leisure and no action, i.e., nothing actually takes place at the stadium, and all that can be done is looking at the stadium itself. Of course, this is a simplified example, but it demonstrates the concept. Thus we do not have some fixed situations with individual rules, but an easily extensible set of situation profile instances, together with rather fixed general semantic matching rules, which is easy to maintain.
5.2 Dynamic Import of Context and User Profile Data during Inference Profile and context data can be imported to the inference engine in two ways: either they are used in a semantic query (which becomes lengthy then), or they are imported on demand when needed by the inference engine. For this purpose, logic predicates implemented in Java can be used, provided by the Ontobroker inference engine. E.g., the current time is delivered by a predicate via its parameter, valid for one semantic query. The predicate is only called when needed, controlled by the axioms of the ontology. The same technique is used for other sensor data and for access to user profile data as well. User profile information may influence the inference process as follows: Some preferences are mapped to service categories or service subjects, which requires a fine-grained service category taxonomy being related to the preferences hierarchy. E.g., a user should not get offers from a coffee shop when he only likes to drink tea. Moreover the user’s language can be used for suppressing services which are not needed for a native speaker, e.g. translation services or anything related to Chinese signs. A user’s cash restrictions and quality demands can be matched with corresponding properties in the service profile. Other preferences may be used for a personalized instantiation of time ontology concepts like Morning and Lunchtime, which are used to infer situations. User data (like name and address) can additionally be used for filling parameters of services.
5.3 Semantic Situation Detection For situation detection the context data imported on demand to the inference engine is initially mapped to the lower-level concepts of all dimension ontologies, and then the gazetteer mechanisms of all dimensions are used to obtain a set of instances of the higher-level dimension ontology concepts. The result is an abstract context, where each context value is replaced by a set of logic higher-level values This abstract context, together with user profile information and possibly other sources, then serves as an implicitly constructed situation request profile. E.g., not only the location and time may characterize a situation, but also whether an action takes place at that location and time, by consulting for example a social event directory service. The resulting situation request profile is then semantically matched to all the situation profiles known to the system. This is done by providing separate match operators for all dimensions of the situation profile, which each consider all relations defined between the corresponding values of the request and all offers. These relations are defined by axioms within the ontology.
The semantic matching leads to a (possibly empty) set of situations. A user may be in any of these situations or may be interested in being in this situation. E.g., if a user is in a stadium and it is lunch time, he may be interested in EatingInStadium and thus gets corresponding service offers. At the same time he is in situation WatchingCompetition.
Web services. Profile-based semantic matching of offers and requests follows for situations and then for services. In both cases, the request profiles are constructed implicitly, but may also be modified by a user. In general, deriving new facts on demand is the general aim of axioms in the ontology and enables deep inference in FLAME2008, where most system logic is implemented in the ontology.
5.4 Semantic Service Matching
In the FLAME2008 demonstrator as shown on CeBIT 2004 and CeBIT Asia 2004, the corresponding features are integrated and implemented and the feedback there was positive. The next step is to transfer the demonstrator to a prototype system. There are still several open problems in situation detection with sufficient preciseness as well as in situation planning in general, which are two major topics of our current research work.
The situation matching described above is analogously to semantic service matching based on OWL-S service profiles [25], which in fact follows next. Service (and information) advertisements and demands are described independently by different user groups (i.e., data/service provider, data/service user), not knowing exactly the needs of each other. The most flexible way to match demands against offers is by using semantic technologies, i.e., ontologies and inference. The service selection process is a semantic matching of an implicitly constructed service request profile against the profiles of all known services found in the semantic registry. It evaluates different types of semantic relationships like subclass and instance relationships or even relationships defined by arbitrary axioms. Here user profile and context may again be considered.
6. CONCLUSION Mass events in general, and those on international level in particular, imply the existence of large user groups with needs for mobile computing based support. Advanced approaches are required, since even for a single domain and context today’s Web does not provide adequate means, i.e., mobile Web surfing is time consuming, costly, and it often provides unsatisfying results. In summary, user profiles, context- and situation-awareness and semantic service descriptions provide the basis for a demanddriven personalized information and service logistics. All these descriptions are based on profiles, “profile” being a hierarchical set of attributes that characterize an entity, instantiated as user profiles, situation profiles, and service profiles. Context values of all users are gathered automatically by sensors, and whenever a user significantly changes his context, his situation is derived dynamically by the inference engine. Finally, the service matching provides as a result all offers which fit to the user’s situation and profile, grouped into categories. This updates the actual set of recommended services at the user’s PDA or smart phone. All this is done using inference based on a modular ontology. We described some details of our approach, focusing on ontology design, user model, contexts and situations and how all these are used for providing a user with personalized situation-dependant services. In FLAME2008 ontologies are used for different purposes. First one can distinguish navigation/browsing from inference. Concerning navigation, FLAME2008 provides a PDA and smartphone ontology browser, which does not only navigate in domain ontologies, but also derives new facts on demand by using the axioms of the ontology when the target of a followed relationship is not already instantiated. Moreover, the browser integrates predefined parameterized queries which are defined in the ontology. Concerning inference, the axioms of the ontologies are used for three purposes in FLAME2008: By abstraction the lower layers of both the location and time ontologies are mapped by axioms and predicates which may even be implemented using Java and
7. ACKNOWLEDGMENTS We wish to thank our colleagues from Dortmund and Berlin with whom we had stimulating discussions, as well as anonymous referees for their constructive remarks.
8. REFERENCES [1] Aufaure, M.-A., Yu, S., Spaccapietra, S. and Cullot, N. User Profiles in Location-based Services: Make Humans More Nomadic and Personalized. In Proc. IASTED International Conference on Databases and Applications, 2004. [2] Borst, P. Construction of Engineering Ontologies for Knowledge Sharing and Reuse. Ph.D. Thesis. Twente University, 1997, http://www.ub.utwente.nl/webdocs/inf/1/t0000004.pdf. [3] Cycorp, Inc. OpenCyc Selected Vocabulary and Upper Ontology, 2002, http://www.cyc.com/cycdoc/vocab/ vocabtoc.html [4] Deiters, W., Löffeler, T. and Pfennigschmidt, S. The information logistics approach toward a user demand-driven information supply, in: Spinellis, D. (ed): Cross-Media Service Delivery, Boston, 2003, pp. 37-48. [5] Dey, A. Understanding and Using Context. In Personal and Ubiquitous Computing Journal, 5 (1), 2001, pp. 4-7. [6] European Research Consortium for Mathematics and Informatics (ERCIM). Special Theme: Applications and Service Platforms for the Mobile User, ERCIM News No.54, July 2003. [7] Fink, J. and A. Kobsa. User Modeling in Personalized City Tours. Artificial Intelligence Review 18(1), 2002, 33-74. [8] Fonseca, F., Egenhofer, M., Davis, C., and Borges, K., 2000. Ontologies and Knowledge Sharing in Urban GIS. Computer, Environment and Urban Systems, 24 (3), 2000, pp.251-272, http://www.spatial.maine.edu/~max/urbanOntologies.pdf. [9] Fraunhofer ISST. FLAME2008 - Being a real part of the Games, http://www.isst.fhg.de/german/veroeffentlichungen/pdf_dateien/produktblaetter/FLAME2008-engl.pdf. [10] Gu, T., Wang, X.H., Pung, H.K. and Zhang, D.Q. A Middleware for Context-Aware Mobile Services. IEEE Vehicular Technology Conference VTC, 2004. [11] Guarino, N. Formal Ontology and Information Systems, Proc. FOIS’98, Trento, Italy, June 1998, IOS Press, pp. 3-15.
[12] Haseloff, S. Context Gathering - an Enabler for Information Logistics. In: Chamoni, Deiters, Gronau, Kutsche, Loos, Müller-Merbach, Rieger, Sandkuhl (eds.): Multikonferenz Wirtschaftsinformatik (MKWI) 2004, Volume 2. Berlin, Akademische Verlagsgesellschaft, 2004, pp. 204-216. [13] Hiramatsu, K. and Reitsma, F. GeoReferencing the Semantic Web: ontology based markup of geographically referenced information. Joint EuroSDR/EuroGeographics workshop on Ontologies and Schema Translation Services, Paris, France, April 2004, http://www.mindswap.org/2004/geo/geoOntologies.shtml. [14] Hobbs, J. and Pustejovsky, J. Annotating and Reasoning about Time and Events, in: Doherty, P.; McCarthy, J.; Williams, M.:Proc. AAAI Spring Symposium on Logical Formalization of Commonsense Reasoning,. AAAI Press, Menlo Park, California, 2003, pp 74-82, http://www.cs.rochester.edu/~ferguson/daml/hobbs-pustejovsky.pdf.
[22] OGC. Gazetteer Service Specification. Open GIS Consortium, Document: 01-036, 2001. [23] Ontoprise GmbH. F-Logic Tutorial. How to Write F-Logic Programs, Nov. 2003, http://www.ontoprise.com. [24] Ontoprise GmbH. Ontobroker Tutorial. How to Use Ontobroker, Oct.2003, http://www.ontoprise.com. [25] OWL Service Coalition OWL-S: Semantic Markup for Web Services, 2004, http://www.daml.org/services/owl-s/1.0/owls.pdf. [26] Schiller, J. and Voisard, A.. Location-based Services, Morgan Kaufmann, San Francisco, California, 2004. 250p. [27] Toivonen, S., Kolari, J. and Laakko, T. Facilitating Mobile Users with Contextualized Content, In Proc. Workshop Artificial Intelligence in Mobile System, 2003 http://www.vtt.fi/tte/tte31/pdfs/AIMS2003-toivonen-kolarilaakko.pdf.
[15] Holtkamp, B., Gartmann, R. and Han, Y. FLAME2008 – Personalized Web Services for the Olympic Games 2008 in Beijing, In Proc. eChallenges e-2003, Bologna, 2003.
[28] Tomai, E. and Kavouras, M. Vagueness in Geographic Categories: A Setback to Semantic Interoperability, 5th AGILE Conf. on Geographic Information Science, 2002.
[16] ISO19115, Geographic information – Metadata to support Imaginary and Gridded Data, ISO/TC 211, doc no. 1142, 2001.
[29] UDDI.Org. UDDI Version 3.0 Specification, Open Draft 2002, www.uddi.org/pubs/ uddi_v3.htm.
[17] ISO19119, Geographic information – Services, ISO/TC 211, doc no. 1203, Dec. 2001. [18] Kifer, M., Lausen, G. and Wu, J. Logical Foundations of Object-Oriented and Frame-Based Languages, Journal of the ACM, vol. 42. no. 4, July 1995, pp. 741-843. [19] Kokkelink, S., Schwänzl R. Expressing Qualified Dublin Core in RDF/XML, Apr.2002, http://dublincore.org/documents/dcq-rdf-xml. [20] Meissen, U., Pfennigschmidt, S., Voisard, A. and Wahnfried, T. Context- and Situation-Awareness in Information Logistics, in Proc. of EDBT Workshop on Pervasive Information Management, Springer Verlag, 2004. [21] Niles, I and Pease A. Towards a Standard Upper Ontology, Teknowledge Corporation, 2001, http://projects.teknowledge.com/HPKB/Publications/FOIS.pdf.
[30] Versit Consortium. VCard - The Electronic Business Card, Specification, Sep. 1996, http://www.imc.org/pdi/ vcard21.doc. [31] Weißenberg, N. and Gartmann, R. Ontology Architecture for Semantic Geo Services for Olympia 2008, In Proc. GI-Tage Münster, June 2004 http://www.gitage.de/downloads/gitage2003/tagungsband/we issenberg.pdf. [32] World Wide Web Consortium. OWL Web Ontology Language Reference, Mar.2003, http://www.w3.org/TR/owl-ref. [33] World Wide Web Consortium. The Platform for Privacy Preferences, Specification, W3C Recommendation, April 2002, http://www.w3.org/TR/P3P
