Provide a method to declare a link between ISRC and ISWC / include conflict resolution

[revelator-labs]

Currently there are 2 known and acceptable methods:

1. MWN - as part of the Musical Work description; each time a new ISRC is linked to an existing ISWC a new message including the new track needs to be sent ! - This means that all the existing ISRCs need to be included in the new message (as all other data), otherwise they will be considered "disconnected" @criadoperez we should indeed confirm this is DDEX standard behavior..

2. ERN - as part of a Release description; Should we allow overwriting ISWCs in a release? I'm not sure that should be permissible; I think we should require creating a new release notification if to map between an ISRC and ISWC through an ERN - If the previous release needs to be omitted, then the data provider should use the existing Takedown message - Alternatively we may ignore ISWC info in ERN and require explicit MWN notifications to declare the connection (considering, many data providers may have noise in their ERN massages)

Appart from the DDEX standard we will also need to support CWR messages. That will be defined as a separate milestone

[criadoperez]

On the first point MWN:

I don't think DDEX gets into how to interprent the message, its more of the message iselft. So if you add a create an ISWC with 2 ISRC today, and tomorrow you send another message with the same ISWC and a new ISRC, values can be overwritten or added depending on your implementation.

For this I would recommend to use the field RelatedMessageId , so if you link the second MWN message to the first one, then we add the 3rd ISRC to the list. If you don't it replaces.

But at the end it's up to us to decide how to handle these things.

On the second point of ERN:

Should we allow overwriting ISWCs in a release?

That's an industry question more than a technical one, so I'm not the person to answer it.

Ideally the link between ISRC and ISWC should be in the MWN message instead no? Will we allow doing this both in MWN and in ERN? We could, but if we do we need to define a proper flow of which message has priority if they contradict each other.

[revelator-labs]

@criadoperez I agree that putting it in an MWN makes more sense, but since all of our messages will be tied to release notifications, we might not be able to rely on MWN being generated.

I would try to first stick with requiring the inclusion of the ISWC in the ERN and using that as the default. Then we should learn if publishers will indeed be able send MWNs or if we will need to accept(the nonDDEX) CWR message first.

If agreed. I will define that ERN is the first message supported in V1 and ISWCs must be declared in that message if they want to make a link.

[revelator-labs]

*by "requiring" I mean, making it optional to declare the ISWC but not compulsory

[revelator-labs]

Depricating this ticket after validating CWR is the correct format. ISWCs will reference all available ISRCs in their registration - linking to any existing ISRCs on the Registry