Introducing virtual money to a recommender service

Working paper by Roland Alton-Scheidl (ras@pvl.at), PUBLIC VOICE Lab
Version 0.9, 20 APR 2000

Summary: On top of the framework of the SELECT rating service we specify a recommendation service, for which users get incentives when being active. Application areas are manyfold: rating of web documents, messages in forums or in newsgroups or documents in databases. The general objective is with ratings to enhance the orientation within the service and to democratize the agenda setting process. We see the necessity that recommendation services shall be designed in a way that recommenders are honoured for giving away recommendations. The incentive shall be a benefit beyond the common value of collaborative filtering per se, in order to motivate users to rate documents.

Rating & Filtering using the SELECT architecture

Within the SELECT project, a European R&D consortium implements a basic and advanced SELECT service architecture. A basic SELECT server does the following An advanced SELECT server will additionally Technically, XML based protocols allow clients to connect to a SELECT server in order to submit ratings, query documents, sort documents by a given rating criteria or in order to manage a user's account and profile. A SELECT client may be thin (pure HTML commands, a Java Applet) or a more complex application like a fat proxy client, a browser¹s plug-in, a groupware server or a Search Engine. If the client is a multi-user service and already may handle user accounts (and offers unique user IDs) or is able to store user profiles, then user administration should be handled on the client side, in order to have as less personal and private data on a SELECT server as possible. We have prepared a functional category for the user interface, to handle rewards for users, whose documents have been rated highly. This is not standard functionality as it is up to the implementors of a client to calculate and distribute rewards. One possible usage of a reward scheme in a client could be that a user is not allowed to benefit from rated documents in his/her own filtering and searching, unless this user also provides ratings and gives away rewards to other users. Weighting will be used as well in the filtering module. This has not been implemented yet, and the final design of this feature is not ready, when this plan is written. This document focusses on the specification of a multi user and multi sourced ratings database service. However, it can be also used for a single user's collection of ratings. We are using the XML, rather than the PICS, syntax, but the functionality is a superset of the PICS functionality and can easily be mapped on the PICS syntax if needed.

The project results are the following: We have a server platform, open protocols to be submitted to IETF standardisation bodies, a set of client technologies, which we offer open source and a number of applications, where rating functionalities will be integrated and demonstrated at user sites. For a wide deployment of the service, we have developed a proxy (to be used on the local PC, near a firewall or at an ISP) , which injects rating values into any web page, for which we have stored rating values.

A new concept for a recommender service

Typically, recommender services use ratings from users, compare them and make recommendations.

The challenge for a recommender service is the conceptual design: the recommendation service must be simple enough to be understood immediately, but also needs rules that resolve conflict situations, cold-start problems, cheating and emerging teams. And it must be fun and/or useful, so that users give away ratings.

Our basic idea is that rating activities and good quality contributions for the community shall be honoured. Both objects and users are rated, if the author is a registered user.

We could invent stars, flowers, dices, scores to be given to users. If our service wants to be successful and commercially viable, we need to look at success stories and derive ideas from them.

Incentive money for portals

Virtual money is a reality in the Internet. For example, beenz are widely used to offer an incentive e.g. to register at a web service; the service provider of the portal is charged and the e-worker can buy real goods.

www.beenz.com skyrocketed to 700.000 members within 10 months and exchanged a value of some estimated 10.000.000 $.
The business model is simple: Web Sites who want to give an incentive to their visitor offer beenz. A store may offer payment in beenz currency and is refunded from beenz.com. The overall commission is 50%. "For every beenz you pay to your e-worker consumers, we charge you one cent. That's it: no hidden charges, set-up fees or integration charges. Pay as you go." Beenz cannot be transferred between users. "On-line stores can accept payments in beenz just like any other currency. We pay businesses half of one cent (US) for every beenz spent by a consumer on their Web site, and provide the software to carry out the transactions."

Incentive money on any object

How can we extend the simple bussiness model of beenz for giving incentives to rating pages or messages from individual persons? The challenge is to give the community a tool, that measures both value, offers some benefit when working with it and can be exchanged between members of the rating community.

One approach is to say: it is the user, who wants to have attraction on his/her contribution. We ask the user to pay some little cash (or gives previously collected beenz or another commodity) to the rating service provider. This will make the user's objects more attractive: who ever rates his/her contribution, will get an incentive. If the user behaves "well" in the community and offers value to it, the amount in the user's wallet increases, if objects are ranked poorly the budget runs out. Like a stock exchange business, where you have to invest something and depend on the performance of your papers. Well, not exactly, but somehow ;-) In order to keep the entry barrier low, users may be offered to rate sets of objects without having donated anything to the community.

The econometrics of the model, which I would like to call "TALENZ", takes ideas from alternative monetarian systems, which have been used in the 1930s, such as the Talent system. We try to implement two major differences from the regular monetarian system, as suggested by Bernard A. Lietaer in his paper A "Green" Convertible Currency: we will use a negative interest rate and backing up by commodities.

Here is a verbal decription of the transaction rules. It sounds more complicated than it will look like on a web page. Imagine an animated gif with rating stars, which fade away and say "Rate me and get Talenz". You click on it, do the rating, and receive your first talenz. Anytime you use your rating account you can see how many talenz you have.

Here we describe the mathematical model in commented pseudo-code notation:

We define the following elements:

P
Pool account (the service provider's total of all commodities in circulation, which is to control whether the talenz system is still backed up with commodities)
Ui
Account (wallet) of User i
Uini
Initial value which a user gets at registration
Int
Interest rate per week
Cj
Value of commodity j (for converting talenz into something real)
Vk
Value to get incentive on object k (how much I get for rating k, may be equal for all objects)
Vini
Default initial value for rating an object
Ua(k)
Author of object k
F
Fee invoiced to a partner
Fcom
commission rate, charged to partner, who wants to have preferred ratings 
Initialisation of process:
I = -0,01   // interest rate is 1% per week
Fcom = 0,01 // one cent Euro per talenz
P = 0
Uini = 10

Backing up pool with initial commodities, which come from partners, and assign a value for each of it
P = … Ck
Vk = Vini

User registers (explicitly or implicitly when doing his/her first rating)
Ui = Uini

User i rates object k
The rating itself is done outside the incentive system using the SELECT service, 
which will ensure that only one rating per object is allowed.

Ui += Vk    // rater gets incentive
Ua(k) += Vk // author gets incentive (only if author is registered at incentive service)
P -= 2*Vk   // values are taken from pool

User i converts collected values into commodity j
Ui -= Cj

A partner offers n commodities j 
(e.g. 100 free subscriptions á 10 Talenz, 50 CDs á 40 Talenz, 1000 Euro á 100 Talenz, 20 access rights to create a voting form)
P += n*Cj

Weekly interest rate for all users i
Ui -= Ui * Int

Preferred rating status: Optionally, we can assign to selected objects a higher value than Vini, 
if being rated. This is good for marketing the incentive service (... rate our content and get y!).
The partner who wants to offer more value when rating their content has to pay a commission fee F to
the service provider of the incentive system.
Vk = y
F = (y - Vini) * Fcom

Requirements for an Experiment

The SELECT infrastructure will be used to do experiments with virtual money as described here. Additionally, we need a wallet for each user as well as a pool and some functions that fulfill the transactions rules. An open issue is, whether we will need full transaction handling or if transaction logs are sufficient.

We are currently looking for demonstration partners, who would like to integrate a rating service into their content tree and partners who offer commodities.

References

SELECT project homepage (under construction): http://about.rated.it