## 4 Application Implementation
### Conflicting Rights Governance  
As declared in the previous sections, the conflicting musical rights governance and management happens on-chain with Solidity smart contracts leverage and control. In this section, the conflicting copyrights governance is introduced, defined and described. It constitutes the greatest portion of the application's business intelligence, while it is developed and executed through the appropriate methods triggered inside these smart contracts. In the context of organizing, detecting and resolving conflicting rights of contradictory assets claims, the presented solution provides a special and innovative approach. In particular, all blockchain submitted music rights claims are organized in a dedicated smart contract that defines the necessary methods that are requested to be applied on on-chain claims when called by the implemented application. This smart contract, namely Claims, illustrates every claim of a music asset in a Solidity structure (\"struct Claim\") of distinct attributes, as depicted in Figure 7.  
Figure 6: Technology stack from bloom API view. Naturally, a claim includes its status, which is either marked as claimed (where there is no disagreement on the rights declaration when compared to any other claims of the same asset) or conflict (where one or more claims declare overlapping fields in the claim declaration, and rights disagreement occurs). Diving deeper, the claim data field, named claimData, is stored as a string pair array (NameValue type), and includes the main rights areas in which claims could be conflicted. Namely, the most common and significant rights features constitute the rights percentage split, the start and end dates of the rights, the rights territories of validity and the rights type (Figure 8). Considering that submitted assets with the same international standard code are referencing the same musical asset, both sound recording and musical works types of assets are studied here; the International Standard Recording Code (ISRC) is used for the sound recording type of musical asset and the International Standard Musical Work Code (ISWC) is used for the musical work type of musical asset. In addition, other logistics details exist in the claim Solidity structure, such as the creation and last change dates, claim type (either sound recording or musical work), its claiming Member and its identification (unique claim id) that is regularly used on-chain to separate claims from one another. Specifically it includes creation date, claim id, claim data, claim type, user member, claim status, last change date and max split. Each one has a specific role, with some of them having major ones, when considering the whole workflow perspective of the conflicting rights governance and its procedures that are completed by respective smart contract methods. Figure 8: Claim overview with claim data when updating a claim. Figure 7: Solidity smart contract structure representing a claim. The management and governance of the conflicting copyrights claims that were submitted to the blockchain occur mainly when calling the private method \"checkClaimStatus\". This method is able to call the private mapping where the claims reside inside the smart contract. These privacy features mainly mean that the methods and mappings cannot be accessed by any other smart contract or the application directly. The private method \"checkClaimStatus\" is an implemented algorithm in Solidity that receives the information of a new claim and ensures its interaction with all the relevant formerly submitted blockchain claims. In particular, if there is a new conflict, then the status of one or more claims will be updated inside this method, by accessing and modifying the dedicated claims mapping, whereas if the new claim cancels conflicting rights, then the corresponding claim status information that needs amendment is updated. As mentioned earlier, since a claim's data field consists of a name-value array of string couples where multiple claim information is matched with their respective value (e.g.