Customization

The customization of Barbante to meet the specific needs of a certain client is done via two configuration files:

• barbante/config/mongoid.yml
• barbante/config/barbante_<client_name>.yml

In the barbante/config/mongoid.yml given here as an example, we have added entries for two client systems, good old "foo" and "bar". The examples in the file are quite self-explanatory, but one thing is vital: the value assigned to the "customer" attribute should be the same as <client_name>.

For instance, in the given mongoid.yml, we have

foo:
  customer: Foo
  sessions:
    default:
      database: db_foo
      hosts:
        - host_foo.mydomain.com:27017
      database_raw: db_foo_raw
      hosts_raw:
        - host_foo_raw.mydomain.com:27017
      options:
        read: primary
        max_retries: 1
        retry_interval: 0
        pool_size: 35
  options:
    raise_not_found_error: False

The client system should therefore use the alias "foo" to identify itself when making REST requests, and the configuration file that will be used by Barbante to provide recommendations for that specific client will be barbante/config/barbante_Foo.yml.

The file barbante_Foo.yml that is provided has a number of parameters that can be fine-tuned to attain better recomendations. Each one of them is very briefly explained in the file itself. The default values that are given should work out fine, anyway, for the great majority of cases.

However, there are three sections in said file that must be customized:

• the ACTIVITIES section, where each user activity that gets tracked by the client is assigned a number of stars (in the usual 5-star rating system), among some other minor configurations;
• the PRODUCT_MODEL section, where each attribute of the product is classified (as text, numeric, list etc.) and assigned a weight with respect to content-based similarity; and
• the ALGORITHM_WEIGHTS section, where each recommender algorithm is assigned a weight, i.e., a measure of its importance in the overall ranking of products.

It should be fairly simple to do that based on the existing examples. We remark that the 5-star rating correspondence assigned to each activity is used to obtain "implicit" user-to-product ratings in systems which do not explicitly obtain such ratings. Note that, in the case of client systems which do collect explicit ratings, such ratings can be tracked as normal activities all the same, e.g., activity "rate-5-stars" corresponding to a rating of 5, "rate-4-stars" corresponding to a rating of 4, etc.