We ought to specify how locally defined code-lists are written to disk, for example:
Is there one CSV-W per code list so that code-lists can be copied around and RDF generated independently of the data cube?
If this is the case then since the metadata is stored in a separate CSV-W (as in csvcubed outputs), we need some kind of triples which set out that the primary data cube CSV-W is dependent on the metadata from each of the separate code list CSV-W metadata files. Without an explicit dependency here, there is no way for us to know what the code list's label/title is, what it represents, or even that it is a skos:ConceptScheme (when outside of an everything-in-one triple store).
Or is there only one CSV-W which describes the CSVs (and their columns) for the data cube and each of the local code-lists; presumably the metadata for the data cube and each of the code lists would all be bundled into the one -metadata.json file.
In this case dependency declarations aren't so critical.
We ought to specify how locally defined code-lists are written to disk, for example:
skos:ConceptScheme(when outside of an everything-in-one triple store).-metadata.jsonfile.