There are several applications where people collectively contribute to a central database (i.e. a cooperative database). A few examples:
  • in the University of Orsay, each assignment is composed of 3 problems from the database of solved problems, and of one new solved problem, approved by the professors teaching the course. This proved to be saving time and to improve the quality of assignment texts.
  • Here in Ontario, the CLOE ( program aims at organizing the constitution of databases of "online teaching materials" in each university, and the exchange of items between university (with vague rules).
  • Wiki pages such as form a valuable base of knowledge, and has been contributed from all over the world.

Those cooperative databases are based on a centralized control, which does not scale well with the size of the database, and have no mechanism to push people using the database to contribute as well. In the similar context of Peer to Peer networks, "reputation systems" are used to control the quality of the submission to the database, and "Friend lists" are used to form incentive to contribute. But those mechanism do not seem to adapt well to the context of cooperative Databases.

We want to consider the problem of how to ensure the growth of a cooperative database (not counting void and duplicated items), in several distinct contexts, corresponding to different constraints or ability concerning the centralisation of the protocol. For instance, the protocol used in Orsay require a centralized control: it might be adequate for applications where such a centralized control is necessary anyway (e.g. for medical procedures or sensitive items), but is not adequate for a database of solved problems exchanged between all universities of North America because it does not scale well.

We started to model the problem in the most simple way we could thing of, agreeing that more complex models (taking into account the quality of each item) will have to wait. The utility function for each agent i would be formed of:

  • his cost c_i, equal to 0 if he submits a void or duplicated item, and 1 otherwise;
  • his gain g_i, equal to 0 if he downloads a void or duplicated item, and 1 otherwise.

One objective could be that the protocol maximizes the "social farewell", another one could be that the protocol maximizes the growth of the database (as a ratio to the number of people using it).

While the protocol stands to organize "exchanges" of digital items, considering a Credit system permits to reduce the problem to known protocols such as Vickrey auctions: it is not clear if we are losing something by taking this approach or not. As only the author of the item can "duplicate" it, there might be a relation with Jason Hartline work (and others) on Competitive Auction (which concerns how to fix the broadcast price of digital content).

-- JeremyBarbay - 30 Nov 2004

Topic revision: r1 - 2004-11-30 - JeremyBarbay
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback