As per http://blog.musicbrainz.org/?p=1301 :

I'm not aware of any objections to storing additional information about aliases. MBS-1485 in particular has a lot of votes.

My proposal is:

Aliases (for artists, labels and works) should have the following attributes:

• type
• sort name
• begin/end date
• a "primary" flag

The default list of types would be:
Artists:

• Artist name
• Legal name
• Search hint

Labels:

• Label name
• Search hint

Works:

• Work name
• Search hint

These attributes should be settable from the add alias page (/ENTITY/MBID/add-alias) and the edit alias page (/ENTITY/MBID/alias/ID/edit).
They should be shown on the aliases tab (/ENTITY/MBID/aliases).
They should be shown in add alias and edit alias edits when the attributes are being added/edited.
They should be shown in remove alias edits.
They should be returned in any relevant WS queries (whenever aliases are returned).

The primary flag is intended to replace the current limitation on having only one alias with a particular locale. This means:

• We should be able to use locales multiple times for an artist.
• Only only alias for a locale should be allowed to be set as primary alias for that locale.
• During the upgrade, we should set the primary flag for all aliases with a locale.

Search hints should not have dates, sort names, locales or the primary flag.

Notes:

1. It was suggested by one person to allow grouping aliases. I do think it's a good idea, but I'm having trouble imagining how it would be implemented. Therefore I've opted to continue with a simpler proposal that will still let us store a lot more information.

2. Additional types can be proposed on the style list.

3. I'm not particularly attached to type names or "primary" as the name of the flag, so if anyone has any better ideas, feel free to suggest them.

4. "Legal name" is not intended to replace the performance name relationship (although people are welcome to discuss it on the style list). It's mainly intended for cases where we wouldn't normally add a separate artist.

Also, some discussion from a while back:
http://musicbrainz.1054305.n4.nabble.com/RFC-Is-became-transitioned-to-relationship-td4036726.html

This ticket is under consideration for the May 15h schema change release. Please do the following:

• Specify exactly what the user interface changes will be. Mock ups would be great. Due date: April 2
• Specify exactly what the database changes will be. We will need to have an exact database table change proposal. Exactly which columns will be added/removed/modified and what new tables will be created. If you cannot specify the changes to be done, chase down a developer to specify them for you. Due date: March 26

Database changes:

artist_alias, label_alias and work_alias should have the following extra columns:

• type (link to artist/label/work_alias_type)
• sort name (link to artist/label/work_name)
• begin/end dates (as implemented everywhere else in the database)
• a "primary" flag (boolean)

new tables: artist_alias_type, label_alias_type, work_alias_type with columns "id" and "name" (default values already defined above)

also change constraints according to restrictions listed above.

Interface changes: Update all the places already listed above, copy the display of existing attributes.

I disagree with storing Legal name as an alias since:

• it's going against current practice/guidelines to not store legal name with performance name (http://wiki.musicbrainz.org/Artist_Alias - When not to use aliases)
• it'll be the cause of inconsistency (sometimes you'll find Legal Name here as an alias, sometimes you'll have to search for a "performs as" relationship) or of redundancy if information is stored both as an alias and with a relationship

Fine. Whatever. Take that out. I (and other people I know) will continue to not be able to enter people's full/real names without creating almost identically named artists (creating more work to watch the artist and make sure people don't use it) and duplicating all the begin/end dates, type, gender, country and all the URLs (so much for avoiding redundancy).

The guidelines do not say that legal names must always be separate artists. See http://wiki.musicbrainz.org/Style/Artist/With_multiple_names#Does_it_always_make_sense_to_create_distinct_entries.3F which has been official for years.

Well, final decision doesn't have to follow my opinion, but at least:
1. You're now aware of some objections
2. We now have a rationale for Legal Name

Alright! Here's me sketching something out for artist aliases:

CREATE TABLE artist_alias_type (
    id SERIAL NOT NULL PRIMARY KEY,
    name TEXT NOT NULL
);

