Geosocial SPLIS: A Rule-Based Service for
context-aware point of interest exploration
Iosif Viktoratos1, Athanasios Tsadiras1, Nick Bassiliades2,
1
Department of Economics, 2Department of Informatics
Aristotle University of Thessaloniki, GR-54124 Thessaloniki, Greece
{viktorat, tsadiras, nbassili}@auth.gr
Abstract. This paper presents the design and implementation of a novel
geosocial semantic service called “Geosocial SPLIS” (GeoSocial Semantic Per-
sonalizing 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.
Keywords: Semantic Web, Ontologies, Rules, Context, Location Based Ser-
vices, Points of Interest, Preferences, Group-Targeted Offers.
1 Introduction
Location Based Social Networking Services (LBSNs) have become very popular over
the past few years [1, 2]. Applications such as Facebook Places1 and Foursquare2 are
used consistently by lots of people for discovering interesting places and connecting
them with their nearby friends. Due to the fact that a LBSN’s user environment is
complex and changes rapidly, deep contextual knowledge is necessary [3].
Semantic web technologies such as ontologies and rules gave a huge boost to con-
text awareness. First of all, ontologies enable high quality context perception by rep-
resenting concepts such as persons, POIs etc. Furthermore, by providing a general
representation standard, they enable reusability and interoperability among different
systems in the web [4]. Ontologies are often combined with rules for increased ex-
pressiveness because rule-based systems are more intelligent and reactive, being able
to conceive context changes and respond accordingly without user intervention [5].
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+” [6] and “SPLIS” [7]. SPLIS (the most recent of previous
versions) supports a web editor so as POI owners to be able to assert their own prop-
erties and group targeted offering policies (e.g. “If a person is unemployed and day is
1
https://www.facebook.com/about/location
2
https://foursquare.com
3
Can be accessed at http://tinyurl.com/GeoSemSer
Friday then spaghetti price has discount 10%”). These offering policies are then rep-
resented 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. Final-
ly, 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 tar-
geted 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.
1.1 Motivation and related work
The motivation of our work is to combine semantic web technologies with LBSNSs
and present qualitative personalized information to user. Everyday life situations pre-
sent strong daily patterns and are not completely random [8]. For example, a user
usually visits a bar at night or an art gallery if it is morning. Therefore, our aim is to
provide users with the capability to design, model and share such preferences and
flexible customize their experience. User defined rules are more consistent and effec-
tive than those of the developers and can provide personalized information of higher
quality.
There are various approaches that inspired our service. For example, Serrano et al.
[9] implemented a tourist information service, which collects RDF data from foaf
profile and uses predefined SWRL rules to suggest interesting POIs to user. Similarly,
Ciaramella et al. [10] utilized SWRL rules to conceive user context and offer a set of
available services proactively to him/her. Last but not least, Croitoru et al. [11] devel-
4
https://plus.google.com
5
Geosocial SPLIS Sesame server can be accessed at http://platon.econ.auth.gr:8080/openrdf-
sesame and data can be accessed at http://platon.econ.auth.gr:8080/openrdf-
workbench/repositories/3
6
https://maps.google.gr
oped a service which gathers and incorporates geosocial knowledge from various
heterogeneous social media sources (e.g. Twitter7 ).
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 demon-
strated. Finally, section 5 discusses the conclusions of our work and indicates future
directions.
2 Architecture
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 applica-
tions as well [12].
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 [13]. Reaction
RuleML was chosen because it can represent production (Condition Action) rules,
which is the appropriate category to represent regular user’s and POI owners’ rules.
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 [14]. RuleML rules are transformed to Jess rules by using XSLT files
[15].
Last but not least, usual client side technologies such as HTML, AJAX and JavaS-
cript were utilized. Geosocial SPLIS’s server is based on Java Server Pages (JSP)
technology.
Google schema.org RDFS
Google Places API POI websites Google+
POI Ontology POI Data User profile
Data & Rules Data & Rules
Facts and Data Storage/
Rules Inference Geosocial Query
Jess SPLIS server Sesame
RDF
Data
Data and rules
POI data and
rules
Geosocial SPLIS Client
Fig. 1. Geosocial SPLIS architecture.
7
https://twitter.com/
3 Geosocial SPLIS’s operations
This section describes in detail the service’s operations. It supports the above opera-
tions:
1. Information presentation operation.
2. Operations about rules.
3. Operations that utilize social connections
4. The planning mode operation.
3.1 Information presentation operation
The operations that need to be completed in order the service to present suitable in-
formation 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 com-
patible 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 en-
gine. 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 con-
textual 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) A larger in size marker represents a place which is suitable for the user’s
preferences and it is suggested.
b) A red marker illustrates a POI which has no offering policies at all.
c) 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).
d) 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).
e) 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 Operations about rules
This section includes a detailed discussion about regular users’ rule based prefer-
ences. A detailed reference regarding POI owners’ operations relating to rules (group
targeted policies) can be found in [6].
Rule insertion operation via editor. Regular users can add their rule based prefer-
ences 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 contex-
tual 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 spe-
cific 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 sali-
ence 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 en-
riched 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.
Fig. 2. Rule editor usage example
Table 1. Rule representations in RuleML,Jess and RDF format
RuleML representation
If day is Friday, then I would like to go to a CafeOr-
CoffeeShop which is closer than 550m placetype CafeOrCoffeeShop uriidpersondayfridaydistanced<d550recommendationidid
Jess representation
(defrule aehfgdhf (declare (salience 1))
(place( type CafeOrCoffeeShop) ( uri ?id))
(person (distance ?d) ( day friday)) (test (< ?d 550))
=>(assert (recommendation( id ?id)))
(store EXPLANATION "If day is Friday, then I would like to go to a
CafeOrCoffeeShop which is closer than 550m "))
RDF triples representation
.
"IF person:distance < 550 AND person:day is Friday THEN I WOULD LIKE
TO GO TO A place:type CafeOrCoffeeShop";
"If day is Friday, then I would like to go to a CafeOrCoffeeShop which
is closer than 550m ".
……
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.
3.3 Planning operation
Another operation which is supported to denote the technical capabilities of Geosocial
SPLIS is the “planning mode”. By selecting the corresponding option from the avail-
able 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 depend-
ing 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.
3.4 Operations that utilize social connections
Common social interaction processes. First of all, users are capable of interacting
each other and creating social ties. They can search for other people, view their pro-
files and send a request text to them, asking to become friends. Users who are friends
among each other can also view each other rules.
Nearby friends’ mode. A user can find his/her friends which are close to him/her and
spot POIs and offers for all of them. In this mode Geosocial SPLIS:
a) Collects i) user’s rules, ii) his friends’ rules (if they are logged in) and iii)
contextual information.
b) Executes the above rules and gets the nearby POIs that are suggested by the
fired rules.
c) Executes these POIs’ rules taking into account all users contexts (the user
and his/her friends).
d) Visualizes information by adopting the following approach:
Uses a red marker to represent a POI which does not contain any of-
fers.
Utilizes a yellow marker to represent a POI that contains a rule base
which does not match anyone (user and friends) at this moment.
A half yellow-half green marker indicates that the POI has a valid
offer for at least one of them.
A green marker is used for a POI which has an offer for all of them
A larger in size marker indicates that the specific POI is suggested
by a user’s rule and at least one of his/her friends’ rules.
This operation will become clear with a use case scenario in the next section.
4 Use case scenarios
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 de-
scribed above and have the rules that are illustrated in table 2.
Table 2. Users’ rules
Peter’s rules Helen’s rules
Rule 1 “If it is Friday between 14:00 “On Friday afternoons (13:00-
and 17:00, I would like to 16:00), suggest me some Restau-
visit a coffee shop ” rants”
“If it is Sunday and time is “I would like to go for coffee, if
Rule 2 between 19:00 and 23:00, find it is Friday and weather is Sun-
me a MovieTheater which is ny”
closer than 2000 m”
4.1 Scenario about an individual person
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 illus-
trated 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 con-
tains the group targeted offer “Students are entitled 50% discount in espresso on Fri-
days”). 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 res-
taurants 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 ex-
planations, Peter and Helen can easily get some of the three most popular rules a) of
all users or b) of their friends.
Fig. 3. Starting screen for Peter
a)Personalized info for Peter regard- b) Personalized info for Helen re-
ing “Ambasso” garding “Mr Jones Cafe”
Fig. 4. Personalized info concerning the two users and the place “Friends Cafe”
4.2 Scenario about nearby friends’ mode
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 illus-
trated 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 com-
prehend 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).
Fig. 5. “Nearby friends” mode for Peter
a) b)
Fig. 6. Personalized information for Peter regarding a) “MOJO cafe bar” and b)
“Ambasso”.
4.3 Scenario about planning mode
Let’s now consider a scenario where Peter has to visit London after two days (in Sun-
day) 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 be-
tween 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.
Fig. 7. “Planning mode” screen for Peter.
5 Conclusions and future work
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 re-
search 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 men-
tioning that an extensive user evaluation and comparison with related services is also
in progress to denote Geosocial SPLIS’s technical capabilities.
References
1. O. Roick , S. Heuser. Location Based Social Networks – Definition, Current State of the
Art and Research Agenda. Transactions in GIS. Volume 17, Issue 5, 763–784(2013)
2. Zheng Y., Xie X. and Ma, W.Y. GeoLife: A Collaborative Social Networking Service
among User, Location and Trajectory, IEEE Data Eng. Bull. 33 (2), 32-39 (2010)
3. S. Ilarri, A. lllarramendi, E. Mena, A. Sheth. Semantics in Location-Based Services. IEEE
Internet Computing (Vol. 15, No. 6) pp. 10-14 (2011)
4. Patkos T, Bikakis A, Antoniou G, Plexousakis D, Papadopouli M.A semantics-based
framework for context-aware services: lessons learned and challenges. In: Proceedings of
4th international conference on Ubiquitous intelligence and computing (UIC-2007), Vol.
4611 of LNCS, Springer, pp 839–848(2007)
5. A. Giurca, M. Tylkowski, M. Muller. RuleTheWeb!: Rule-based Adaptive User Experi-
ence. 2012. Proceedings of the RuleML2012@ECAI Challenge, at the 6th International
Symposium on Rules, Montpellier, France, August 27th-29th, 2012, CEUR Workshop
Proceedings, Vol-874 (2012)
6. Viktoratos I., Tsadiras A., Bassiliades N. 2013. PLIS+: A Rule-Based Personalized Loca-
tion Information System. RuleML2012@ECAI Challenge, at the 6th International Sympo-
sium on Rules, Montpellier, France, August 27th-29th, (2012)
7. Viktoratos I., Tsadiras A., Bassiliades N. 2013.A Rule Based Personalized Location In-
formation System for the Semantic Web.14th International Conference, EC-Web 2013,
Prague, Czech Republic, August 27-28. Proceedings. pp 27-38 (2013)
8. Jie Bao , Yu Zheng , Mohamed F. Mokbel, Location-based and preference-aware recom-
mendation using sparse geo-social networking data, Proceedings of the 20th International
Conference on Advances in Geographic Information Systems, November 06-09, 2012,
Redondo Beach, California
9. D.Serrano, R. Hervás, J. Bravo. Telemaco: Context-aware System for Tourism Guiding
based on Web 3.0 Technology. International Workshop On Contextual Computing and
Ambient Intelligence in Tourism (2011)
10. Ciaramella, A., Cimino, M.G., Lazzerini, B., Marcelloni, F. Situation-Aware Mobile Ser-
vice Recommendation with Fuzzy Logic and Semantic Web. Ninth Int. Conference on In-
telligent Systems Design and Applications, IEEE (2009)
11. A. Croitoru, A. Crooks, J. Radzikowski, A. Stefanidis 2013 Geosocial gauge: a system
prototype for knowledge discovery from social media. International Journal of Geograph-
ical Information Science Vol. 27, Iss. 12.
12. Broekstra J., Kampman A., and van Harmelen F. Sesame: An architecture for storing and
querying RDF data and schema information. In H. Lieberman D. Fensel, J. Hendler and
W. Wahlster, editors, Semantics for the WWW. MIT Press (2011)
13. Paschke A., Kozlenkov A., H. Boley. A Homogenous Reaction Rule Language for Com-
plex Event Processing, 2nd International Workshop on Event Drive Architecture and
Event Processing Systems (EDA-PS 2007), Vienna, Austria, (2007)
14. Ernest Friedman-Hill: Jess in Action.Rule-Based Systems in Java. Manning Publications.
ISBN-10: 1930110898, pp. 32-33(2003)
15. G. Sherman. A Critical Analysis of XSLT Technology for XML Transformation. Senior
Technical Report (2009)