Fix grammar and spelling

EIPS/eip-5553.md

@@ -12,18 +12,18 @@ requires: 20, 721
 ---
 
 ## Abstract
-This proposal introduces a generic way to represent intellectual works on chain, along with a refined royalty representation mechanism and associated metadata link. This standard is not associated with a specific type of work and could represent many types of works such as musical works, videos, books, images and more.
+This proposal introduces a generic way to represent intellectual works on chain, along with a refined royalty representation mechanism and associated metadata link. This standard is not associated with a specific type of work and could represent many types of works such as musical works, videos, books, images, and more.
 The standard is kept very generic on purpose to allow the industry to evolve new ecosystems that can all rely on the same basic standard at their core.
 
 This standard allows market participants to:
 1) Observe the canonical on-chain representation of an intellectual work
 2) Discover its attached metadata
 3) Discover its related royalty rights holders
-4) In the future, this will enable building registration, licensing and payout mechanisms for intellectual property assets.
+4) In the future, this will enable building registration, licensing, and payout mechanisms for intellectual property assets.
 
 ## Motivation
 
-There is no accepted standard mechanism to license a work, or to represent it, except using traditional NFTs. But regular NFTs only represent a collectible item use case, and cannot easily represent more complicated use cases of licensing a work for different types of uses.
+There is no accepted standard mechanism to license a work or to represent it, except using traditional NFTs. But regular NFTs only represent a collectible item use case, and cannot easily represent more complicated use cases of licensing a work for different types of uses.
 To enable such mechanisms, a more robust mechanism is needed to:
 1) Declare that a work exists, SEPARATELY from its purchase ability
 2) Declare possibly multiple interested parties to be paid for such work 
@@ -46,13 +46,13 @@ Implementers of this standard **MUST** have all of the following functions:
 ### royaltyRightsTokens() function
 This function MUST return an array of addresses related to [EIP-20](./eip-20.md) tokens that MUST represent royalty rights to different types of interested parties. These royalty rights tokens represent a more granular and streamlined way to declare royalty splits for multiple collaboration participants for the creation of the work. 
 
-For example, for a musical work, we might have two tokens representing the composition/writing/publishing royalty rights side, and the recording/master side. These royalty rights tokens are distributed to the collaboration participants and can later be queried for the various holders, for purposes of distribution of royalties - i.e if you hold 10% of a royalty rights token, you will get 10% of financial distribution related to that type of royalty.
+For example, for a musical work, we might have two tokens representing the composition/writing/publishing royalty rights side, and the recording/master side. These royalty rights tokens are distributed to the collaboration participants and can later be queried by the various holders, for purposes of distribution of royalties - i.e if you hold 10% of a royalty rights token, you will get 10% of financial distribution related to that type of royalty.
 
 ### metadataURI() function
-This function MUST return the URI to a metadata file containing any required metadata for the work, or an empty string. Each work type MAY implement its own metadata standard, defined separately. The file will MUST be hosted in IPFS or Arweave or other decentralized content-addressable systems in which the file's contents are not changeable without changing the URI.
+This function MUST return the URI to a metadata file containing any required metadata for the work, or an empty string. Each work type MAY implement its metadata standard, defined separately. The file MUST be hosted in IPFS or Arweave or other decentralized content-addressable systems in which the file's contents are not changeable without changing the URI.
 
 ### changeMetadataURI() function
-This function allows changing the metadata URI to point to a new version of the metadata file. Calling this function MUST trigger the event `MetadataChanged` in case of success success.
+This function allows changing the metadata URI to point to a new version of the metadata file. Calling this function MUST trigger the event `MetadataChanged` in case of success.
 
 ### ledger() function
 This function MUST return the address of the registry or registrar contract, or an EOA account that initialized the work and associated royalty tokens. A work MAY be registered in multiple places by different actors for different purposes. This enables market participants to discover which registry mechanism is the parent of the work and might have special access rights to manage the work.
