Issue Details (XML | Word | Printable)

Key: MBS-2532
Type: Improvement Improvement
Status: Closed Closed
Resolution: Fixed
Priority: Normal Normal
Assignee: Kuno Woudt
Reporter: Nicolás Tamargo
Votes: 6
Watchers: 5
Operations

If you were logged in you would be able to see more operations.
MusicBrainz Server

Allow more than one IPI per artist

Created: 04/Jun/11 03:02 PM   Updated: 16/May/12 10:36 AM   Resolved: 15/May/12 07:40 PM
Component/s: Schema Change
Affects Version/s: None
Fix Version/s: Schema change, 2012-05-15

Issue Links:
Depends
 
Relates
 


 Description  « Hide

Ideally every artist should have only one IPI... but I've already found artists who were registered twice with two different IPIs. We should probably allow introducing this.



Sort Order: Descending order - Click to sort in ascending order
PATATE12 added a comment - 03/Apr/12 11:45 PM

For WS, <ipi-list> seems good for me.


Oliver Charles added a comment - 03/Apr/12 11:34 AM

The changes to the web service still need to be discussed. Should we introduce <ipi-list> elements for artists and labels?


Oliver Charles added a comment - 03/Apr/12 11:24 AM

I think the UI for this is simple enough to work on during the schema change version (the upcoming month). Nicolás has pointed out the options for the write interface, for the read interface it's really just a case of enumerating all IPIs


Nicolás Tamargo added a comment - 02/Apr/12 07:03 PM

While I suck at mock-ups, this UI is pretty much described in comments, and has two options depending on whether it is possible to do it all now or it has to be broken in two.

a) If possible, keep it in the same place as it is now, but add a button to add more IPIs, in the same vein as we have buttons to add more labels to a release (on clicking, another row appears).

b) If there's no time to implement this UI right now, add it for now in the same way as we do for recordings and ISRCs - "Add IPI" in the sidebar, allowing to add one IPI per use.


Robert Kaye added a comment - 02/Apr/12 06:57 PM

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


Oliver Charles added a comment - 30/Mar/12 02:21 PM

As I haven't heard a convincing argument for the IPI table, I propose a schema without that table. A summary of the DB changes are now at http://wiki.musicbrainz.org/User:RobertKaye/Schema_Change_Release_May_2012#Database_changes_3


Aurélien Mino added a comment - 28/Mar/12 09:04 PM

I've no opinion on whether ipi should be stored in "artist_ipi" and "label_ipi", or in "ipi".
I'll leave the final decision to developers, as an implementation detail that I'm unable to resolve.


Kuno Woudt added a comment - 28/Mar/12 08:41 PM

Oliver, artists and labels share the same space in IPI. i.e. someone looking up an IPI code may only know the code and not know whether the entity represented by that code would be in the artist or in the label table in musicbrainz. So, it could make sense to store them in a single table, but I don't see any real benefit in that over storing them in "artist_ipi" and "label_ipi" tables – we need to link them to artists and labels anyway.


Aurélien Mino added a comment - 28/Mar/12 08:30 PM - edited

Also, why is the label.ipi_code drop commented out?

Because I was planning to work on that branch on a slave database, so temporarily keeping old columns was allowing me to keep my database updated while doing development.


Robert Kaye added a comment - 28/Mar/12 07:26 PM

This ticket is not complete on http://wiki.musicbrainz.org/User:RobertKaye/Schema_Change_Release_May_2012 . Please work to settle the proposed schema changes. The deadline for these proposed changes is tomorrow.


Oliver Charles added a comment - 27/Mar/12 01:19 PM

Also, why is the label.ipi_code drop commented out?


Oliver Charles added a comment - 27/Mar/12 11:41 AM

My only comment would be why the ipi table has an id column. Dropping that column leaves us with ipi.ipi, which then means we don't even need the ipi table at all. This seems quite nice, because it resolves my next question, which is - does it make sense for artists and labels to share the same space for IPIs? I don't know how IPIs work so maybe that's fine, but it's something that came to mind.


Aurélien Mino added a comment - 19/Mar/12 09:56 PM

I hate how ISRCs are done right now. I would really rather see the interface done like multiple labels for releases, where there's a button on the add artist (etc) page to add another one, so that it can all be edited by clicking the edit tab.

I agree with you, but this is out of the scope of this ticket.
And the more user changes you put in this feature request, the least it has chances to happen at end.


nikki added a comment - 19/Mar/12 09:48 PM

I hate how ISRCs are done right now. I would really rather see the interface done like multiple labels for releases, where there's a button on the add artist (etc) page to add another one, so that it can all be edited by clicking the edit tab.


Aurélien Mino added a comment - 19/Mar/12 09:31 PM - edited

Specify exactly what the user interface changes will be

  • Drop the IPI field from the "Add artist", "Add label", "Edit artist" and "Edit label" screens
  • Add a new action in the artist/label sidebar "Add a new IPI"
  • Be able to display multiple IPI codes in the sidebar whereas only one is displayed currently
  • Add a "(remove)" action next to each IPI code displayed in artist/label sidebar

In fact IPI codes should be handled pretty much like ISRCs are currently handled (same add/edit/remove process)

Specify exactly what the database changes will be

I think this describes it quite accurately: https://github.com/murdos/musicbrainz-server/commit/64acfdf66906804f132627216c566d3038002220


Robert Kaye added a comment - 19/Mar/12 09:18 PM

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

Aurélien Mino added a comment - 19/Mar/12 09:16 PM

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

I'm not aware of any objections to storing multiple IPIs per artist. This ticket has a number of votes and comments, so I'll take that to mean there is a consensus that we should implement it in some form.

My proposal is:

We should be able to store multiple IPI codes for an artist or a label, since we have a more strict definition of a distinct artist than right management societies.

Each IPI should be shown on the artist page (/artist/MBID) in the sidebar
A new IPI code can be added with a "Add a new IPI" action in the artist sidebar
An existing IPI should be removable though a "remove" link next to the code in the sidebar.
They should be returned in any relevant WS queries

These editing actions should not be displayed when the user is not logged or not able to edit.

I don't know what supporting documentation, if any, would be needed.

Notes:

1. Multiple IPIs per label has not been explicitly requested, but I think it's a good idea to share the same data model for artist and label ipi.


Johannes Weißl added a comment - 08/Aug/11 07:06 AM

I found another one... let's tag all examples with "multiple ipi":
http://musicbrainz.org/tag/multiple%20ipi/artist


PATATE12 added a comment - 10/Jun/11 05:48 PM


zos18 added a comment - 04/Jun/11 03:20 PM

http://musicbrainz.org/edit/14482947

00151 89 41 63 MANU CHAO
00145 95 88 31 José-Manuel CHAO
00151 89 40 65 CHAO MANU


Aurélien Mino added a comment - 04/Jun/11 03:04 PM

Could you please list the examples you're finding here?