+1, for examples use tag "multiple iswc", http://musicbrainz.org/tag/multiple%20iswc

If this gets implemented, I would suggest that the webservice be updated to treat works/iswcs precisely analogously to recordings/isrcs.

A work would have an iswc-list element, which would itself contain iswc elements. It would be possible to lookup an iswc directly, e.g. /ws/2/iswc/ABCD1234, which would return an iswc element, which would itself contain a work-list element.

This looks really straight-forward, since we already have multiple ISRC codes for recordings, so this should work quite symmetrical. Is there anyone who objects to this feature?

I agree with this server feature, but I would like to see a style guideline enforcing the definition of a work, so we know when 2 works can be merged. Right now 2 different ISWC codes for one work is a strong indication that 2 different works should exist in MB.

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

• Specify exactly what the user interface changes will be. Mock ups would be great. Due date: April 2

• Change UI to match that of ISRCs. Pages that need to be adapted are:
  • /work/GID/* mbs-2885-work.png mbs-2885-edit-work.png
  • /artist/GID/works
  • /search?query=type=work mbs-2885-search-work.png
• Pages that need to be created are:
  • /iswc/ISWC mbs-2885-iswc.png
  • /work/GID/add-iswc mbs-2885-add-iswc.png
  • /iswc/delete?iswc_id=XXX mbs-2885-remove-iswc.png
    See screenshots how it should look like

• Specify exactly what the database changes will be.

• New table "iswc":

  CREATE TABLE iswc
  (
      id             SERIAL,
      work           INTEGER,
      iswc           CHARACTER(15),
      source         SMALLINT,
      edits_pending  INTEGER,
      created        TIMESTAMP WITH TIME ZONE
  );
  

• Remove "iswc" row in the "work" table, after moving all iswcs into the new "iswc" table

Thanks for all you great work. I like all the pics except I think it's a pity if we loose the ISWC in work creation page (mbs-2885-edit-work.png), I wish we could keep one ISWC field as I almost always create works with ISWC.

We could instead match multiple ISWC in that field (.match(new RegExp(iswc_pattern, "gi"))).

I also don't want to lose the ability to add an ISWC while creating or editing a work (and I don't need multiple ISWCs, so it seems the proposal currently has nothing but downsides for me).

I've attached my suggestion for the interface. It's basically the same as what's used in the release editor for multiple labels. This suggestion would also mean that no "Add ISWC" link would be needed in the sidebar, and no "(remove)" link would be needed next to the ISWCs in the sidebar, because we would do it all via the edit tab.

Nikki, I believe addiswc.png is your suggestion ?
I want to state that we do need multiple ISWC for some works anyway.

The iswc table looks good, but I'm curious about unique constraints. Presumably you want the id column to be the primary key, but what about the iswc column? Is there ever a case where a ISWC is used by >1 works? If not, could we use iswc as the primary key, and if we need that then we could extend it to work, iswc.

Also, all columns are missing NOT NULL and foreign key constraints, and presumably we want a CHECK constraint on iswc to make sure it's stored consistently.

I'm not sure whether the source column needs to be there, because we don't use source on isrc either.

Yes, there are cases where an ISWC is used by more than one work. For me, they're ones where JASRAC has not made a distinction between original and translated versions of a song. Here's an example:
http://musicbrainz.org/work/4599153e-ad5c-36fd-848a-c24a84fba091
http://musicbrainz.org/work/9b61fc07-3138-3652-a608-5a0cda91b0e7
http://musicbrainz.org/work/a5409ad5-ab43-3b92-8199-35b7ae92c505

I've also seen times where of top work would have one ISWC and we could have sub works in MB for convenince purpose and they will all have the same ISWC (I don't remember my example but I think I saw that once, on a CD).

This ticket's schema changes are still not complete. Nudge! Please finish updating: http://wiki.musicbrainz.org/User:RobertKaye/Schema_Change_Release_May_2012

The schema changes for this ticket are complete, and think the UI mockups clearly show how the UI will be updated.

The changes for the web service need to be discussed for this ticket. Are we going to display these ISWCs in a new <iswc-list> element?

Sorry for not commenting earlier:

• I just copied the "source" column from the ISRC table, and have no idea what it is used for. If it isn't used, I suggest to remove it from the proposal and also from the ISRC table (it's a schema change, isn't it?).
• As for the UI proposed by nikki: I can't decide this. In my opinion ISRC/ISWC UI should be handled the same, it is confusing if they are handled differently... maybe it is enough to have just one ISWC field for the "Create Work" page (without the "label-like" handling)?

The source I guess is to tell whether ISRC comes from CD or online DB.
And yes, a simple text field would be enough for ISWC in add work.
You say the treatment should be same ISWC and ISRC. I add IPI same same too.

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

@hrglgrmpf: I do agree that they should eventually be the same, but they are already handled differently (ISWCs are added/edited via the edit tab, ISRCs aren't), so I don't think it's a big problem for them to continue to being different for a bit longer, until the UI for ISRCs is updated.

I don't really like the idea of having just one ISWC field on the "Create Work" page (what about when editing a work?), that sounds more confusing than having all the editing for ISWCs in one place and it would still mean that the UI for ISRCs and ISWCs is different.

Ollie also already said on IRC at some point that he would rather add more JS (i.e. add label-like handling) than add more pages (i.e. ISRC-like handling), so it seems like the devs are fine with the suggestion if other people agree.

I don't really like the idea of having just one ISWC field on the "Create Work" page (what about when editing a work?), that sounds more confusing than having all the editing for ISWCs in one place and it would still mean that the UI for ISRCs and ISWCs is different.

As long as we do not add extra steps (clicks, waits) to enter work. No extra steps like the label lookup for instance.

nikki is right, I was mostly saying that we already require JS for the release editor, so we might as well embrace it and add a much more pleasing UI.

The change made to the webservice for this ticket breaks backwards-compatibility with existing applications that use the webservice to lookup iswcs, I've opened http://tickets.musicbrainz.org/browse/MBS-4752 to track that issue.