Repository for the Open Energy Family metadata. Contains metadata templates, examples and schemas. For metadata conversion see https://github.com/OpenEnergyPlatform/omi
Two problems were put forward with the current structure of the string.
Top level keys can be interpreted as belonging to all resources that a metadata string describes. It is not possible to differentiate that e.g. some source information only belongs to one specific table and not to another. A strict, unambiguous structure would put some, if not most top level keys under resource. A different solution would be to drop support for multi-file descriptions. A compromise could see a significant restructuring of multi-file datapackages, i.e. basically listing all resources with separate top level keys.
If the metadata are to be fully machine readable, the values need to get a stricter definition. Ambiguity must be avoided. That would apply to the contents of spatial and also things like contact (e-mail-address? GitHub User account? Employer profile page?). The first problem is also relevant here.
These would be significant changes, so it will need to be discussed.
Two problems were put forward with the current structure of the string.
spatialand also things like contact (e-mail-address? GitHub User account? Employer profile page?). The first problem is also relevant here.These would be significant changes, so it will need to be discussed.