I added a description to the Specification.

as long as that artist is not claimed, he should be able to edit name and mail address, e.g. to correct typos. but anything else should only be editable by someone who claimed it.

This could work in principle and it's implementation depends on the solution of #340. It might need a hand crafted form (~3h).

We also need to provide the user with information, why an object created by him is not editable anymore - e.g. by mouseover on an deactivated edit icon.

Should the web user be able to add the creation for the first artist?

yes, but he should leave it to the artist to commit -- is that possible? that way, the original artist could check the validity and still decide to discard the entry without raising a dispute.

The object is auto commited and should be - all related objects must not be uncommitted, as they could be a distribution relevant part of the system (being the reason for the commit workflow). In this case, some Artist X referenced one of his Creations A as a derivative of the Creation B of another Artist Y.

Should Y really be able to discard B? The normal usecase for the need of a discard would be the claim of an artist with a wrong collection. Perhaps there should be a "unclaim" button/mechanism for Releases and Creations (but not Artists), by which the creation/release(+creations) is split from the artist and added to another new artist with the same name?

To implement, what you have in mind, we should expand the claim process by a "claim_revised" flag. Unrevised objects could then also be promoted on the dashboard distinguished from the uncommited ones. The question then is, if changes to unrevised objects should be handled exactly like commited objects - those objects are related and we could loose information, if a freshly claimed artist would change them.

Should the web user be able to edit the first/second/third created artist?

second/third: only if he created the artist, then treat it like usecase 1. if someone else created the second case, only that one should be in the position of usecase 1.

Thinking it through, the solution depends on how to relate to Artists during the creation of a foreign Creation, see #341. If we decide to omit the search for artists in the database and don't want to match Artists just by name, the first and second case is not possible.

In this case, some Artist X referenced one of his Creations A as a derivative of the Creation B of another Artist Y.

Should Y really be able to discard B?

i think there's two possibile cases here:

1. if B existed before in the database and Y had already claimed it, Y should be able to discard the relation between A and B
2. if B didn't exist before but was newly created by X, Y should be able to reject B completely

i assume that Y would only do that if B is indeed not his/her creation or if he/she knows for sure that A is not a derivative of it. that is because Y wouldn't gain anything by rejecting, only by accepting the link, so there's no incentive for falsely rejecting relations from Y's perspective.

the question is what should happen to B if Y rejects the creation. if Y doesn't want to claim it, it should probably be kept as a creation by an unclaimed artists with the same name, like you proposed, because there's also no incentive for X to falsely adding such a relation (because it will split the revenue). in cases where there are other artists by the same name already, they should be able to directly see the unclaimed work somewhere in their profile, so they can check if it's theirs and then probably claim it.

1. if B existed before in the database and Y had already claimed it, Y should be able to discard the relation between A and B

This could be covered by the commit workflow I proposed concerning the revision of freshly claimed objects. My question was, if those should be handled exaclty like uncommitted objects, so everything (including original creations) could be changed without dispute until revised. after revision, no easy changes anymore, but a dispute over why to change some metadata.

In general this sounds reasonable, as the user should be provided with an easy edit phase after claiming a bunch of auto-created objects.
On the other hand, this could possibly be an attac vector, as someone could claim all unclaimed songs and change all the metadata. And those auto-created objects could already have been used for money distribution.

1. if B didn't exist before but was newly created by X, Y should be able to reject B completely

I am with you, that there's no incentive for both sides to manipulate the data. But I disagree in general, that any author should be able to reject derivatives - those are declared derivatives by their artists. If you have a decent popular hit, you probably cannot possibly validate all derivatives. In short, information about the derivatives is not information of the original artist, but of each derivative artist and therefor should not be pertubated by the original author.

By the same reasoning, I propose to omit the definition of derivative creations at all, and to just provide the original creations see #399.

Ok.