Consider Metadata as 'Data About Data'. There’s nothing hard about this one.
The simplest example I can give is of a Database. Lets say we have a "Job" table containing 4 fields -> Job ID, Job Run Time, Job Customer Process, Job Completion Date.
Each field is responsible for holding data. However, the reason for holding the data (or even what the data is for) may not be so obvious to a future user, especially in the above (contrived) example. To solve this problem, we could make notes to explain what each field "is" and "does". Example:
"Job Comletion Date refers to the REQUIRED date a job should be completed, not the ACTUAL date" and so on...
This is metadata - 'Data about Data'.
Hope this helps
Bodie