Split out metadata schema and description from etl_manager to metadata_schema repo

[RobinL]

I think there may be an argument for splitting out the metadata jsonschema into a separate repo, probably modelled after the vega spec repo.

Would be good to get the team to brainstorm pros and cons. Here's some I can think of:

Pros

• Can version etl_manager independently
• Probably simpler to version metadata schemas, and make sure all historical schemas are easily accessible. (You
• Encourages us to properly version our metadata schema, like vega do, using semver.
• Makes it clearer that our metadata schema isn't intrinsically tied to etl_manager. etl_manager is basically a set of converters, jobrunners, and metadata auditing tools.
• Makes it easier for us to talk about our metadata schema. It's no longer hidden away in etl manager, but a spec in its own right

Cons

• Need to version two things, so e.g. will need to be careful about compatibility between etl manager and metadata schema versions

[RobinL]

Another pro:

The schema is not actually python specific. For instance, we may want an R package that imposes metadata conformance on a dataset. So it makes sense for the repo containing the schema to be language agnostic

[RobinL]

I made this but we can delete if we decide we don't want

[isichei]

I agree with this in general but think we need to spend a bit of time closely defining what the meta schema should be. As atm I think the current schema is probably tied a bit too closely to etl_manager. If we did seperate I'd assume etl_manager should inherit this schema and then override areas which are more etl_manager specific?