Recommender System for Crops & Varieties Selection A Farmer Centered Approach DISSERTATION SUBMITTED TO THE GLOBAL OPEN UNIVERSITY OF NAGLAND IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE AWARD OF THE DEGREE OF MASTER OF PHILOSOPHY BY GAURAV KUMAR AGARWAL QQ DEPARTMENT OF COMPUTER SCIENCE GLOBAL OPEN UNIVERSITY NAGALAND INDIA 2009
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Recommender System for Crops & Varieties Selection
A Farmer Centered Approach
DISSERTATION SUBMITTED TO THE GLOBAL OPEN UNIVERSITY
OF NAGLAND
IN PARTIAL FULFILLMENT OF THE REQUIREMENTS
FOR THE AWARD OF THE DEGREE OF
MASTER OF PHILOSOPHY
BY
GAURAV KUMAR AGARWAL
QQ
DEPARTMENT OF COMPUTER SCIENCE
GLOBAL OPEN UNIVERSITY
NAGALAND
INDIA
2009
CERTIFICATE
This is to certify that the work embodied in this dissertation entitled RECOMMENDER
SYSTEM FOR CROPS & VARIETIES SELECTION – A FARMER CENTERED
APPROACH has been submitted to Department of Computer Science, Global Open
University, Nagaland. The work presented in this dissertation has not been submitted in
parts or full to any other university for any diploma or degree.
Gaurav Kumar Agarwal
(Candidate)
Dr. Sudeep Marwaha
(Supervisor and Scientist (SS)
Division of ComputerApplications IASRI,
Pusa, Delhi)
ii
Abstract
As information mounts it leads to the problem of how to access, navigate through,
and select available options. One possible solution to the problem is based on recommender
systems or the concept of automatic recommendation generation. A recommender system
recommends items to users by predicting items relevant to the user, based on various kinds
of information including items, user information and interactions between users and items.
Recommender systems form a specific type of information filtering technique that attempt
to present information items such as movies, music, books, news, images, web pages, that
are likely to be of interest to the user. Typically, a recommender system compares the
user's profile to some reference characteristics. These characteristics may be from the
information item (the content-based approach) or the user's social environment (the
collaborative filtering approach) or combination of both (Hybrid-filtering approach). These
systems are very powerful cognitive decision – makers in the context of distributed online
information processing in real – time networked scenarios.
Recommender Systems have now evolved to trust – based recommender systems where the
trust component has been modeled using soft computing techniques. Thus the
recommender systems have graduated from being intelligent decision – support systems to
human – level AI systems. Trust plays an important role in the decisions related to sources
that are used by humans to take recommendations. We do not go out on the street and just
start taking recommendations from anyone on the street, but opt for our trustworthy
acquaintances to suggest us products. In real life, we use the data provided by others, but
process it according to our own reasoning power, into information that we use for decision
making. If recommender systems also use advice seeking and decision making process
similar to real life, then it will be easier for the user to trust the recommendations of the
system. Hence, by adding a trust component to a decentralized environment the problem of
lack of trust on the recommenders is alleviated.
There are number of domain experts (agriculture scientists) each having knowledge of their
domain according to their own perspective. Now, if the farmer wants information about the
iii
varieties of a crop that can be grown in a specific zone such as Uttar Pradesh, he may
contact the domain experts who provide their knowledge of the specific problem area such
as pathology (Disease related problems) or entomology (insect/pest problems). Thereafter
accordingly the farmer processes the information gathered according to his specification.
As the experts may be geographically distributed, this knowledge engineering problem is a
distributed computing problem.
Research literature on intelligent agent system architectures has established that problems
that are inherently distributed can be efficiently implemented as a multi agent system. So
we propose a prototype recommender system for agriculture that helps the farmers to find
the best possible crops / set of varieties which can be grown on the farmer’s field. This
prototype recommender system is based on a multi-agent system approach, where every
user in the prototype is represented by an agent. The agents communicate with others to
generate the recommendation using various techniques like Content Based, Collaborative
and Hybrid approach.
.
iv
Acknowledgements
It gives me immense pleasure to extend my thanks to those who
provided inestimable support for the completion of my work.
In the first place I would like to record my gratitude to Dr. Sudeep
Marwaha for his supervision, advice, guidance from the very early stage of
this research and for patiently guiding me through the dissertation process. I
gratefully acknowledge him for his crucial contributions, which made him a
backbone of this dissertation.
I would like to thank my brother Mr. Sumit Agarwal for the valuable
suggestions he had provided during this work.
Further, I would like to thank Mrs. Jotsna, staff of Global Open
University Nagaland, for her prompt help whenever I approached her.
I thank my parents, and in-laws, for their faith in me and allowing me to
be as ambitious as I wanted.
I owe my loving thanks to my wife Mrs. Madhulika Agarwal, for all the
support and encouragement she had provided in spite of her hectic schedule. I
would also thank my little son Aryan Agarwal for letting me work on this
study by being patient and understanding.
I would like to thank all the people who have directly or indirectly
helped me in completing this dissertation.
GAURAV KUMAR AGARWAL
v
Table of Contents
Abstract ....................................................................................................................... i
Acknowledgement ................................................................................................ iii
List of Figures ......................................................................................................... vi
List of Tables .......................................................................................................... vii Chapter 1 Introduction ....................................................................................... 1 1.1 Problem Definition ................................................................................. 2 1.2 Overview of Dissertation ........................................................................ 2 Chapter 2 Review of Literature .................................................................... 4 2.1 Introduction ............................................................................................ 4 2.2 Working of Recommender System ......................................................... 5 2.3 Classification of the existing Recommender Systems ............................ 6 2.4 Techniques used by different types of Recommender Systems .............. 6 2.5 Evaluation of Recommender Systems ...................................................10 2.6 Technologies Used .................................................................................12 2.6.1 Multi Agent System ...................................................................12 2.6.2 JADE (Java Agent Development Environment) ........................13 2.6.3 APACHE TOMCAT (Web Server) ...........................................13 2.6.4 JAVA .........................................................................................13 2.6.5 JSP (Java Server Pages) .............................................................14 2.6.6 ORACLE 9i ............................................................................................ 15 Chapter 3 System Design ................................................................................ 17 3.1 Introduction ............................................................................................17 3.2 Basics of Intuitionistic Fuzzy Sets .........................................................17 3.3 Improving Recommender Systems with Trust .......................................19 3.4 Analysis .................................................................................................22 3.5 Methodology ..........................................................................................22 3.6 Algorithm ...............................................................................................27
vi
Chapter 4 System Architecture of Recommender system .......... 32 4.1 Introduction ............................................................................................32 4.2 System Architecture ...............................................................................33 4.3 Database Design ....................................................................................36 4.4 Implementation ......................................................................................44 Chapter 5 Conclusion ......................................................................................... 47 Annexure I ................................................................................................................. 49
The presence of trust in human society is unquestionable. All the relations and the
interactions thereof in human society are based on trust between the interacting
individuals. Trust helps an individual to safeguard its interests from harmful individuals
in the society and as agents are designed to behave like humans, trust should play an
important role during the interactions between the agents. The agents also, except for
trivial application domains, require interaction with other agents, i.e., application
domains require multi-agent systems. This interaction is required for sharing files and
services with the other agents in the application domain. Trust increases the robustness of
an agent by making it capable to safeguard its interests from harmful agents in the
application domain as in human beings.
3.3.2 Degree of trust
Trust is not dichotomous; rather it is a range. This means that trust may be graded and the
extent to which one is trustworthy is the degree of trust (DoT) of the entity. Degree of
trust can be defined as a subjective certainty of the pertinent beliefs. We have restricted
the range of degree of trust between 0 and 1.
3.3.3 Recommender System based on Trust
Agents interact with other peer agents in the application domain and exchange
information with each other. An agent forms trustworthy relationships with peers and the
suggestions from such trustworthy acquaintances are used in its decision making process.
These trustworthy relationships form a web of trust. The social network hence formed
helps an agent to get views of even those agents that are not directly known to it through
the agents known to it directly (Fig 2).
28
Fig. 2: Web of Trust
Fig 2 shows such a network of peers represented by the numbered circles, where the
numbers in the circles identify the various peers in the application domain. An edge
represents that trustworthy relationship exists between the connected agents with certain
degree of trust. Every agent maintains a list of peers adjacent to it along with the degrees
of trust on them. It is not necessary that if A trusts B with degree of trust as x then B also
trusts A with degree x.
The peer agents in the community environment exchange recommendations about
the products during their idle time, which we are referring to as the unintentional
encounters. The recommendations are list of products that the recommender has
suggested along with the degree of importance associated with it. An agent may
accumulate the recommendations of one specific agent through more than one
unintentional encounter. But one agent cannot be a part of more than one group at a given
instance. Since the idle agents are free to join the group of agents exchanging
information, such interactions are the unintentional encounters. When an agent wants to
find interesting products for it and explicitly seeks the recommendations from its
trustworthy agents, the interactions are termed as intentional encounters. The
unintentional encounters and their own experience with the products are used by
recommender agents to compute the information for recommendations to be given to the
user agent during the intentional encounters.
It is not feasible for an agent to know every peer in the network to be able to
assign a trust value to them, and then get recommendations from all of them. Rather the
6
98
75
4
3 2
1
29
agent may use the recommendations of those known to it, which may further take the
recommendations from those known to them and so on. This is on the basis of the
assumption that if A trusts B and B trusts C then A also trusts C, even though not
necessarily with the same degree of trust as it has on B. Let the circle with number 1 in
Fig. 2 represents the agent that wants to find interesting products for itself through its
network of acquaintances. All the agents that are directly linked to the user agent
participate in intentional encounters and give their recommendations to the user. Even the
agent that is not directly linked conveys its recommendation list to the user agent through
the intermediate agents.
Research in recommender systems to date has predominately focused on
designing algorithms for more effective and efficient computation of recommendations
[Breese et. al., 1998; Sarwar et. al., 2000b]. Even though the recommender systems may
be providing accurate recommendations, studies by Sinha and Swearingen [2001] have
found that users prefer the recommendations of friends over those of recommender
systems. This is because most of the existing recommender systems do not take into
account the social elements of advice seeking and decision-making, and hence the system
model does not match the mental model of the user [Bonhard, 2004]; and it is difficult
for the user to trust the system recommendations [Bedi P. and Kaur H, 2006 ].
Augmenting recommender systems with trust dimension in a decentralized
environment solves the problem of lack of trust on the recommender system. Trust plays
an important role in the decisions related to sources that are used by humans to take
recommendations. We do not go out on the street and just start taking recommendations
from anyone on the street, but opt for our trustworthy acquaintances to suggest us
products. In real life, we use the data provided by others, but process it according to our
own reasoning power, into information that we use for decision making. If recommender
systems also use advice seeking and decision making process similar to real life, then it
will be easier for the user to trust recommendations of the system. Hence, by adding trust
to decentralized environment alleviate the problem of lack of trust on the recommender
systems.
30
3.4 Analysis of the proposed Recommender System
The existing recommender systems do not generate their recommendations based on the
trust relationships that exist in the society, rather suggest products on the basis of
similarity between the users or the items. They ignore the social elements of decision-
making and advice seeking, and hence the system model does not match the mental
model of the user. The recommender agent does not know about the people whose tastes
are used to suggest products that may be of interest to the user, and this result in lack of
trust on the recommendations received from the system. Given a choice between
recommendations from friends and recommender systems, in terms of quality and
usefulness, friend’s recommendations are preferred even though the recommendations
given by the recommender system have high novelty factor [Sinha et. Al 2000]. Friends
are seen as more qualified to make good and useful recommendations as compared to
recommender systems.
In the presented recommender system, a social structure exists between the agents in the
application domain, which is formed on the basis of trust between them. The agents
recommend varieties to each other using this social structure. This is similar to the mental
model of decision making of a human.
Every agent in the system maintains a degree of trust and information about the tastes of
the agents that are connected to it directly. The recommenders pass only that
recommendation to the user agent that matches its taste leading to personalization of the
recommender system. This reduces the number of recommendations that need to be given
to the user agent by removing the unnecessary recommendations and this further reduces
the number of computations that the user agent has to perform at the aggregation of the
recommendations to find something useful for itself
3.5 Methodology of the proposed Recommender System
The proposed recommender system is a Multi Agent System (MAS) as illustrated in
Fig. 3. Most of the existing recommender systems ignore the social elements of decision-
making and advice seeking, and hence the system model does not match the mental
model of the user. These recommender systems are designed with a central authority
31
controlling the data as well as computational resources to generate recommendations. The
user does not know about the people whose tastes are used to suggest products. This acts
as a hindrance for the user to trust the recommendations of the system.
Fig.3 The Functional diagram of A RECOMMENDER SYSTEM-AFCA
The decentralized and distributed systems are increasingly becoming popular and
the recommender systems can take advantage of the huge amount of information that
they provide. These infrastructures provide the information in human understandable and
machine readable format. Recommender Systems can be designed in such a way that they
use the machine-readable information available with the user or user agent to infer the
user preferences and then generate personalized recommendations for the user.
32
To overcome the limitations of lack of trust and the central control in the existing
recommender systems, a trust based decentralized recommender system is being
proposed and a prototype is developed under this project. Every human user of the
recommender system is represented through an agent. The information is distributed over
the entire network in the form of information with the agents. The agents of the
application domain form a trust based virtual community referred to as “web of trust”.
The architecture provides ways to quantify degree of trust between the agents initially
when the system starts and also when a new agent comes into the application domain.
Trust is initialized to zero in the beginning or can be subjectively given by the
administrator of the system to give good recommendations, which is then updated on the
basis of interactions between the agents.
All recommender agents have their own knowledge about the varieties in specific Zone
stored in their own location. Hence, the recommender system being developed under A
RECOMMENDER SYSTEM-AFCA uses the decentralized database. A user agent asks
for recommendations from various recommender agents in its neighborhood, which in
turn can take recommendations from their trustworthy neighbors. The user agent then
prioritizes the received recommendations based on trust on recommenders and generates
a ranked list of recommendations for the user.
The prototype A RECOMMENDER SYSTEM-AFCA has two different types of agents:
1. User Agent (UA)
2. Recommender Agent (RA)
3.5.1 User Agent (UA): User sends the request to the UA. UA collects the data from the user using web based
GUI. It captures the information for the attributes to be considered for selection of a
variety and their degree of significance. UA also stores trust values for each interacting
recommender agent known to it and prioritizes the recommender agents according to
their trust value.
33
Temperature Spacing Plant Type Disease Resistance Ingredients
.7845 .6873 .5974 .2345 .2323
Table 1: Degree of significance of attributes of varieties
Recommenders R1 R2 R3 R4 R5
Degree of Trust 0.78 0.68 0.85 0.23 0.76
Table 2: Degree of Trust of user on the recommenders
Once, UA receives the recommendations from all trustworthy recommender agents in its
neighborhood, it generates the final recommendation list of varieties after taking into
account the degree of trust on each of the recommender agent. UA also updates the
degree of trust on each recommender agent after evaluating the recommendations given
by them.
3.5.2 The Recommender Agent (RA): The Recommender agent (RA) after getting a request from user agent generates a set of
recommendations in order to best satisfy the incoming request. Every recommendation
corresponds to a variety for a specific crop for a given Zone is in the form of
Intuitionistic fuzzy Set (IFS). The IFS recommendation for a variety has a degree of
membership (satisfaction), degree of non-membership (dissatisfaction) and the degree of
hesitation (uncertainty) signifying the relevance, irrelevance and uncertainty of the
variety for a given user. To personalize the variety recommendations according to the
taste of the user agent A, the recommender agent maintains the following lists:
• Preference list: The preference list, PA consists of the information in terms of the
attributes (Temperature, spacing, plant type, disease resistance, Ingredients etc.) of
the varieties liked by the user in the past connected to user agent A. There are
separate sublists in PA corresponding to the attributes Temperature, spacing, plant
type, disease resistance, Ingredients. The order of names of varieties in a sublist in PA
34
corresponding to a particular attribute signifies their priority in their respective
sublists.
Preferences in the sublists ( PA )
Temperature V3 V5 V2 V1 V4
Spacing V1 V2 V4 V3 V5
Plant Type V2 V5 V4 V1 V3
Disease Resistance V1 V3 V2 V5 V4
Ingredients V5 V4 V3 V1 V2
Table-3: Preference List (all the sublists) about taste of user maintained by recommenders
• Uncertain list: The uncertain list, UA consists of the same type of information as that
of the preference list. However, it is unordered list accumulated during unintentional
encounters and the recommender agent has no idea whether the user prefers one
variety over the other.
Uncertain List (UA )
V6 V8 V7 V10 V9
Table-4: Uncertain List (UA) about taste of user maintained by recommenders
In this research work, we are trying to build a prototype for a system similar to a social
recommendation process. The system is also capable of recommending a variety to a user
if the variety has a general appeal. In such cases, if the user likes the variety that actually
does not conform to his/her tastes explicitly mentioned, the user agent gives a feedback to
the recommender agent(s) who recommended that particular variety. The recommender
agent on getting the feedback from the user agent adds the variety in the preference list
for that user.
35
3.6 Algorithms used in proposed Recommender System:
3.6.1 Generating Recommendations
Various ways in which a recommender agent recommends a variety are:
• Case 1: The variety is in the preference list corresponding to the user stored in
the recommender agent.
• Case 2: The recommender agent comes to know about the variety through a
trustworthy acquaintance during unintentional encounters.
• Case 3: The recommender has used the variety, and feels that the variety has a
general appeal even if it does not conform to the tastes of the user. Recommender
agent recommends that variety to the user with the degree of uncertainty. The
degree of uncertainty signifies the extent to which the recommender is not sure
about his/her decision to suggest that variety to the user. The degree of
membership is zero for such varieties and the third parameter is computed using
the other two degrees. All such varieties are recommended to the user.
The varieties of case 3 are recommended whether they are according to the tastes of the
user or not. For the varieties of case 1 and case 2, matching is done with PA and UA and
based on the matching results, the recommendation is generated.
3.6.1.1 IFS generation for Varieties
A recommender can recommend varieties known to it. The recommender agent comes to
know about the variety either through usage or through unintentional encounters. During
the unintentional encounters, an agent exchanges the information about only those
varieties that it has used and is satisfied with.
An agent stores the names of the experienced varieties. When an agent has to generate
recommendations for other agent, it retrieves knowledge about experienced varieties.
Let a variety V be represented by n attributes (a1, a2… an). A variety V is suggested to the
user agent A, along with the IFS generated for it as shown below:
36
1. The degree of membership of variety V, μv is computed using the preference list PA, as: 1.1 For every attribute ai (i = 1, …, n) of variety V, do the following:
1.1.1 Search the position pi of variety V in preference list PA then compute the
rank Ranki as the normalized position of V in the range [0 to 1] using the
following formula:.
Ranki = 1- ((pi – 1) / (max-1))
where
max represents total number of varieties exist in PA
1.1.2 Finally, degree of membership of variety V, μv is computed as:
μv = n
rankdan
iii∑
=1)*(
where dai (i = 1, 2, …, n) represents the normalized degree of significance that
the user associates with the ith attribute,
n represents the total number of attributes of variety V in PA.
2. The degree of uncertainty of variety V, πv is computed using the uncertainty list UA,
created during the unintentional encounter among the trustworthy agents and on the
experienced varieties of the recommenders that are not matched with varieties of PA
as:
2.1 πv is computed from PA, using the experienced varieties list by assigning the
satisfaction values of V, greater than some threshold value.
2.2 πv is computed using the uncertainty list UA, as:
2.2.1 Let ki be the attribute value of V for attribute ai in UA.
2.2.2 Compute the degree of uncertainty of the V as:
n) k da ... k da k (da nn22 11 ∗++∗+∗
=vπ
where, dai (i = 1, 2, …, n) represents the degree of significance that the user associates with the ith attribute.
n represents the number of varieties in UA. The degree of non-membership of variety V, νv is computed as follows:
vv - - 1 πμν =v
37
3.6.1.2 Recommendation List Generation by Recommender Agent After matching the varieties with the preference list and uncertain list, the degree of
membership, degree of non-membership and uncertainty is available with the
recommender agent for all the varieties that it knows. The following method is used to
generate the final list of the varieties that are to be recommended to the user agent along
with IFS that is computed for them:
1. All the varieties that are part of case 3, section 3.6.1 are to be considered for
further processing.
2. For all the varieties of case 1 and 2, section 3.6.1, do the following:
2.1 The varieties with non-zero degree of membership are followed by the
varieties with non-zero degree of uncertainty.
2.2 Within the varieties with non-zero degree of membership, order the
varieties in descending order on degree of membership.
2.3 Within the varieties with non-zero degree of uncertainty, order the
varieties in descending order on degree of uncertainty.
3.6.2 Final Recommendation List Generation by User Agent
The user agent needs to form an aggregated list out of the IFS recommendations lists
received from the trustworthy recommender agents. User agent has to generate a final
consolidated list from all the recommendations that are received from the
recommenders. The user agent computes the degree of importance of a variety on the
basis of degree of trust on the recommenders who have recommended the variety, the
relative position of the variety in the list of recommenders and the IFS
recommendation of the recommender. The user agent generates a final consolidated
list from all the recommendations that are received from the recommenders using the
following aggregation method:
1. First identify the distinct varieties from the lists and then compute the degree of
importance (DoI) of every variety (Vi) as follows: ( ) ( ) ( ) ( ) ( )
( ) ( ){ }( ) ( ) ( ) ( ){ } ( )))(
)),......()()((),}{((
22222
11111
kikikikik
iiii
iiii
RRankRRRRDoTABSRRankRRRRDoTABS
RRankRRRRDoTABSMAXDoI
∗∗−∗∗∗−∗
∗∗−∗=
πνμπνμ
πνμ
38
where,
DoIi(A) is degree of importance of Vi as computed by A,
Rj is the jth recommender,
μi(X) is the degree of membership of Vi according to recommender X,
νi(X) is the degree of non-membership of Vi according to recommender X,
πi(X) is degree of uncertainty or hesitation of Vi according to recommender X,
DoT(Rj) is the degree of trust of the A on Rj,
Ranki(Rj) is the normalized position of Vi in the recommendation list of Rj,
k is the total number of recommenders who have recommended Vi.
2. Compute the threshold, TDOI for degree of importance as
TDOI = μ – ν * π
where,
μ, ν and π are degree of membership, non membership and uncertainty,
respectively that the user agent expects from the interesting variety.
3. For all the distinct varieties, Vi of step 1, the degree of importance obtained is a
real number that lies between 0 and 1; and hence there is no need for its
normalization. Arrange the products in the descending order of their degrees of
importance.
3.6.3 Initializing and Updating Degree of Trust on the Recommenders
3.6.3.1 Trust Initialization When a new agent comes up in the system or the system starts from the scratch, then the
agents have to initialize the trust values for some of the other agents in the application
domain to form its acquaintance set. If an agent is known to the other agent (i.e., the
corresponding humans know each other), then the human associated with the agent can
initialize the degree of trust according to the personal dealings with the person. However,
the system also allows an agent to initialize degree of trust on an agent X, on the basis of
the experiences of the other agents with X, i.e., to what extent the other agents in the
39
application domain have received good recommendations from X. The degree of trust is
then regularly updated on the basis of the personal experience of the agent with X.
The new agent Y, asks for the experience of known agents’ (connected to it) w.r.t. X. Let
q agents return their experience values as the number of good recommendations received
to the total number of the recommendations received from X. Let jth agent gives the
experience as ej. Then the degree of trust on X is as following:
q
eXDoT
q
jj∑
== 1)(
where, DoT(X) is degree of trust as computed by Y on X.
If q is large, then basically we are interested in finding what is the experience of
majority of the agents? Then experiences can then be clustered and degree of trust can be
computed [Kaur et al., 2005].
3.6.3.2 Trust Updation The degree of trust on a recommender is updated on the basis of the distance between
degree of importance of the variety as it is there in the aggregated list of the user agent
(A) and the recommendation list of the recommender (R). The difference of opinion
between the user and the recommender is computed as follows: ( )
μ, ν, π; and μi(R), νi(R), πi(R) are as defined earlier.
p is the total number of varieties in the recommendation list of R.
Depending upon whether the difference between its aggregated list and the
recommendations is below its acceptable threshold dt or not, the user agent updates the
degree of trust, DoT(R) on recommender as follows:
DoT(R) = DoT(R) + (dt – d) In our model, hence trust increases for those who give good recommendations and vice-versa.
40
Chapter 4
System Architecture of Recommender System 4.1 Introduction:- In the present context, there are number of domain experts (Farmers) each having
knowledge of their domain according to their own perspective. Now, if the user wants
information about the use of strategies and set of varieties that can be deployed in a
specific Zone such as Uttar Pradesh, Himachal Pradesh, he may contact the domain
experts who provide their knowledge of the specific problem area. Thereafter accordingly
the user processes the information gathered according to his specification. As the experts
may be geographically distributed, this knowledge engineering problem is a distributed
computing problem. Research literature on intelligent agent system architectures has
established that problems that are inherently distributed can be efficiently implemented as
a multi agent system. So the prototype proposes the solution based on a multi-agent
system approach, where every user in the prototype is represented by an agent. The
agents communicate with others to generate the recommendation using various
techniques like Content Based, Collaborative and Hybrid approach.
The prototype “A Recommender System for Crops & Varieties Selection-A farmer
Centered Approach” addresses the influence of Zone over varieties system operates. The
prototype integrates the knowledge of various domain experts (farmers) thereby
providing a solution to its users by recommending a set of varieties that is useful and can
be used for a particular Zone. This in turn expands the user knowledge regarding the
effects of Zones.
Using this Recommender System a user can get the recommendation on the use of
variety/ set of varieties in a user specified Zone from the available set of varieties, it takes
into account the influence of Zone over which farmers and varieties systems operate
thereby expanding the body of knowledge regarding the effects of Zone. The prototype
41
combines several domain experts’ knowledge to compute the recommendations. Thus, in
order to cover a certain range of tactical engagements, a recommendation for a set of
varieties will be obtained.
4.2 System Architecture:-
4.2.1 Program Structure Program structure defines the boundaries of the system within which the system will be
developed. This head provides pictorial view of the system which helps in understanding
various modules and sub-system of the system. Information like how the system interacts
with the user, how the input given by the user produces the output, what are the various
processes available to the user, type of users that are available with the system, etc.
4.2.2 Architecture Diagram The overall system would be presented shown pictorially with Block diagram, DFD and
ERD of the proposed system.
Block Diagram
Figure 4, shows the interaction of the user with the prototype. User provides the Zone
description as input and the system in turn produces the recommended ranked variety list
under crops from which the user finally selects a variety(s) for use. The system comprises
of certain crop which contain number of varieties of similar attributes.
Zone Description Variety list as
recommendation
Figure 4: Block Diagram
RECOMMENDER SYSTEM FOR
CROPS. & VARIETIES SELECTION – A
FARMER CENTERED APPROACH
42
4.2.3 Data Flow Diagram
The data flow diagram as shown in figure 5 describes how the user interacts with the
system and the process flow of the system.
Figure 5: Data Flow Diagram
43
4.2.4 Entity Relationship Diagram Figure 6 shows the entity relationship diagram for the prototype under consideration.
Figure 6: Entity - Relationship Diagram
44
4.3 Data Design 4.3.1 Database Description
The database for the proposed system has the following relations, in which some of them
are static and some are dynamically created. The purpose and attributes of each of these
tables is explained in Annexure I.
Zone Info
Variety Info Field Name Type Keys Description
Variety_ID VARCHAR2(15) Primary Key
Variety_Name VARCHAR2(40)
Description VARCHAR2(80)
Crop Info Field Name Type Keys Description
Crop_ID VARCHAR2(15) Primary Key
Crop _Name VARCHAR2(20)
Description VARCHAR2(80)
Field Name Type Keys Description
Zone_ID VARCHAR2(15) Primary Key
Zone_Name VARCHAR2(20)
Description VARCHAR2(80)
45
Zone_Crop Info Field Name Type Keys Description
Zone_Crop_ID VARCHAR2(15) Primary Key
Zone_ID VARCHAR2(15)
Foreign Key on Zone_ID of
Zone Info.
Crop_ID VARCHAR2(15) Foreign Key on Crop_ID of
Crop Info.
(Zone_ID and Crop_ID) must be a candidate Key.
Attribute Info Field Name Type Keys Description
Attribute_ID VARCHAR2(15) Primary Key
Attribute_Name VARCHAR2(20)
Description VARCHAR2(80)
Crop_Attribute Info Field Name Type Keys Description
Crop_Attribute_ID VARCHAR2(15) Primary Key
Crop _ID VARCHAR2(15) Foreign Key on Crop _ID of Crop
Info.
Attribute_ID VARCHAR2(15) Foreign Key on Attribute_ID of
Attribute Info.
(Crop _ID and Attribute_ID) must be a candidate Key.
46
User Account Info Field Name Type Keys Description
User_ID VARCHAR2(15) Primary Key
User_Type VARCHAR2(20)
Description VARCHAR2(80)
User_Name VARCHAR2(20)
Password VARCHAR2(15)
Address VARCHAR2(50)
Phone_No NUMBER(10)
Designation VARCHAR2(20)
Crop_ Variety Info Field Name Type Keys Description
Crop _Variety_ID VARCHAR2(15) Primary Key
Variety_ Crop _ID VARCHAR2(15) Foreign Key on
Variety_ Crop _ID of
Crop Info.
Variety_ID VARCHAR2(15) Foreign Key on Variety-
_ID of Variety Info.
(Variety_ Crop _ID and Variety_ID) must be a Candidate key.
Attribute_Variety Info Field Name Type Keys Description
Attribute_ID VARCHAR2(15) .
Variety_ID VARCHAR2(15)
Value NUMBER(6,6)
(Attribute_ID, Variety_ID) must be a Candidate Key.
47
Ajay_Trust
Field Name Type Keys Description
User_Name VARCHAR2(15) .
Trust_On VARCHAR2(15)
Trust_Value NUMBER(6,6)
(User_Name, Trust_On and Trust_Value) must be a Candidate Key.
Ajay_Significance
Field Name Type Keys Description
Attribute_ID VARCHAR2(20) Primary Key
Significance_Value NUMBER(20,18)
Gaurav_Uncertain
Field Name Type Keys Description
Variety_ID VARCHAR2(20)
Gaurav_Final_Recommendation
Field Name Type Keys Description
Variety_ID VARCHAR2(15)
D_O_Imp NUMBER(8,6)
Ui_Vi_Pii NUMBER(8,6)
48
Gaurav_Variety
Field Name Type Keys Description
Variety_ID VARCHAR2(20) Primary Key
Satisfaction_Rate NUMBER(8,6)
4.4 Implementation Details
A Recommender System for Crops & Varieties Selection - A Farmer Centered Approach
is designed and developed using JADE (Java Agent Development Environment), JSP and
Oracle 9i. An experiment is conducted in which 10 domain experts (farmers) were asked
to help the users decide about which variety to use in a specific zone. The dataset is
collected from the IASRI for generating the recommendations and trust updation. This
dataset contained the details of 10 zones, 12 crops, 15 varieties under each crop category
and 6 variety attributes.
The AFCA system starts with 10 recommender agents (domain experts), who have their
own knowledge about the varieties in specific zone stored in their own location. User
agent creates when user logs into the system. The user agent has a certain degree of trust
on these recommender agents, which is represented in the Table-2. In Table -1, degrees
of significance that the user agent associates with the attributes of a variety. The Table –
3 gives the preference list that the user agent gave to the recommender agents. The
information in the Table – 4 is what the recommender agents know, during the
unintentional encounters.
User agent receives the query regarding variety recommendation from the user and passes
this query to its trustworthy recommender agents. The recommender agents respond with
the degrees of membership and non-membership about the varieties. Finally the
aggregated list of all the recommendations as computed by the user agent and given to
user.
49
The following snapshots give the implementation details of the AFCA system and which
will guide the user how to interact with the system.
4.4.1 Login
This is first screen that displays. It allows the user to access different screens based upon
the user’s role. Administrator, Domain expert and User are different roles assigned to
user. User with administrator role has to login first for successfully starting the
application.
Fig.7 Login window of AFCA
4.4.2 Domain Expert Agents
Once administrator successfully logs into the system then all the domain expert agents
run automatically. These agents were created in the JADE (Java Agent Development
Environment). Fig.8. shows agent environment in which domain expert agents are
running.
50
Fig.8 Agent Environment
4.4.3 Unintentional Encounters
The recommender agent comes to know about the variety through unintentional
encounters. During the unintentional encounters, an agent exchanges the information
about only those varieties that it has used and is satisfied with. Fig.9 shows the
information exchange among the agents during unintentional encounters.
Fig.9 Information exchange among the agents during unintentional encounters
51
4.4.4 Recommender’s known varieties details
For creating a known variety list user selects the variety from the existing variety list to
known variety list shown in Fig.10 then user fills the satisfaction in percentage for the
experienced varieties shown in Fig 11.
Fig.10 Selection of user’s known variety list
Fig.11 User’s known variety details
52
5.2.5 Recommender’s experienced variety details
The system allows the recommenders to share the experienced varieties knowledge.
Recommender selects the appropriate zone and crop under which he experienced the
varieties then he selects the list of experienced varieties from the pool of existing list
shown in Fig-12. Fig 13 shows the recommender ranks the list of selected varieties
according to variety attributes.
Fig.12 Selection of experienced varieties
Fig.13. Ranking of varieties according to the variety attributes
53
5.2.6 Update trust
Trust of the user on recommenders is updated by the system implicitly based on
importance of recommendation for the user. System also allows the user to explicitly
update the trust on the recommenders shown by Fig 14.
Fig. 14 Updation of trust of the user over recommenders
5.2.7 Recommendation Generation
System captures the information of degree of significance for the variety attributes shown
in Fig 15 then system allows the user to select the zone over which variety has to use
shown in Fig.16. After that system generates the recommendation list for the specified
zone shown by Fig.17.
Fig.15 Grade the degree of significance
54
Fig.16 Selection of zone for generating the recommendation
Fig.17 Recommendation Report
55
Chapter 5
Conclusion and Future Work
The research work “Recommender System for Crops & Varieties Selection -A Farmer
Centered Approach” addresses the influence of Zone over which farmers and variety
systems operate. The prototype integrates the knowledge of various domain experts
thereby providing a solution to its users by recommending a set of variety systems that
are useful and can be used for a particular Zone. This in turn expands the user knowledge
regarding the effects of Zone.
All existing recommender systems employ one or more of a handful of basic techniques:
content-based, collaborative, hybrid. A survey of these techniques shows that they have
complementary advantages and disadvantages. This fact has provided incentive for
research in hybrid recommender systems that combine techniques for improved
performance.
Using this Recommender System a user can get the recommendation on the use of variety
/ set of varieties in a user specified Zone from the available set of varieties, it takes into
account the influence of Zone over which farmers operate thereby expanding the body of
knowledge regarding the effects of Zone. The prototype combines several domain
experts’ knowledge to compute the recommendations. Thus, in order to cover a certain
range of tactical engagements, a recommendation for a set of varieties will be obtained
The existing recommender systems base recommendations on similarity between the user
and the recommenders or between the items. In the first case, the user profile is matched
with the database of profiles to find the similar profiles. The products preferred by those
similar people are suggested to the user also. In the second type of recommender systems,
the database is mined to find products that are normally preferred together. Depending
upon what user has already purchased/shown preference for; the other products that go
along with it are suggested to the user. However, the studies have shown that the users
56
prefer recommendations from friends as compared to the recommendations received from
these recommender systems. This is because the existing recommender systems work like
a black box and hence it is difficult for the user to accept the recommendations of the
system.
To overcome this problem of lack of trust on the recommendation systems this model
incorporates the social recommendation process. The trustworthy peers of the user
become the recommender agents and suggest varieties to the user according to the tastes
of the user. The agents in our system also learn from their experience in dealing with the
trustworthy peers and update the degree of trust on them. In this system, we have tried to
merge the advantages of the mechanical recommender system with the more human
recommendation process to make their recommendations trustworthy and useful for the
user.
Future versions of the present system can incorporate neural models of adversarial
strategies while computing recommendations.
57
Annexure I
a) Database Table Description
• User This table stores the details of the users, authorized to use this system.
Name Data type Description Remarks User_Id Varchar(20) Every user has a unique
user id, used for authentication
Primary Key
Password Char(10) It stores password given by user
-
User_name Varchar(20) It stores the name of the user
-
Address Varchar(20) It stores the address of user
-
City Varchar(20) It stores the city of user - State Varchar(20) It stores the state of user - Country Varchar(20) It stores the country of
user -
Phone Number(10) It stores the phone number of user
-
Institute_id Varchar(20) It stores the id of institute where the user works
Foreign Key-(Institute(Institute_id))
Usertype_id Varchar(20) It sorer the type of user Foreign Key-(UserType(Usertype_id))
• UserType
This table stores the different types of users permitted to uses the system:
Name Data type Description Remarks Usertype_Id Varchar(20) Every type of user has a
unique user type id Primary Key
Usertype Varchar(10) It stores the type of user - Usertype_desc Varchar(20) It stores the description
about that user type -
58
• Institute This table stores the details of the institute where the user belongs to.
Name Data type Description Remarks Institute_Id Varchar(20) Every institute has a
unique institute_id. Primary Key
Institute_Acro Char(10) It stores the acronym of the institure
-
Institute_name Varchar(20) It stores the name of the institute
-
Institute_Address Varchar(20) It stores the address of the institute
-
Institute_City Varchar(20) It stores the city of institute
-
Institute_State Varchar(20) It stores the state of institute
-
Institute_Country Varchar(20) It stores the country where the institute is located
-
Institute_Phone Number(10) It stores the phone number of the institute
-
Institute_fax Varchar(20) It stores the fax number of the institute
Foreign Key-(Institute(Institute_id))
Institute_website Varchar(20) It stores the website address of the institute
Institute_Email It stores the Email Id
• Proj_Basic_Data: This table contains the data regarding the project
Name Data type Description Remarks Proj_Code Varchar(20) Every project title is given
an unique id Primary Key
TiTle VarChar(200) The title of the project is stored here
-
Proj_Start_Date Date It stores the date when the project was started
-
Proj_End_Date Date It stores the date when the project came to an end
-
Institute_Id Varchar(20) It stores the city of user Refers Institute(Institute_id)
PI_Name Varchar(20) It stores the name of PI of that project
Refers Users(User_Id)
Status Char(10) The staus “new”,”comp”, “ongoing” is stored
59
• Proj_Objective This table stores the Objectives corresponding to
each Project Title Name Data type Description Remarks Proj_objective_Id Varchar(20) Every Objective is
given an unique Id Primary Key
Pcode Varchar(20) The project Titlecode is given here
Refers Proj_Basic_Data(Proj_Cde)
Proj_Objective Varchar(200) The objective statement is given here
-
• Proj_Activity The descriptions of all the activities are mentioned in this table
Name Data type Description Remarks Proj_Actv_Code Varchar(20) Every Activity
is given an unique Id
Primary Key
Proj_Obj_Id Varchar(20) The Id of the Objective to which the activity belongs to is mentioned
Refers Proj_Objective(Proj_Objective_Id)
Proj_Activity Varchar(200) The activity statement is given here
-
60
Annexure II
RiTa.WordNet Libraries
Fields RiWordNet.ADJ String constant for Adjective part-of-speech
RiWordNet.ADV String constant for Adverb part-of-speech
RiWordNet.NOUN String constant for Noun part-of-speech
RiWordNet.VERB String constant for Verb part-of-speech
Methods exists() Checks the existence of a ‘word’ in the ontology
getAllAlsoSees()
Returns also-see terms for all senses ofword/pos or null if not found Holds for nouns (?) & adjectives Example: happy -> [cheerful, elated, euphoric, felicitous, joyful, joyous...]
getAllAntonyms()
Returns String[] of Antonyms for the 1st sense of word with pos or null if not found Holds for adjectives only (?)
References
61
getAllCoordinates()
Returns coordinate terms for all sense of word/pos, or null if not found X is a coordinate term of Y if there exists a term Z which is the hypernym of both X and Y. Examples:
• blackbird and robin are coordinate terms (since they are both a kind of thrush)
• gun and bow are coordinate terms (since they areboth varieties)
• fork and spoon are coordinate terms (since they are both cutlery, or eating utensils)
• hat and helmet are coordinate terms (since they are both a kind of headgear or headdress)
Example: arm -> [hind-limb, forelimb, flipper, leg, crus, thigh, arm...] Holds btwn nouns/nouns and verbs/verbs
getAllDerivedTerms()
Returns derived terms forall senses of word/pos or null ifnot found Holds for adverbs Example: happily -> [jubilant, blithe, gay, mirthful, merry, happy]
getAllExamples()
Returns examples for all senses of word with pos if they contain the word, else null if not found
getAllGlosses()
Returns glosses for all senses of ‘word’ with ‘pos’, or null if not found
getAllHolonyms()
Returns part-to-whole relationships for all sense of word/pos, or none if not found X is a meronym of Y if Y has X as a part. X is a holonym of Y if X has Y as a part. That is, if Y is a meronym of X. Holds between: nouns and nouns Returns part, member, and substance holonyms Example: arm -> [body, physical-structure, man, human...]
getAllHypernyms()
Returns an ordered String[] of hypernym-synsets (each a semi-colon delimited String) up to the root of WordNet for the 1st sense of the word, or null if not found
getAllHyponyms()
Returns an unordered String[] of hyponym-synsets (each a colon-delimited String), or null if not found
References
62
getAllMeronyms()
Returns array of whole-to-part relationships for all senses of word/pos, or null if not found X is a meronym of Y if Y has X as a part. X is a holonym of Y if X has Y as a part. That is, if Y is a meronym of X. Holds between: Nouns and nouns Returns part,member, and substance meronyms Example: arm -> [wrist, carpus, wrist-joint, radiocarpal-joint...]
getAllNominalizations()
Returns nominalized terms for all sense of word/pos or null if not found Refers to the use of a verb or an adjective as a noun. Holds for nouns, verbs & adjecstives(?) Example: happiness(n) -> [happy, unhappy] happy(a) -> [happiness, felicity]
getAllSimilar()
Returns similar-to list for all sense of word/pos or null if not found Holds for adjectives Example: happy(a) -> [blessed, blissful, bright, golden, halcyon, prosperous...]
getAllSynonyms()
Returns an unordered String[] containing the synset, hyponyms, similars, alsoSees, and coordinate terms (checking each in order) for all senses of word with pos, or null if not found
getAllSynsets()
Returns String[] of words in each synset for all senses of word with pos, or null if not found
getAllVerbGroups()
Returns verb group for all senses of verb or null if not found Example: live -> [dwell, inhabit] Holds for verbs
getAlsoSees()
Returns also-see terms for 1st sense of word/pos or null if not found Holds for nouns (?) & adjectives Example: happy -> [cheerful, elated, euphoric, felicitous, joyful, joyous...]
getAnagrams() Returns up to maxResults full anagram matches for the specified word and pos
References
63
Example: ‘table’ returns ‘bleat’ (but not ‘tale’).
getAntonyms()
Returns String[] of Antonyms for the 1st sense of word with pos or null if not found Holds for adjectives only (?)
getAnyExample()
Return a random example from the set of examples from all senses of word with pos, assuming they contain word, or else null if not found
getBestPos()
Finds the most-common part-of-speech for the word, according to its polysemy count, returning the pos for the version of the word with the most different senses.
getCommonParent()
Returns common parent for words with unique ids id1, id2, or null if either word or no parent is found
getCommonParents()
Returns String[] of Common Parents for 1st senses of words with specified pos’ or null if not found
getContains()
Returns up to maxResults of the specified pos where each contains the given word
Example: ‘table’ returns ‘bleat’ (but not ‘tale’).
getCoordinates()
Returns coordinate terms for 1st sense of word/pos, or null if not found X is a coordinate term of Y if there exists a term Z which is the hypernym of both X and Y. Examples:
• blackbird and robin are coordinate terms (since they are both a kind of thrush)
• gun and bow are coordinate terms (since they are both varieties)
• fork and spoon are coordinate terms (since they are both cutlery, or eating utensils)
• hat and helmet are coordinate terms (since they are both a kind of headgear or headdress)
Example: arm -> [hind-limb, forelimb, flipper, leg, crus, thigh, arm...] Holds btwn nouns/nouns and verbs/verbs
getDerivedTerms() Returns derived terms for 1st sense of word/pos or null if not found
Returns description for word with pos or null if not found
getDistance()
Returns the min distance between any two senses for the 2 words in the WordNet tree (result normalized to 0-1) with specified pos, or 1.0 if either is not found
getEndsWith()
Returns up to maxResults of the specified pos ending with the given word.
Returns examples for word with unique senseId, or null if not found
getGloss()
Returns full gloss for !st sense of ‘word’ with ‘pos’ or null if not found
getHolonyms()
Returns part-to-whole relationships for 1st sense of word/pos, or none if not found X is a meronym of Y if Y has X as a part. X is a holonym of Y if X has Y as a part. That is, if Y is a meronym of X. Holds between: nouns and nouns Returns part, member, and substance holonyms Example: arm -> [body, physical-structure, man, human...]
getHypernyms()
Returns Hypernym String[] for all senses of word with pos or null if not found
X is a hyponym of Y if there exists an is-a relationship between X and Y. That is, if X is a subtype of Y. Or, for xample, if X is a species of the genus Y. X is a hypernym of Y is Y is a hyponym of X. Holds between: nouns and nouns & verbs and verbs Examples:
• artifact is a hyponym of object • object is a hypernym of artifact • carrot is a hyponym of herb
References
65
• herb is a hypernym of carrot
getHypernymTree()
Returns an ordered String[] of hypernym-synsets (each a semi-colon delimited String) up to the root of WordNet for the id, or null if not found
getHyponyms()
Returns Hyponym String[] for 1st sense of word with pos or null if not found
X is a hyponym of Y if there exists an is-a relationship between X and Y. That is, if X is a subtype of Y. Or, for xample, if X is a species of the genus Y. X is a hypernym of Y is Y is a hyponym of X. Holds between: nouns and nouns & verbs and verbs Examples:
• artifact is a hyponym of object • object is a hypernym of artifact • carrot is a hyponym of herb • herb is a hypernym of carrot
getHyponymTree()
Returns an unordered String[] of hyponym-synsets (each a colon-delimited String) representing all paths to leaves in the ontology (the full hyponym tree), or null if not found
getMeronyms()
Returns array of whole-to-part relationships for 1st sense of word/pos, or null if not found X is a meronym of Y if Y has X as a part. X is a holonym of Y if X has Y as a part. That is, if Y is a meronym of X. Holds between: Nouns and nouns Returns part,member, and substance meronyms Example: arm -> [wrist, carpus, wrist-joint, radiocarpal-joint...]
getNominalizations()
Returns nominalized terms for 1st sense of word/pos or null if not found Refers to the use of a verb or an adjective as a noun. Holds for nouns, verbs & adjecstives(?)
Returns an array of all parts-of-speech ordered according to their polysemy count, returning the pos with the most different senses in the first position, etc.
getRandomExample() Returns a random example from a random word w’ pos
getRandomExamples()
Returns numExamples random examples from random words w’ pos
getRandomWord()
Returns a random word with pos and a maximum of maxChars.
getRandomWords() Returns count random words w’ pos
getRegexMatch()
Returns up to maxResults of the specified pos matching the the given regular expression pattern.
getSenseCount()
Return the # of senses (polysemy) for a given word/pos. A ‘sense’ refers to a specific WordNet meaning and maps 1-1 to the concept of synsets. Each ‘sense’ of a word exists in a different synset.
For more info, see: {@link http://WordNet.princeton.edu/gloss}
getSenseIds()
Returns String[] of unique ids, one for each ‘sense’ of word with pos, or null if none are found.
A WordNet ‘sense’ refers to a specific WordNet meaning and maps 1-1 to the concept of synsets. Each ‘sense’ of a word exists in a different synset.
For more info, see: {@link http://WordNet.princeton.edu/gloss}
getSimilar()
Returns similar-to list for first sense of word/pos or null if not found Holds for adjectives Example: happy(a) -> [blessed, blissful, bright, golden, halcyon, prosperous...]
References
67
getSoundsLike()
Returns up to maxResults of the specified pos that match the soundex code of the given word.
getStartsWith()
Returns up to maxResults of the specified pos starting with the given word.
Example: ‘turn’ returns ‘turntable’
getStems() Returns an array of all stems, or null if not found
getSynonyms()
Returns an unordered String[] containing the synset, hyponyms, similars, alsoSees, and coordinate terms (checking each in order) for all senses of word with pos, or null if not found
getSynset()
Returns String[] of words in synset for first sense of word with pos, or null if not found.
getVerbGroup()
Returns verb group for 1st sense of verb or null if not found Example: live -> [dwell, inhabit] Holds for verbs
getWildcardMatch()
Returns up to maxResults of the specified pos matching a wildcard pattern, with * ‘*’ equals any number of characters, and ‘?’ equals any single character.
Returns true if ‘word’ exists with ‘pos’ and is equal (via String.equals()) to any of its stem forms, else false;
isVerb()
printHypernymTree()
Prints the full hypernym tree to System.out (primarily for debugging).
printHyponymTree() Prints the full hyponym tree to System.out (primarily for debugging).
References
69
References Adomavicius G., and Tuzhilin A., 2005. Toward the Next Generation of Recommender Systems: A Survey of the State-of-the-Art and Possible Extensions. In IEEE Transactions on Knowledge and Data Engineering, Vol. 17, No. 6, pp. 734-749. Atanassov, K., 1999. Intuitionistic Fuzzy Sets: Theory and Applications. Studies in Fuzziness and Soft Computing, 35, Physica-Verlag. Baldi P., Frasconi P. and Smyth P., 2003. Commerce on the Web: Models and Applications. Modeling the Internet and the Web, Probabilistic Methods and Algorithms, John Wiley & Sons Ltd., West Sussex, England, pp. 211-234. Bedi P. and Kaur H., 2006. Trust based Personalized Recommender System. In INFOCOM Journal of Computer Science, Vol. 5, N.1, pp. 19-26. Bonhard P., 2004. Improving Recommender Systems with Social Networking. In the Proceedings Addendum of the 2004 ACM Conference on Computer-Supported Cooperative Work. Chicago, IL, USA. Breese J., Heckerman D. and Kadie C., 1998. Empirical Analysis of Predictive Algorithms for Collaborative Filtering. In the Proceedings of Fourth Annual Conference on Uncertainty in Artificial Intelligence, Morgan Kaufmann, Madison, WI, USA, pp. 43-52.
Burke R., 2002. Hybrid Recommender Systems: Survey and Experiments. User Modeling and User-Adapted Interaction, Vol. 12, pp. 331-370. Herlocker J.L., Konstan J.A., Terveen L.G. and Riedl J., 2004. Evaluating Collaborative Filtering Recommendations. In ACM Transactions on Information Systems, Vol. 22, No. 1, pp. 5-53. Huang Z., Chen H. and Zeng D., 2004a. Applying Associative Retrieval Techniques to Alleviate the Sparsity Problem in Collaborative Filtering. In the ACM Transactions on Information Systems, Vol. 22, No. 1, pp. 116-142. Li Q. and Kim B.M., 2003. Clustering Approach for Hybrid Recommender System. In the Proceedings of the IEEE/WIE International Conference on Web Intelligence (WI’03). Resnick P. and Varian H.R., 1997. Recommender Systems. In the Communications of the ACM, Vol. 40, Vol. 3, pp. 56-58.
References
70
Sarwar B., Karypis G., Konstan J. and Riedl J., 2000b. Analysis of Recommender Algorithms for E-Commerce. In the Proceedings of Electronic Commerce, Minneapolis, Minnesota, USA, pp. 158-167.
Sarwar B., Karypis G., Konstan J., and Riedl J., 2001. Item-Based Collaborative Filtering Recommendation Algorithms. In the Proceedings of World Wide Web, Hong Kong, pp. 285-295 Schafer J.B., Konstan J. and Riedl J., 1999. Recommender Systems in E-Commerce. In the Proceedings of First ACM Conference on Electronic Commerce, Denver, USA. Schafer J.B., Konstan J. and Riedl J., 2002. Meta-Recommender Systems: User-controlled Integration of Diverse Recommendations. In the Proceedings of Conference on Information and Knowledge Management (CIKM ’02), McLean, Virginia, USA, pp. 43-51. Semeraro G., Lops P. and Dedemmis M., 2005. WordNet-based User Profiles for Neighborhood Formation in Hybrid Recommender Systems. In the Proceedings of the 5th International Conference on Hybrid Intelligent Systems (HIS '05). Shardanand U., and Maes P., 1995. Social information filtering: Algorithms for Automating “Word of Mouth”. In the Proceedings of the ACM CHI’95 Conference on Human Factors in Computing Systems, Denver, CO, pp. 210-217. Sinha R. and Swearingen K., 2001. Comparing Recommendation made by Online Systems and Friends. In the Proceedings of the DELOS-NSF Workshop on Personalization and Recommender Systems in Digital Libraries, Ireland.
Ungar L.H. and Foster D.P., 1998. Clustering Methods for Collaborative Filtering. In the Proceedings of the Workshop on Recommender Systems, AAAI Press.