@@ -68,8 +68,8 @@ import '@openzeppelin/contracts/interfaces/IERC165.sol';
 ///
 interface IWorksRegistration is IERC165 {
     
-    /// @notice Called with the new uri to an updated metadata file
-    /// @param _newUri - the uri pointing to a metadata file (file standard is up to the implementer)
+    /// @notice Called with the new URI to an updated metadata file
+    /// @param _newUri - the URI pointing to a metadata file (file standard is up to the implementer)
     /// @param _newFileHash - The hash of the new metadata file, for future reference and verification
     function changeMetadataURI(string memory _newUri, string memory _newFileHash) external ;
 
@@ -81,16 +81,16 @@ interface IWorksRegistration is IERC165 {
     /// @dev i.e a registry or registrar, to be implemented in the future
     function ledger() external view returns (address) ;
 
-    /// @return the uri of the current metadata file for the work
+    /// @return the URI of the current metadata file for the work
     function metadataURI() external view returns (string memory) ;
 
     /// @dev event to be triggered whenever metadata URI is changed
     /// @param byAddress the addresses that triggered this operation
-    /// @param oldURI the uri to the old metadata file prior to the change
-    /// @param oldFileHash the hash of the old metadata file prior to the change
-    /// @param newURI the uri to the new metadata file 
+    /// @param oldURI the URI to the old metadata file before the change
+    /// @param oldFileHash the hash of the old metadata file before the change
+    /// @param newURI the URI to the new metadata file 
     /// @param newFileHash the hash of the new metadata file 
-    event MetadaDataChanged(address byAddress,string oldURI, string oldFileHash, string newURI, string newFileHash);
+    event MetadaDataChanged(address byAddress, string oldURI, string oldFileHash, string newURI, string newFileHash);
 }
 ```
 
@@ -99,7 +99,7 @@ interface IWorksRegistration is IERC165 {
 
 ### Returning an array of EIP-20 tokens presents a more robust royalty rights structure/
 
-Current royalty implementations deal only with a single type of royalty payments: NFT sales. They also only allow a single type of royalty - i.e you cannot have different royalty rights owners receive royalty based on different licensing types. 
+Current royalty implementations deal only with a single type of royalty payment: NFT sales. They also only allow a single type of royalty - i.e you cannot have different royalty rights owners receive a royalty based on different licensing types. 
 In other words, currently, a royalty split works the same way no matter what type of purchase or license deal has happened, for all parties involved.
 
 With this proposal, multiple **types** of royalty rights are allowed. A classic case is the music industry in which you have writing/composition royalties, and recording/master royalties. Different licensing types will pay different percentages to different parties based on context.
@@ -114,10 +114,10 @@ Moreover, this EIP has a single structure that connects to all types of royalty
 Lastly, moving EIP-20 tokens around is much easier than managing an 0xsplits contract.
 
 ### Separating the work from the sellable NFT enables scaling licensing types
-By separating the canonical version of the work from its various licensed uses (NFT purchase, streaming, usage of art etc..) this EIP introduces a path for an ecosystem of various license types and payment distributions to evolve.
-In other words, when people use this schmeme, they won't start by creating a music NFT or art NFT, they start by creating the works registration, and then create types of licenses for it, each as its own sellable NFT, possible in the form of [EIP-5218](./eip-5218.md) or other formats.
+By separating the canonical version of the work from its various licensed uses (NFT purchase, streaming, usage of art, etc..) this EIP introduces a path for an ecosystem of various license types and payment distributions to evolve.
+In other words, when people use this scheme, they won't start by creating music NFT or art NFT, they start by creating the works registration and then create types of licenses for it, each as its own sellable NFT, possible in the form of [EIP-5218](./eip-5218.md) or other formats.
 
-### A single pointer to the works metadata
+### A single pointer to the work's metadata
 The work points to metadata housed in IPFS or Arweave and allows changing it and keeping track of the changes in a simple and standard way. Today the only metadata standard is NFT metadata extension, but we do not know which standard the document adheres to. With different work types, different metadata standards for different work types can be formulated and have a simple easy place to discover attached metadata.
 
 ## Reference Implementation 
@@ -209,7 +209,7 @@ contract MusicalIP is ERC721, IWorksRegistration {
 
 ```
 
-#### Deploying a new music works instance using a simple song registry contract
+#### Deploying a new work of music using a simple song registry contract
 
 ```solidity  
 // SPDX-License-Identifier: Apache-2.0
@@ -246,9 +246,9 @@ contract SimpleSongLedger is IERC721Receiver {
 ```
 ## Security Considerations
 
-There might be potential security challenges of attackers persuading holders of royalty rights tokens to send them those tokens and gaining royalty rights in various works. However these are not specific to royalties and are are common issue with EIP-20 tokens.
+There might be potential security challenges of attackers persuading holders of royalty rights tokens to send them those tokens and gaining royalty rights in various works. However, these are not specific to royalties and are a common issue with EIP-20 tokens.
 
-In case of the works registration ownership, it will be recommended that registry contracts will own the works registration and it will be non transferrable (account bound to the registray that created it).
+In the case of the works registration ownership, it will be recommended that registry contracts will own the works registration and it will be non-transferrable (account bound to the registry that created it).
 
 ## Copyright