ICRC3.mo

Standardized definition from Internet Computer responisble for storing the transaction log of the NFT's

ICRC7.mo

Standardized definition from Internet Computer responsible for defining the NFT

ICRC37.mo

Standardized definition from Internet Computer responsible for the approve workflow. Where the token (either unique or can contain a supply cap) is then transefered or allowed as a sub-owner of the token. Based on how it's defined in the file.

main.mo

These are all functions that implement those standards. We've also included endpoints that can be invoked in order to define a token, mint it, and transfer it. We've setup a testing function called test_workflow. Participants can deploy the canister and invoke this function using the candid UI. It will help them visualize how the NFT is created, minted, approved for transfer, checked for approval, transfered to the new owner or added as a subowner, and lastly checking the transaction log to view the NFT transaction.
There is another function called test_create_collection that creates a new collection (not Knowledge token) through motoko code rather than the CLI. This will also help them visualize how the NFTS are defined and minted.
One last function is the innit function that creates the Knowledge token ICRC7 NFT and also initilizes the ICRC37 and ICRC3 code based on how they we're defined in their respective files.

Once users are comfortable with the workflow of how NFTs work. They can then refactor the main DeComm aaplication.

There are several ways to implement this based on how the participants would like to approach it. One way (but not the only way!) is to refactor the main code base allowing sellers to define their own NFT which can be bought with the Knowledge Token and buyers to be subowners of the Knowledge Token NFT once they have purchased the product.

Import the NFTCanister in the main/main.mo. (Define it as a dependency for the backend in dfx.json).
A seller will invoke the createProduct from the frontend. Define a new NFT which can be done in a similar fashion to the test_create_collection. Passing it arguments rather than being hard coded.

In the backend createProduct function take in the (_msg) message caller as an argument or any sort of identifier that can be used to identify that the user will be the owner of the NFT.
Create the product and once the product has been created successfully, call the relevant function in NFTCanister/main.mo in this case a modified test_create_collection that takes in arguments and pass it the relevant arguments such as the name of the NFT the url of the image etc.
Then mint the NFT and verify that it has been minted.
Return true to the user if the above step has been done successfully.

A buyer would like to purchase the NFT:

Once a user invokes the purchase method, call the relevant function from NFTCanister/main.mo which will add the person who purchased the NFT to be added as a the new owner or a subowner of the NFT.
This can be done in a similar fashion to the test_workflow function. Where they can use the same exact function modify it a bit in order to take arguments such as an identifier of who is purchasing the NFT.

The token can either be transfered to that buyer or they can be added as a subowner. Code it as you see fit.

You can call the relevant NFT functions in the for loop of the purchase method in the main/main.mo

I'm emphasizing the importance of the test_workflow and test_create_collection here. As deploying them and running them through the candid UI will better help you visualize how the whole process works.
Lastly get acquainted with identifiers such as the _msg, pricinpals, and Principal.fromActor(this), ICRC7.Account, etc... These are all key identifiers on who calls the functions and who owns or will be the owners of the NFTs.