This paper presents the design and implementation of a novel geosocial semantic service called “Geosocial SPLIS” (GeoSocial Semantic Personalizing Location Information Service). The service a) gets data about points of interest (POIs) and user profiles from external sources such as Google Places API and Google+, b) adopts the well known schema.org ontology, c) supports a user friendly web editor so as regular users to be able to insert and customize their daily preferences about points of interest (POIs), and POI owners their group targeted offers, d) uses RuleML and Jess rules to make this rules machine comprehensible, e) presents contextualized information on Google Maps.
Location Based Social Networking Services (LBSNs) have become very popular over
the past few years [
Semantic web technologies such as ontologies and rules gave a huge boost to
context awareness. First of all, ontologies enable high quality context perception by
representing concepts such as persons, POIs etc. Furthermore, by providing a general
representation standard, they enable reusability and interoperability among different
systems in the web [
In this work, an innovative location based social networking service called
“Geosocial SPLIS3” will be presented. Geosocial SPLIS is an extension of previous
systems called “PLIS+” [
Friday then spaghetti price has discount 10%”). These offering policies are then represented as rules in RuleML and Jess format. SPLIS evaluates these rules on the fly depending on regular user’s context and delivers personalized offers to them. Geosocial SPLIS, in the same spirit: 1. Gets people data (except from a common registration form) via Google+4. 2. Supports a user friendly web editor so as regular users to add their individual rule based daily patterns about POIs (e.g. “If time is between 11:00-17:00 and weather is Sunny then I want to go to an Ice-cream shop”). The service supports preferences about: a) all POI properties b) weather (e.g. a when weather is sunny suggest me some ice-cream shops) c) time-day-month (e.g. I would like some restaurants, if it is Monday) d) user’s location (e.g. I want a store which is within 900 meters)
Then the data from editor’s forms are being used to create a RuleML file. After that, this file is transformed into Jess so as to become computer understandable. Finally, all data5 and rules are stored in Sesame so as to be reusable from other systems, as described above.
3. Executes and evaluates data and rules (user rules and POI owners’ group targeted offering policies) at run time to provide contextualized information to users on Google Maps6 (relevant places and offers regarding their context). 4. Users can interact among each other and create friendships, as in other LBSNs. Last but not least, Geosocial SPLIS combines users’ preferences with those of their nearby friends to provide POIs and offers for all of them.
The motivation of our work is to combine semantic web technologies with LBSNSs
and present qualitative personalized information to user. Everyday life situations
present strong daily patterns and are not completely random [
There are various approaches that inspired our service. For example, Serrano et al.
[
In the following section, the service’s architecture is described, while section 3 includes the service’s operations. In section 4 some use case scenarios are demonstrated. Finally, section 5 discusses the conclusions of our work and indicates future directions.
Geosocial SPLIS’s architecture components are illustrated in the UML component
diagram of figure 1. The basic component of Geosocial SPLIS is Sesame, which is
used for storing and retrieving RDF triples and is compatible with java-based
applications as well [
Another component of the system is the rule language which is used to represent
human understandable policies. In our service, we selected RuleML and being more
detailed, Reaction RuleML (a subcategory of RuleML) for this purpose [
To develop a service like Geosocial SPLIS a rule representation language needs to
be transformed into a computer executable form. Jess was selected for this purpose
due to the fact that it is lightweight and connects well with web technologies, which
were needed [
Last but not least, usual client side technologies such as HTML, AJAX and JavaScript were utilized. Geosocial SPLIS’s server is based on Java Server Pages (JSP) technology.
Google Places API
Google schema.org RDFS
POI websites
Google+ Jess
POI
Data Facts and
Rules
Ontology
POI Data & Rules Inference
Data
Geosocial SPLIS server
Storage/
Query Data and rules
POI data and
rules Geosocial SPLIS Client
RDF Data
User profile Data & Rules
Sesame
This section describes in detail the service’s operations. It supports the above operations: 1. Information presentation operation. 2. Operations about rules. 3. Operations that utilize social connections 4. The planning mode operation. 3.1
The operations that need to be completed in order the service to present suitable information to users are the followings: 1. Data insertion. First of all, users have to fill in a registration form or connect Geosocial SPLIS with their Google+ account in order the service to build their profile. A data mapping is directly done because Google+ properties are compatible with schema.org. When a user logs in using Google+ account, Geosocial SPLIS updates existing data. 2. Data acquisition. After a user’s login, data concerning user’s context (profile properties, relationships, rules, time, day, weather) and data about nearby POIs (properties, owner, rules) are retrieved from the repository. 3. Rule evaluation. Data referred previously are transferred to the Jess rule engine. Jess evaluates users’ and POI owners’ rules exploiting the existed facts and modifies POIs’ property values according to the fired rules. Concerning POIs’ rules, Jess checks the conditions of a rule and concludes whether or not the values of the properties involved in the then-part of the rule, need to be changed. Regarding users’ rules, it checks the if-part (they involve user contextual properties and place data) and concludes whether a POI is suggested or not to the user. 4. Visualization of personalized information. The last step is to present the available information via Google map. On the map: a) b) c) d) e)
A larger in size marker represents a place which is suitable for the user’s preferences and it is suggested.
A red marker illustrates a POI which has no offering policies at all.
A red star over the marker is used for informing the current user that he/she is the owner of the POI (so the user is able to add properties and targeted offering policies).
A green marker indicates that this POI has a valid offer for the current user (at least one rule was fired for the current user regarding his/her contextual situation).
A yellow marker is used to illustrate a place that contains a rule base of offering policies that does not match current user’s context.
The service also helps the user with extra information by displaying messages that show which rules were fired and why. A user’s rule/preference is represented by a person icon in front of the message and a POI owner’s rule/group target offer by a marker icon. Apart from these messages, by clicking on a marker, a user can a) view its data, b) contribute by writing a review, c) rate POIs, c) add “likes” or d) do a “check in”. The information presentation operation will become clearer with a use case scenario in the next section. 3.2
This section includes a detailed discussion about regular users’ rule based
preferences. A detailed reference regarding POI owners’ operations relating to rules (group
targeted policies) can be found in [
Rule insertion operation via editor. Regular users can add their rule based preferences through a user friendly web editor. An illustration of rule creation in Geosocial SPLIS is given in figure 2, where a user asserts the rule “If day is Friday, then I would like to go to a CafeOrCoffeeShop which is closer than 550m”.
To begin with, a user can insert the title and the priority of the rule. Afterwards, by clicking on the four buttons “Add...Condition” he/she is able to customize the contextual condition. The condition customization consists of a) the property part (weather, day, time, distance) b) the operator part (“is” for day or weather and “<”,”>” for time or distance) and c) the value. To avoid user data heterogeneity and possible mistakes properties’ and operator elements are represented by read-only forms and values’ elements by drop down menus. By clicking on the red button, a user is able to delete a condition as well. By repeating this process, he/she can add multiple conditions. A logical “AND” is implied among them.
Then a user has to select the desired POI category. It is worth mentioning that schema.org hierarchy is adopted. For example, if he/she chooses the place type “Store” all its subcategories are inferred (e.g. ShoeStore etc.). Moreover, by clicking on the “Add Where Condition” button he/she is capable of making the rule more specific by customizing the POI properties. A drop down menu for POI properties, an operator drop down menu (“is” and “contains” for text and “<”,”>” for numbers and dates) and a value field are supported.
Finally, a user can insert a textual explanation of the rule, so that the meaning of the rule can become obvious both to him/her and also to other users. Notice that the editor supports a preview button to check the rule before the submission and a clear button to reset the operation. A user can also select anyone of the most popular rules, or on one of his/her friends’ rules in the left corner of the screen and the forms about this rule are automatically filled.
After the submission, form data are being collected and transformed to RuleML language (for knowledge sharing) and afterwards, via xslt, are transformed to Jess so as to become machine executable. For example, table 1 illustrates the rule of figure 2 in RuleML and Jess. About Jess representation, it’s worth mentioning that JESS salience is utilized for resolving rule conflict issues. Setting a rule's salience to a large positive value will give that rule a higher priority above all rules of lesser salience. In our system conflicts concern only the POI owners’ rules in case they modify the same slot (e.g. If an owner has inserted the following two rules a)”If it is Monday spaghetti costs 6€”, b) “If a person is a student spaghetti costs 5€”, the rule with the highest priority/salience value will be fired). “Recommendation” is the name of the template that stores the POIs that match the rule based preference if it is fired and “EXPLANATION” is a variable which is used for storing the explanation message which will be presented to the end user. Finally, rule data are stored in Sesame in the form of RDF triples. Table 1 contains some of them. RDF/S ontology has been enriched by adding the relating class and its properties (e.g. title, priority, explanation, description, ruleml_link etc.). Notice that “policy_description” property is a text that is automatically created from the data the user entered into the rule forms and it is used for helping other users to comprehend the rule if the rule’s creator inputs either a non-understandable text or no explanation text at all. Rule editing operation. Users can directly find their rules and edit or delete them. The same interface which has been designed for the rule insertion operation is used for updating the existing rules as well. “Get a rule” operation. To make the overall operation (regarding rules) simpler and motivate users as much as possible, they are able (apart from developing their own rules) to obtain rules from other users. To begin with, they can search among existing rules. Furthermore, in the starting page, a) the 3 most popular rules regarding all users and b) the 3 most popular rules considering user’s friends are displayed. A user can simply check and get some of them if they are suitable. Additionally, when a user does a “check in” to a place, or a “like”, the 5 most popular rules regarding the POI’s category are also displayed in a pop up. Last, by clicking on their friends’ profile they are able to view and get their rules. To prevent problems in the rule editing operation (in cases where user A gets a rule which was created by a user B and then edits it), when a user modifies a rule a new one is created.
Another operation which is supported to denote the technical capabilities of Geosocial SPLIS is the “planning mode”. By selecting the corresponding option from the available menu (Planning) a pop up window appears, including two drop down menus which concern the future day and time a user will visit a location. In detail, he/she has to choose a) after how many days he/she will visit a location and b) the time of day being there. After that, the system collects the user’s future context (day, time and weather condition) and evaluates his/her rules and POI group targeted offers depending on the future situation. In order to select the future location a user makes a right click on the map on the desired location. It is worth mentioning that the number of days is restricted to 5 due to available future weather information. This operation will be demonstrated with a use case scenario in the next section.
In order to show Geosocial SPLIS’s abilities, use case scenarios about two different users will be exhibited. We take as example two users (being friends with each other) that have the following profiles: a) User A (“Peter”) is a 18-year old male student, his current profile snapshot is taken on Friday, at 14:37 in a location A, which has sunny weather”. b) User B (“Helen”) is 20-years old; she is a female student and is logged in the system at the same time with Peter in a location B, close to a location A”.
Let us now make the assumption that Peter and Helen have used the web editor described above and have the rules that are illustrated in table 2.
“On Friday afternoons (13:0016:00), suggest me some Restaurants” “I would like to go for coffee, if it is Friday and weather is Sunny” As it was mentioned, when a user logs into Geosocial SPLIS, it builds his/her context and evaluates his/her rules/preferences along with nearby POIs’ rules/group targeted offers accordingly. Regarding Peter, rule 1 from table 2 is fired because the day is Friday and current time is 14:37. Consequently, all the nearby coffee shops are illustrated with a larger marker and are recommended to him (figure 3 below). In order to assist Peter in finding easier a POI, the marker contains a letter which is the starting letter of the category it belongs (e.g. “R” if it is a Restaurant). By clicking on the nearby POIs, Peter can get contextualized information. As it was mentioned earlier, a large green marker indicates that this POI not only has a valid offer for him, but he would also like to go there regarding his current context. Taking for example the place “Ambasso”, a) it is represented with a big green marker because it is a coffee shop and b) has a valid offer for him because it is Friday and he is a student (it contains the group targeted offer “Students are entitled 50% discount in espresso on Fridays”). Peter can view a) its data (notice that data that have been modified by a POI owner’s rule are highlighted), b) the POI owner’s textual explanation about the group targeted offer that matches his context and c) his rule-based preference which was fired and suggested this POI (figure 4a). Peter can also add a “like”, a review or a rating to “Ambasso”. He can also view the reviews and ratings that have been inserted by other people.
Similarly for Helen, both rules are fired for her. As a result, coffee shops and restaurants are represented with larger markers. For instance, if she clicks on “Mr Jones Café” she can get the personalized info illustrated in figure 4b. In this case the POI owner‘s rule is not valid for her (it’s not Saturday) and the POI is represented with a yellow marker. Notice that in the left side of the screen, by checking the relating explanations, Peter and Helen can easily get some of the three most popular rules a) of all users or b) of their friends.
By selecting “Friends””Nearby friends” in Geosocial SPLIS’s menu, Peter and Helen are able to view which of their friends are nearby. Taking for example Peter, we make the assumption that Helen is his only nearby friend which is logged in at this time. When he visits this page the system: a) Collects his and Helen’s corresponding context and rules. b) Executes all the above rules, and then acquires from the repository all the available nearby POIs that are suggested by the fired rules. In our scenario Peter’s rule 1 is fired and as a result coffee shops are suggested. Apart from Peter’s rules, Helen’s both rules are fired. Consequently, coffee shops and restaurants are recommended. c) After that, the system gets recommended POIs’ offers (POIs’ rules) and evaluates them according to Peter and Helen’s contexts. d) After that, it displays personalized information.
When Peter is inserted into “friends’ mode” he gets the information which is illustrated in figure 5. All coffee shops (markers with the letter “C”) are represented with a larger in size marker because Helen would like to go for coffee at this time as well. Restaurants are represented with a small marker because they concern only Peter. On the left side of the screen there are explanations about the icons and, below them, there is a table which displays which rules are fired and who is their possessor. As result, Peter can easily find common POIs with his friends (large markers), POIs that contain offers for all of them etc. For example, he is able to spot easily a POI, where both of them would like to go, which contains a valid offer for both of them as well by clicking on a big green marker. After that he is able to view the POI owner’s rules (if any) and the user defined rules which are fired, regarding this POI, so as to comprehend a) who has a valid offer and why, b) who maybe be eager to visit this POI at this moment. Taking for example the POI “MOJO cafe bar” which is represented with a half green-half yellow marker, Peter can to view a) that the offer is valid only for Helen (she is a female student) and b) that both of them would like to go there at this moment (figure 6a). Similarly regarding “Ambasso”, Peter can directly understand that not only both of them have a valid offer but also that they both want to go there now (figure 6b).
Let’s now consider a scenario where Peter has to visit London after two days (in Sunday) and would like to get some information about POIs and offers there. In order to accomplish this, he chooses the “Planning” option from the available menu and in the pop up window he selects a) the option after 2 days, b) the time he will be there (21:00 in our scenario). Once he is inserted into planning mode he is able to make a right click on the map in London and find POIs and offers that match a) his/her rule based preferences and b) POIs’ rules for the future situation (figure 7). Due to the fact that it is Sunday and time is 21:00 o’clock, the rule “If it is Sunday and time is between 19:00 and 23:00, find me a MovieTheater which is closer than 2000 m” is fired. Consequently, nearby movie theatres are illustrated with a larger marker. By clicking on the markers he enjoys future, contextualized information.
In this work, an innovative knowledge-based LBSNS, called Geosocial SPLIS, was presented. Geosocial SPLIS a) collects data from sources such as Google Places API and Google+, b) adopts schema.org ontology, c) offers users the capability to insert rules at run time via a web based editor, d) converts these rules into RuleML and Jess, e) uses Google Maps for information presentation. On the one hand, regular users enjoy proactively POIs and offers depending on their preferences and their contextual situation, and on the other, POI owners (by being able to specify their offering policy rules) deploy their marketing strategy more effectively by reaching their potential customers right on time.
Geosocial SPLIS service can evolve in the future in various ways. Our current research interest is focusing on integrating data about users and POIs from other web sources (e.g. Facebook, Twitter, OpenStreetMaps etc.). Furthermore, system’s maintenance will be taken into consideration (e.g. checking for POIs that have been closed or changed). Moreover, there are plans to expand the web editor to provide contextualized preferences concerning movies, videos etc. Finally, it is worth mentioning that an extensive user evaluation and comparison with related services is also in progress to denote Geosocial SPLIS’s technical capabilities.