ALTER TABLE artist_alias ADD COLUMN type INTEGER;
ALTER TABLE artist_alias ADD COLUMN sort_name INTEGER NOT NULL;
ALTER TABLE artist_alias ADD COLUMN begin_date_year SMALLINT;
ALTER TABLE artist_alias ADD COLUMN begin_date_month SMALLINT;
ALTER TABLE artist_alias ADD COLUMN begin_date_day SMALLINT;
ALTER TABLE artist_alias ADD COLUMN end_date_year SMALLINT;
ALTER TABLE artist_alias ADD COLUMN end_date_month SMALLINT;
ALTER TABLE artist_alias ADD COLUMN end_date_day SMALLINT;
ALTER TABLE artist_alias ADD COLUMN primary_for_locale BOOLEAN NOT NULL DEFAULT false;

ALTER TABLE artist_alias ADD CONSTRAINT primary_check
CHECK (locale IS NULL AND primary_for_locale IS FALSE);  

DROP INDEX artist_alias_idx_locale_artist;

CREATE UNIQUE INDEX artist_alias_idx_primary ON artist_alias (artist, locale) WHERE primary_for_locale = TRUE AND locale IS NOT NULL;

However, I see that we're now dropping legal name, which essential makes all the type tables identical. Does it make sense for these to now be unified, and prepopulated with "Name" and "Search Hint" types? Or do we imagine these types diverging in the future, and maintaining separate lists being a better option?

I'd be in favour of having legal name as an alias instead of a separate artist.

I also agree that removing "redundancy" in artist-amounts is a good idea, eg, artist credits and artist aliases, sound like a good idea to remove a lot of unneeded extraneous artists that where added simply to catalogue that "the full, legal name etc of this artist is slightly different than the artists current better known name" (or very different)

as upposed to things like björk that's known, and (released) both under her full name and her "stage name"

or indeed, "ee cummings" or "k.d. lang" like situations.

this is pretty good idea with things like maiden-name/marriage name, or people who change their name because of things like gender-change etc.

Please do not drop the "legal name as an alias" concept. I think separate objects for legal names are justified only if the artist created multiple projects or concepts and one of them is credited with his legal name. One current example is: Tomáš Dvořák / Floex
http://musicbrainz.org/artist/d6d87219-24e7-4e72-b42a-a72cb82754b4 / http://musicbrainz.org/artist/24b70d13-85ab-410b-a044-2cca4600b1e1

In the future I would even go further in utilizing the aliases:

• Artist credits would be composed of aliases (to get rid of the duplication which comes with ACs). Of course for this to work effectively creating such an alias should be (almost) as easy as creating artist credits.
• Artist object name could be one of the object aliases.

Ollie: I can easily see them diverging, e.g. we might want things like "married name" for artists. Not null for sortnames seems like it would conflict with not having sort names for search hints.

This ticket is in danger of being rejected from the upcoming schema change release. Please provide UI mock-ups today.

On UI, from the comments above:

These attributes should be settable from the add alias page (/ENTITY/MBID/add-alias) and the edit alias page (/ENTITY/MBID/alias/ID/edit) (in the same way we can now set locale, + a checkbox for primary)
They should be shown on the aliases tab (/ENTITY/MBID/aliases) (for example, the table could be "ALIAS SORTNAME TYPE DATES LOCALE PRIMARY". This could get a bit crowded, but we will survive.). Also (I'm adding this now) ideally "real" aliases would all appear before search hints.
They should be shown in add alias and edit alias edits when the attributes are being added/edited.
They should be shown in remove alias edits.
They should be returned in any relevant WS queries (whenever aliases are returned).

I think nikki's original comment clearly defines the UI changes for this ticket, so I vote that it is included in this set of schema changes.

The changes to the web service schema still need to be clarified. I would like all of this data to be shown in our web service.

Do we want to allow aliases to have no type, or should they always use one of the above types? Understandably we can't fix bad data, but we can put checks in place to prevent future aliases from having no type, and fix up old data with reports.

I think they should be able to have no type. You want to be able to add an alias when you're not sure which type it is without being forced to guess.

Ok, that's easy then. Thanks!

In review at http://codereview.musicbrainz.org/r/1854/