FirstReport < Main

Main Web>TWikiUsers>JeremyBarbay>DigitalCooperatives>FirstReport (2004-11-30, JeremyBarbay) (raw view)

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 (http://cloe.on.ca/) 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 www.wikipedia.org 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).

-- Main.JeremyBarbay - 30 Nov 2004

Topic revision: r1 - 2004-11-30 - JeremyBarbay

Main

TWiki Webs
CSEveryBody
- AIMAS
- CERAS
- CF
- CrySP
- External
- Faqtest
- HCI
- Himrod
- ISG
- Main
- Multicore
- Sandbox
- TWiki
- TestNewSandbox
- TestWebS
- UW

My links
- People
- CERAS
- WatForm
- Tetherless lab
- Ubuntu HowTo
- eDocs
- RGG NE notes
- RGG
- CS infrastructure
- Grad images

Edit