The Profile Model concept was already described here . Profile models are used by predictors to collect data that they need as input for calculating predictions. Profile models can be updated by feedback processors when users provide feedback.
The Duine Toolkit currently comes with 4 profile models. They are described below. Each profile model follows the same design pattern:
The Duine Toolkit is designed to facilitate extension with other profile models.
The RatingModel provides access to and storage of the ratings by users. See the javadocs for further details about the RatingModel.
An interest model is a profile model that represents the interests of users. To avoid having to create a new profile model implementation for each kind of interest model the Duine Toolkit provides a generic component (InterestModel) for the realization of interest models. This model can be used if interests can be expressed as strings.
The Interest class describes one interest of a single user. An interest is expressed as a single keyword of type String: the subject of interest (e.g. swimming, cycling). Furthermore, an interest can be quantified by a weight and a certainty.
Applications only have to specify and configure the interest model(s) in the configuration. An interest model has a modelId attribute to make it distinct from other interest models.
This is shown in the following example. The informationFiltering predictor uses the infoFilterInterestModel to retrieve the interests of the user related to information filtering. This infoFilterInterestModel is implemented using the generic InterestModel class. The mainGenreInterestModel uses another instance of the same InterestModel class. This model is used by the mainGenreLMS predictor.
<bean id="informationFiltering" class="org.duineframework.recommender.predictor.InformationFiltering">
<description>Uses term weight maps for its predictions.</description>
<property name="name" value="informationFiltering"/>
<property name="interestModel" ref="infoFilterInterestModel"/>
.....
</bean>
<bean id="infoFilterInterestModel" class="org.duineframework.recommender.profile.interest.InterestModel">
<property name="modelId" value="org.duineframework.recommender.profile.interest.infoFilterInterestModel"/>
....
</bean>
<bean id="mainGenreLMS" class="org.duineframework.recommender.predictor.InterestLMS" >
<description>Uses main genres for its predictions.</description>
<property name="name" value="mainGenreLMS"/>
<property name="interestModel" ref="mainGenreInterestModel"/>
....
</bean>
<bean id="mainGenreInterestModel" class="org.duineframework.recommender.profile.interest.InterestModel" >
<property name="modelId" value="org.duineframework.recommender.profile.interest.mainGenreInterestModel"/>
....
</bean>
The UserSimilarityModel represents the similarity between users and has interfaces to access these similarities. It can be accessed through the IUserSimilarityModel interface. The Duine Framework offers 2 implementations of this interface, the UserSimilarityModel and the UserSimilarityModelOnTheFly .
The UserSimilarityModel implementation assumes that a database is available where the pre-calculated similarities are stored. Duine has a tool, the UserSimilarityBuilder that can be used to calculate similarities and store them in this database. In a typical usage scenario you could execute this tool in an external process on a regular basis, for example every 24 hours.
The UserSimilarityModelOnTheFly implementation calculates the requested similarity every time it receives a request.
Note that the current implementations for similarity calculations do not scale very well for larger numbers of users. We hope to address this issue in future releases (see the the roadmap ).
The ItemSimilarityModel represents the similarity between items and has interfaces to access these similarities. It can be accessed through the IItemSimilarityModel interface. The Duine Framework offers 2 implementations of this interface, the ItemSimilarityModel and the ItemSimilarityModelOnTheFly .
The ItemSimilarityModel implementation assumes that a database is available where the pre-calculated similarities are stored. Duine has a tool, the ItemSimilarityBuilder that can be used to calculate similarities and store them in this database. In a typical usage scenario you could execute this tool in an external process on a regular basis, for example every 24 hours.
The ItemSimilarityModelOnTheFly implementation calculates the requested similarity every time it receives a request.
Note that the current implementations for similarity calculations do not scale very well for larger numbers of items. We hope to address this issue in future releases (see the the roadmap ).
