I've added a metadataProvenance object that gets attached to the working context and keeps track of which keys in the metadata arise from which sidecar file. Now, when high-level issues are reported about the metadata, the issue outputs point directly to the actual problem file rather than the default metadata file.
In the course of this PR, I also uncovered and resolved an error where schema.org rules were being checked upon finding a "dataset_description.json" file in the tree, when really these rules should be checked every time a valid datafile is encountered (because sidecar inheritance makes it so every datafile might have its own unique composite metadata object)
This PR closes issue #31.
I've added a metadataProvenance object that gets attached to the working context and keeps track of which keys in the metadata arise from which sidecar file. Now, when high-level issues are reported about the metadata, the issue outputs point directly to the actual problem file rather than the default metadata file.
In the course of this PR, I also uncovered and resolved an error where schema.org rules were being checked upon finding a "dataset_description.json" file in the tree, when really these rules should be checked every time a valid datafile is encountered (because sidecar inheritance makes it so every datafile might have its own unique composite metadata object)