Wikimedia Commons

From Meta, a Wikimedia project coordination wiki
This is an archived version of this page, as edited by Eloquence (talk | contribs) at 06:11, 4 May 2004 (detailed proposal). It may differ significantly from the current version.
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

The goal of the Wikimedia Commons project is to provide a central repository for free images, music and, possibly, texts, to be used by all Wikimedia projects. The Commons was originally proposed by Erik Möller on March 19 [1]. This is a more elaborate description of the project and its goals based on that proposal and subsequent discussion.

Rationale

Presently each of the many Wikimedia projects -- every single Wikipedia and Wiktionary, as well as Wikibooks, Wikisource and Wikiquote -- has a separate directory for file uploads. There is no reliable way to reference images on other projects. Many good, free uploads on one wiki may go unnoticed on another. Thus, there is needless duplication of intellectual and creative work as well as unnecessary redundancy and increased maintenance.

Other advantages:

  • Central place to resolve licensing issues
  • Less time wasted on locating relevant files
  • A place for things like image galleries that go beyond the needs of a single article (e.g. 10 different pictures of the same airplane)
  • We can actively solicit contributions specifically to the commons from people who are not interested in contributing on a regular basis
  • We can provide the largest such respoitory of freely licensed material, with a quality control mechanism that other such projects lack (the community)
  • We further establish our name beyond being merely the largest, greatest encyclopedia ever
  • We benefit from the positive connotations of the term "commons" and appeal more directly to altruism, which will be beneficial when we ask for donations
  • We create a very real consciousness for the copyleft idea which so far is missing especially for images, where many people simply upload whatever they find on the net.
  • We can use this platform to become more politically relevant in the ongoing discourses about copyright law.

Proposal

A central repository is to be created at commons.wikimedia.org. It would hold:

  • images
  • music, artistic works
  • documents

All material in the commons would have to be licensed under one of several licenses, not necessarily the FDL, but all allowing at the very least free distribution and commercial use. For texts, modification rights would also be a requirement. There would be NO fair use material on commons.wikimedia.org.

As documents are currently maintained by Wikisource, this part of the proposal will have to be debated further as soon as the commons goes live.

Criteria for inclusion

Material would be eligible for inclusion in the Commons if it is useful to at least one Wikimedia project. This includes plausible future usefulness.

The Commons Community would define further criteria for inclusion, for example, if a band is notable enough to have an article in Wikipedia, and their MP3s are freely licensed, they can be deposited; if a file is highly referenced from the outside and causes unbearable bandwith costs, it can be removed. The larger and more popular a file, the more pressing needs to be its rationale for inclusion.

Implementation

The proposal requires some changes to MediaWiki, although a working version could already be set up with a relatively small amount of new code.

Upload process

The MediaWiki upload form would be completely redesigned. Look at these two mock-ups:

The first selection is whether a file should be uploaded to the commons or to the local wiki (in the mock-up, the English Wikipedia). The commons would always be the default, but the local wiki could be used for things which are useful only to one wiki, or which are not allowed under the terms of the commons. For example, the English Wikipedia allows limited fair use. This option is, however, not available on the Wikimedia Commons upload form.

The second question is whether the user is the creator of the file. If they are, we narrow down the set of allowed licenses to the ones which we prefer, and the user only needs to type a description and is ready to go. We want to make things as easy as possible for original creators. There are a few more questions, however, if the user is not the copyright holder. In this case, they also need to provide source information for the image.

Note that in these mock-ups, depending on the answer to the "Are you the original creator?" question, the other part of the form is grayed out and not editable. This should make it relatively intuitive.

The commons wiki

The commons wiki itself should of course be multilingual as Project Sourceberg and Meta are. New uploads would show up both in the upload log of the wiki from which they were uploaded, and in the commons upload log. Without a single sign-on, such uploads would be logged as "Username@wiki", e.g. "Eloquence@En-Wikipedia".

There would have to be a real commons community, which would take a look at uploaded files, provide translations of image descriptions, sort media files into galleries, translate and annotate source documents, and so forth. They would also be responsible for enforcing the standards of inclusion.

Usage

Usage of material from the commons needs to be largely transparent to the end user. In effect, when a user types

[[Image:Mona Lisa.jpg]]

that request would go first to the local wiki and then, if no local copy exists, to the commons.

The image description page would transparently be imported from the commons everytime it is viewed, until it is edited, at which point a local copy would be created.

Necessary MediaWiki changes

These are some features which we should enter into the MediaWiki roadmap if we want to implement this proposal:

  • Provide an interface to a shared media file directory, and to the commons wiki database (to update the commons upload log, create image pages etc.)
  • Redesign upload form and resulting description pages, allow uploading either to the commons or to the local wiki
  • Transparently import pages when viewing commons image pages, permanently import them when editing them

Desirable MediaWiki changes

These changes are not crucial to make the Commons work, but are desirable in the long term:

  • Rename the Image: namespace to File: and revamp "image" pages to be more intuitive (allow playback of media files, for example)
  • User interface languages can be set in the preferences (important for any single wiki that allows multiple languages)
  • Better interlanguage handling in a single wiki installation
  • Friendly user interfaces for multi file uploading
  • Selectable categories for images?
  • Automatic gallery generation for multiple images
  • Transclusion of text from the commons (smart caching!), including individual sections

Commons as basis for single sign-on?

Since the commons proposal requires a shared database (it would be possible to access it via HTTP, but since the Wikimedia setup allows for a shared DB, that would seem unnecessary) it would only be logical to use the commons as the basis for single sign-on.

The implementation would be as follows:

  • A field user_created is added to the user table. For existing accounts, this field is filled with the date of the first contribution of the user (alternatively, the date of the creation of their user page). If neither exists, the date is set to "today".
  • A new table usermatch is created in the database of each wiki with the fields "local_id" and "commons_id".
  • Two tables are created in the commons database: user and user_old.
  • The first user_id in the commons user table must be higher than the total number of users of all projects (to avoid attribution problems)
  • All unique existing accounts are loaded into the commons user table. An account is unique if it exists only with the same password across all wikis.
  • All other existing accounts are loaded into the user_old table, which may includes duplicat rows.
  • On the creation of a new account that does not exist in the user table, the system system checks whether the account exists in user_old. If so, it prints the name of the oldest account (e.g. "Eloquence, English Wikipedia: 2002-xx") and asks the user for the password to that account.
  • If the password is entered correctly, the user now owns that account in the commons database.
  • The user can "hook up" additional old accounts by entering the account password. This would be done through the user preferences.
  • The edits associated with hooked up accounts would be reattributed using the usermatch tables of the respective wikis. In cases where the usernames are different, a developer would have to push a button -- such cases require changing the user_text in the CUR and OLD table of the respective wiki, which can be quite a big operation.

In the long term, we should of course get rid of the usermatch table and also the user_old table, if possible. Hopefully there will only be relatively few duplicates that do not belong to the same users.

This approach has one key advantage, it quite securely prevents account hijacking. For most users the transition would be completely transparent. The most painful cases are those where a user is forced to change their name because it is already taken by an older user. They are painful largely because of our database layout.

From a technical perspective, the implementation is not so difficult. The filling up of the required tables and fields might take some time, but could be done on a slave database. Using the shared database for logging in is trivial, a universal cookie might be a bit more difficult across different domain names.

Who wants to help?

If you want to help with the implementation of the Wikimedia Commons, please list your name below and describe what you want to do:

  • Eloquence
    • Coordination and coding. If nobody else does anything, I'll at least implement the basic requirements.