A Modular Data Infrastructure for Location-Based Services Shijun Yu, Stefano Spaccapietra Ecole Polytechnique Fédérale de Lausanne (EPFL)
Next generation LBS: Knowledgeable Information Delivery n Current LBS: Space-awareness u n Time-awareness u u n On rainy days, suggest a museum rather than a park User-awareness (personalization) u n Do not suggest visiting a market on days it is closed Omit out-of-town spots if the user has only half a day free Context-awareness (contextualization) u n Nearest cash dispenser If user is on a business trip, suggest taking a taxi rather than a combination of public transports Service-awareness (focus) u do not promise information you do not have 2
Personalization: info for you n Selecting a subset of the objects of interest u Select nearby restaurants by taking into account your preferences for cuisine n Choosing specific information u Adapt information on the temple to the level of detail that is appropriate to your knowledge of temple history and architecture n Personalizing predicates u Define the meaning of “nearby” depending on your habits User dislikes walking: nearby = less than 5’ walk F User likes walking: nearby = less than 15’ walk F User is driving: nearby = less than 10’ drive F 3
Contextualization: info for where you are in the situation you are n When looking for transportation to join a meeting u u consider traffic conditions to select subway/train or taxi/bus consider local cultural habits to determine the targeted arrival time F F if in Switzerland, plan to arrive at the meeting slightly before its opening if in Italy, plan to arrive at the meeting within half an hour from its opening n When looking for restaurants, on a rainy day ignore user preference for restaurants with outdoor garden n Make sure you know the rules: F F F n duration of a trip on surface road depends on traffic conditions when it is appropriate to join a meeting depends on local socio-cultural rules outdoor activities normally require nice weather Contextualization is a query refinement process 4
An Architecture for knowledgeable LBS Limited Universe of Discourse Local Environment (contexts Data Sources Web pages User Profiles I want to know … I want to book … Location Based Services External Ontologies Databases XML & RDF files 5
K-LBS Data Infrastructure Ontological Resources Context profiles Time User profiles Terminological Resources e. g. Wordnet Context Module User Module Space Service Module Service profiles Modular Core Ontology mapping inter-module link 6
Context
What’s Context? n Context: Describes the current "situation" of the real world of interest n Context: where, when, who, why, what, how (Schilit et al. , 1994) n Any information that may lead to modifying a user query given the current situation and is not specific to a user or to a service n Context is service-relevant and user-relevant n Low-level contexts: u n location, time, nearby objects, networking configurations, orientation, environment (light, temperature, pollution, etc. ) High-level contexts: u social context (e. g. , social status of the event or location) 8
A Skeleton for the Context Module Administrative Spatial Functional Landmarks Context basically, a composition hierarchy Temporal Environment Communication Calendars Landmarks Academic Business Atmospheric Traffic Network Device Socio-cultural 9
Example: Environmental Data Environmental data for the current city Date: 27. 9. 2007 Weekday: Thursday Time: 11 h 00 Weather: sunny Temperature: +13 Celsius Humidity: 53% Weather forecast: good, warming Pollution level: medium Snow: none Environmental data for the current user (in a room) Date: 27. 9. 2007 Time: 11 h 00 Temperature: +20 Celsius Humidity: 40% Light: shadow Pollution level: medium Noise level: medium City traffic: fluid 10
Linking Context and Services n How does the LBS know when traffic conditions are relevant? u "relevance" link between Service and Context modules u a relevance link connects a service with the context elements on which the service "depends" e. g. bus transportation services depend on traffic conditions (to compute durations), local events (to look for alternate routes if needed), and the day of the week (to refer to the appropriate schedule). "Depend" here means the services need this context information to provide contextualized answers. F availability of services may depend on what is the current day of the week (e. g. museums in France are closed on Tuesday). "Depend" here means there is a precondition for using the service. The precondition may be stated as a predicate on the current temporal context. F 11
Linking Context and User Modules n User queries need to be contextualized and personalized. n Personal preferences may depend on context u n e. g. a preference for outdoor-sitting in restaurants is only relevant if the weather is currently fine => materializes as a "relevance" link between the outdoor-sitting preference in the User Module and the nice weather status in the atmospheric data in the Context Module. Analysis: u inter-module relevance links are used either as a filter (to determine what has to be considered) or as an import means (to transfer knowledge so that the service process becomes knowledgeable) 12
Users
Personalization => User Profiling n Basically, a user profile holds a set of properties that characterize the user (e. g. , age class, profession) or express user’s preferences and priorities (e. g. , domains of interest, preferred cuisine style): <attribute, value> pairs n Highly context-dependent: one user = many contextual profiles n Currently, no standard format/content, no underlying theory Example Profile 1 for Stefano: Activity: Tourist Profession: {professor, employee, academic} Age: senior Gender: male Nationality: French, Swiss Income: comfortable Interest: art, culture, hiking, cinema Languages: French, English, Italian Food. Preference: very good to good Cuisine: Japanese, Thai, Arabic Example Profile 2 for Stefano: Activity: Professional Profession: {computer scientist, professor} Age: senior Interest: databases, ontologies, semantic web Languages: French, English, Italian Memberships: ACM, IEEE, IFIP 14
Using User Profiles n To make queries more focused n To present retrieval results in user’s order of preference u Query reformulation examples “where can I buy a souvenir? ” + income: moderate => “give me a nearby department store which sells souvenirs” + income: high => “give me a nearby shop specializing in souvenirs” u 15
Richer User Profiles n Beyond < attribute, value > pairs …. . u u An attribute may be multivalued An attribute may be structured (with embedded sub-properties) F u An attribute may have a hierarchy of values (i. e. , values at different levels of detail) F n n E. g. , interest [domain, level-of-expertise] E. g. : Interest (music (rock, tango), movie (action-movie (karate-movie))) Dependencies may exist between attributes: E. g. , income hotel category Rules stating what the attribute is useful for u E. g. , income has impact on things implying a payment (buy), but has no impact on preferences in things free or inexpensive Interest music movie rock tango action-movie karate-movie 16
Properties in Profiles n Ordered-value property u n Favorite. Cuisine = LIST(Japanese, Thai, Chinese) Context-sensitive property u Favorite. Sport: Season = Summer SET(hiking, cycling) Season = Winter SET(ski, yoga) (Season is a concept in the temporal component of the Context Module) n Privacy-sensitive property u credit. Card = LIST(VISA, Master) Privacy: Disclose(Amazon, Paypal), Undisclose(Ebay) 17
A Skeleton for User Module Birthdate Census Nationality Gender User basically, a composition hierarchy Professional Educational Interest Domains Domain Fonction Domain Degree Domain Expertise Preference Skills Domain Expertise 18
The User Ontological Module n User profiles are mapped to the User Module User Profile 1 User Module User Profile 2 User Profile 3 ………. User Profile N n The User Module describes an abstraction of user profiles n This abstraction provides directives (patterns) for query reformulation n The patterns are evaluated against the suitable profile of the querying user 19
Services
Services from Multiple Data Sources n "Local" available sources u n e. g. , for a tourist in Kyoto, Nara and Osaka tourism information is also considered locally relevant, but not Tokyo information Heterogeneity: Structured / unstructured, u browsable / queriable e. g. , public local databases, local and generic Web services, Web pages n Diverse knowledge extraction strategies, but few extraction tools for space and time n Homogenization: describe each source as a set of services n Service profiles are mapped to (and abstracted by) the LBS ontological module about services 21
A Skeleton for the Service Module Real. Estate. Rental Car. Rental Sport. Equipment Villas Apartments Winter. Sports Summer. Sports Bus Services basically, an is-a hierarchy Transport Train Subway Facilities Hotels Restaurants Gardens Museums Temples Shows Service Profiles Chado Research center Kyoto National Museum Raku Museum 22
Conditional services n A service may be available only in conjunction with Stadium History Museum other services, e. g. Museum Facility Sports Museum obtain a visa you must first obtain an id document Hospital u => pre & post conditions e. g. Quai de Belgique Path u to n Lausanne city Transport District A service may be available only for. Landmark persons. Museum given e. g. Olympic e. g. Ouchy Block access a swimming pool at certain times you must have membership into the swimming club Hotel Tourism e. g. Olympic Museum u to n Top 10 visited e. g. Lausanne Cathedral A service may be available only in given Ouchy Port e. g. contexts u in Transport means Switzerland, shops are closed on August 1 st u a special bus to a nature park only runs in Summer 23
Similar services n A service may be almost equivalent to another service Stadium u taking History Museum a bus from A to B Museum Facility u taking a subway from A to B Sports Museum Hospital u if one is not available, the other one may replace it Path e. g. Quai de Belgique n A service may Lausanne city District be equivalent to another service but in a Transport Landmark e. g. Olympic Museum e. g. Ouchy different timeframe Block u the n daily bus is replaced by a minibus after 10 pm Tourism Hotel e. g. Olympic Museum A service may be equivalent to another service but at a e. g. Lausanne Cathedral Top 10 visited e. g. Ouchy Port different cost Transport means u taking a bus from A to B and taking a taxi from A to B 24
Queries
Query Formulation Techniques n Natural Language u u u n Complex Structured Language à la SQL u n For expert users only, not suited for LBS Keywords driven u u u n Where in Kyoto tomorrow can I buy a Toshiba PC 12 inches? Easy to use if input audio channel is available Difficult to process Buy, laptop, PC, Toshiba, screen-size = 12” Relatively easy to use, but still needs complements Relatively easy to process Menu driven (à la Ipod) u u Buy -> computer -> laptop -> brand -> Toshiba -> type -> PC -> screen -> 12” Easy to use, easy to process 26
Query Formulation with Tokens n Must be simple, as few words as possible n Query: <What, Where, When, What Else> u< n “Toshiba 12” laptop, Kyoto, tomorrow, version=English > Open vocabulary, avoids limiting the concept space. Entails the use of linguistic techniques, e. g. u Tokenization: cellphone => <cell, phone> hands-free_cellphone => <hands-free, cellphone> u Lemmatization: travel, traveling, traveled => travel jobs => job u Elimination: a, the, by, type of 27
Query Formulation: Examples n What: u u n Where: u u u n The nearest Chinese restaurant A pizza delivery service which could deliver a pizza at my hotel A bus going downtown (from here, or from the Kyoto Hotel) When: u u n A Chinese restaurant, a cash dispenser A place selling stamps A taxi Am I moving North? The nearest Chinese restaurant still serving lunch at 3 pm A fine-arts exhibition open this afternoon What else: additional user preferences: u The nearest Chinese restaurant rated very good 28
Understanding the What n ==> linguistics + ontologies + terminology + context n What: "Chinese restaurant" u u English Grammar ---> Chinese: adjective, restaurant: noun Search for "restaurant" in the Service Module: F F u Search for "Chinese" within the description of restaurants F F F u u u OK: If the concept is context-dependent, check what the current context is to identify the correct interpretation: Set the query as Q 0: (x) SM. restaurant(x) if no restaurant in the Service Module, search for synonyms in the terminology if Chinese appears as a value for enumerated attribute type. Of. Cuisine, add the predicate "type. Of. Cuisine = "Chinese" Q 1: (x) SM. restaurant(x) SM. type. Of. Cuisine(x , 'Chinese') otherwise Search for meaning of Chinese: pertaining to China / person from China / … Select meaning "pertaining to China" as it suits the role of an adjective "pertaining to China" applies either to the cuisine being served or the owner of the restaurant F F F discard owner as normally this is not an attribute used to select restaurants if there is an attribute type. Of. Cuisine, add the predicate type. Of. Cuisine(x, 'Chinese') if Chinese doesn't produce results, try with nearby concepts (e. g. Vietnamese) or more generic concepts (e. g. Asian) 29
Understanding the What n A place selling stamps u Selling: action, related to shops / shopping Stamps: object to be sold Stamps are sold by post offices only (contextual knowledge) => u Q: (x) SM. post. Office(x) u u n A taxi u n Taxi: service, offered by taxi companies, contact by telephone Am I moving North? (Assuming the LBS positioning services include a functionality to compute directionality of paths) u u Boolean query: yes - no North: direction Moving: action Moving North: going in North direction: user movement leading North 30
Query Answering Steps n Reformulate the user input (what, where, when, what else) as a conjunctive query: set of predicates defining the result u Q: (x) SM. restaurant(x) SM. type. Of. Cuisine(x , 'Chinese') SM. rating(x, 'very good') SM. location(x, p) near(p, CM. current. User. Location) n Reformulate the query by adding/modifying predicates to take into account the user profile u u n e. g. user profile has preference for cosy restaurants Q: Q SM. atmosphere(x, 'cosy') Reformulate the query by adding/modifying predicates to take into account the context u u n IF (weather = 'sunny' AND temperature = 'warm' AND 'outdoor' IN UP. preferences) THEN Q: Q SM. sitting(x, 'outdoor') Check preconditions and possibly add more predicates 31
Using pre-conditions n Precedence: If the precondition for using a service is that another service must have been used before, look into the interaction history to check the precondition u n Filtering: If the precondition limits the use of a service to a certain category of people, check if the querying user belongs to this category u u n --> need to maintain an interaction history the qualifying category is defined, for each type of service, by a set of predicates on the user profile --> relevance links between service description and user description Dependence: If the precondition limits the use of a service to queries issued in a certain context, check if the current context allows for using the service u u the qualifying contexts are defined, for each type of service, by a set of predicates on the context data --> relevance links between service description and context description 32
Query Reformulation Example n Original user query Q (what: Salsa dance course, where: near Kyoto Tower, when: Thursday evening, what-else: beginner) n Step 1: Q(what) Reformulation: ’Salsa dance course’ n From the core ontology: Dance. Course Has. Subject. Dance and Has. Style is a role from Dance to Dance. Style and Salsa is an instance of Dance. Style qwhat= "Dance. Course" and qwhatelse= (Dance. Style = ’Salsa’) n The what of the query can be written as: Q: (x) Dance. Course(x) Dance. Style(x, 'Salsa') 33
Example continued: where n Step 2: Q(where) Reformulation: near Kyoto Tower n near: a spatial relation; Kyoto Tower: a known Landmark qwhere: distance(Kyoto. Tower. location, Service. location)≤ 1 km (x) Dance. Course(x) Dance. Style(x, 'Salsa') location(x, s) location(CM. Kyoto. Tower, k) distance(s, k) < 1 km 34
Example continued: when n Step 3: Q(when) Reformulation: Thursday evening n Local Calendar: current date is "2007 -07 -17, Tuesday". In this context, Thursday means "2007 -07 -19, Thursday" Evening is defined in local context as after 6 pm. (x) Dance. Course(x) Dance. Style(x, 'Salsa') location(x, s) location(CM. Kyoto. Tower, k) distance(s, k) < 1 km Open. Time(x, d, t) d = '2007 -07 -19' t > 18 35
Example continued: what_else n Step 4: Q(what-else) Reformulation: "beginner" n The initial condition in Q(what-else) is only one keyword "beginner". By identifying its value, it is found it matches with the value domain of the attribute "level", hence it is reformulated as follows: n qwhatelse = (level = ’beginner’) Q: (x) Dance. Course(x) Dance. Style(x, 'Salsa') location(x, s) location(CM. Kyoto. Tower, k) distance(s, k) < 1 km Open. Time(x, d, t) d = '2007 -07 -19' t > 18 Level(x, 'beginner') 36
Query Refinement n Q: (x) Dance. Course(x) Dance. Style(x, 'Salsa') location(x, s) location(CM. Kyoto. Tower, k) distance(s, k) < 1 km Open. Time(x, d, t) d = '2007 -07 -19' t > 18 Level(x, 'beginner') User Profile: Language: LIST(Japanese, English, French) n Q: Q Teaching. Language(x, t) ( t = 'Japanese' v t = 'English' v t = 'French' ) ORDER x BY (t, LIST(Japanese, English, French)) n 37
Query Relaxation n If a satisfying service is not found, a Latin dance course may be acceptable instead of a Salsa course (Latin denotes a dance style more generic than Salsa) u n If a satisfying service is not found, an afternoon course may be acceptable instead of an evening course u n relaxing the predicates on hour If a satisfying service is not found, a course on Wednesady may be acceptable instead of a course on Thursday u n relaxing the predicate on dance style relaxing the predicates on date What can be relaxed (and in which order of priority) depends on the user preferences u need for a user-defined query relaxation profile 38
Conclusion n Personalized and context-dependent information management is the natural target for next generation information services in general and LBS in particular. n An appropriate data infrastructure is needed for that. n We propose a modular ontology framework, mainly built from externally provided user and service descriptions n We emphasized the need for intra-module and intermodule links, and identified a set of relevant semantics for these links, to effectively enable personalization and contextualization. 39
Скачать презентацию A Modular Data Infrastructure for Location-Based Services Shijun
5f252ce3600fb641803b8e50d6d08d01.ppt