Topic on Talk:Files and licenses concept

Currently the concept is to store the following per set in mw_file_props:

mw_file_props contains:
	fp_id		INT (mw_revision.rev_fileprops_id is a key to this column)
	fp_key		VARBINARY(255)
	fp_value_int	INT
	fp_value_text	VARBINARY(255)

EXAMPLE

fp_id	fp_key	fp_value_int	fp_value_text
1	author	50 (mw_user.user_id of User:Krinkle)	NULL if empty the username is used
1	author	43 (mw_user.user_id of User:Catrope)	Roan wiki user who wants display name different from username
1	author	NULL	John Doe
1	license	2 (mw_license.lic_id of CC-BY-SA-3.0)
1	license	5 (mw_license.lic_id of GFDL)

This file has three authors: Krinkle, Catrope (attributed as Roan) and John Doe (not a wiki user). And is dual licensed.

---

What we totally forgot in this structure is attribution and url. So instead of adding a useless extra column like fp_string2 and fp_string3, it's best to move this away to a mw_author table.

mw_file_props contains:
	fp_id		INT (mw_revision.rev_fileprops_id is a key to this column)
	fp_key		VARBINARY(255)
	fp_value_int	INT

mw_author contains:
	author_id		PRIMARY AUTO INCREMENT
	author_user		INT (mw_user.user_id is a key to this column - it's NULL if author is not a wiki user) [1]
	author_name		VARBINARY(255) (if author is wiki user this is NULL, we get username from user table 
				(saves space and saves changes when username would change) [1]
	author_attribution	VARBINARY(255) (if author is wiki user this may be NULL (in which case attribution falls
				back to 'user_real_name' or 'user_name';
				but it may be filled in if users want a custom attribution eg. "Team X / Krinkle")
				either way this is the field that licenses will cite when requiring attribution
				(eg. photographer could hand rights to museum author is John Doe, attribution is Museum X) [1]
	author_url		VARBINARY(255) [2]

UNIQUE(author_name, author_attribution, author_url)

[1]: Front-end requires an author to be given. atrribution and url are optional. When saving MediaWiki checks if author is a wiki username. If so, it uses it's id as author_user, and NULL for author_name, otherwise it saves the string as author_name and NULL in author_name

[2]: url is optional, but if account is wiki user and no value is here it fallsback to userpage.

EXAMPLE

author_id	author_user	author_name	author_attribution	author_url
12	50 (mw_user.user_id of User:Krinkle)	NULL	NULL	NULL
14	43 (mw_user.user_id of User:Catrope)	NULL	Roan wiki user who wants attribution different from username	NULL
16	NULL	John Doe	Foobar Museum	http://museumfoobar.org/

fp_id	fp_key	fp_value_int
1	author	12 (reference to row in mw_author)
1	author	14 (reference to row in mw_author)
1	author	16 (reference to row in mw_author)
1	license	2 (mw_license.lic_id of CC-BY-SA-3.0)
1	license	5 (mw_license.lic_id of GFDL)

This file has three authors: Krinkle, Catrope (attributed as Roan) and John Doe (not a wiki user, hire by museum, hands over rights). And is dual licensed.

Roan didn't see anything bad in it, and the idea came from Bryan. If by tomorrow we dont see anything wrong with this I'd say... let's write it!

Ok with me, but it does mean creating an AuthorManager and the way to link user input on the file props edit form with the database becomes even less trivial. I don't see another option though, so let's do it this way.

An AuthorManager would imho be a feature request for later. For now the author-data is stored in the mw_author table so that we don't duplicate information and have an effecient way to get lists by one or more authors or licenses (since file_props only stores integers to mw_license or mw_author).

And this enables a future ability to edit an author once and have it reflect on all it's files. However I dont think an AuthorManager is required for the first working-proof-of-concept (there's no "user manager" either, although there is RenameUser..) - this AuthorManager would probably be an admin-only function (ie. to merge, or update authors in case something needs to be updated). but not something every uploader could do. (what are the usecases ? 'm open to new insights)