Introducing virtual money to a recommender service
Working paper by Roland Alton-Scheidl (firstname.lastname@example.org), 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
- store incoming ratings
- output sets of rated documents (with or without full document content) when queried according to given rules
- list preconfigured rating categories
- evaluate a list of URIs and return the aggregate ratings on them
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.
- register users and manage their profiles
- manage user groups
- allow to register a rating category
- allow to exchange rating data between networked servers
- allow other software modules to plug-in
- support agent-based collabortive filtering
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:
- Usually a users starts a talenz wallet when s/he rates an object, which promises talenz when rating it.
- Any object may promise a certain amount of talenz, when being rated.
- Users shall get at registration some initial talenz.
- Providers of portals, subject trees, search engines or any user are service partners and may donate any amount of real money or any convertible virtual money or any commodity, to which a talenz-value will be assigned, to the talenz pool.
- If an object is rated good or superior, the author gets a certain amount of talenz from the talenz pool, as long as there are talenz in the pool.
- Users' wallets loose some talenz each week (negative interest rate) for storage and user account management to the talenz pool.
- A user may convert his/her talenz again back to virtual money or commodities (free CD, book, etc).
- In order to avoid rating-spams we will need some more rules that restrict the maximum number of maximum given or received ratings.
- The service continuosly shows
- the total talenz in the pool
- how many talenz one must have so that own documents are incenticed
- the top ranking of users by talents, which is an indicator that they either have rated many documents or are authors of high quality documents
- which commodities are available and how much talenz have to be paid
We define the following elements:
- 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)
- Account (wallet) of User i
- Initial value which a user gets at registration
- Interest rate per week
- Value of commodity j (for converting talenz into something real)
- Value to get incentive on object k (how much I get for rating k, may be equal for all objects)
- Default initial value for rating an object
- Author of object k
- Fee invoiced to a partner
- 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.
SELECT project homepage (under construction): http://about.rated.it
- Bernard A. Lietaer:Internet Currencies for Virtual Communities
- Bernard A. Lietaer:A "Green" Convertible Currency
- SELECT Draft Protocol Specifications Report
- SELECT Draft Module Specifications Report
- SELECT Interface Draft Functional Specification
- SELECT User Requirements Report
- SELECT Technical Documentation & User Manual of Base System
- SELECT Working paper by Rob Procter, Dave Mason, Duncan Pemberton and Tom Rodden: "Some Issues for Collaborative Filtering Through Shared Bookmarks", Draft Version 28 MAR 00.
- SELECT Preliminary Exploitation Report by Roland Alton-Scheidl and Jacob Palme.