search

OpenEnergyPlatform / omi

Repository for the Open Metadata Integration (OMI). For metadata definition see metadata repo:
https://github.com/OpenEnergyPlatform/metadata
GNU Affero General Public License v3.0
7 stars 4 forks source link

Function to split and join metadata for multiple tables #54

Open chrwm opened 2 years ago

chrwm commented 2 years ago

A function would come in handy to split and join metadata from existing tables.

1st use-case: 1 metadata string with multiple tables in key resources. Create one metadata string for each resource and copy the general information to each individual new resource-metadata-string.

2nd use-case: reverse 1st use-case

jh-RLI commented 2 years ago

To make it clearer, you want a function that can add the metadata to any table referenced in the resources?

We can also use omi to 1. read the JSON string and create a python OEMetadata object (parse) 2. Modify the object parsed.key.value = new.value and then 3. compile, render and save the Object back to a JSON file. I added a simple usaage section to provide an example.

In general i think we maybe should not add this functionality to ´omi´ but to an other tool like the ´oep-client´.

chrwm commented 2 years ago

@Ludee and I were speaking about it.

To make it clearer, you want a function that can add the metadata to any table referenced in the resources?

For example, 1 metadata json that has 5 different tables in the resources should be split in 5 metadata jsons that have respectively 1 individual table in the resources. Each table inherites the general information too.

We can also use omi to 1. read the JSON string and create a python OEMetadata object (parse) 2. Modify the object parsed.key.value = new.value and then 3. compile, render and save the Object back to a JSON file. I added a simple usaage section to provide an example.

This seems to be about the functionality I described.

@Ludee what do you think

jh-RLI commented 2 years ago

Thanks for the explanation :) Also to clarify my point: I think it is not necessary to create 5 new metadata files. We can also just add the same json to all the tables, but cut out the resource keys that don't belong to the "current" table. Also, I think it will be problematic to split the source information when the resources are split, since we still have no way to identify the table a source refers to (or am I missing something?).

chrwm commented 2 years ago

I think it is not necessary to create 5 new metadata files. We can also just add the same json to all the tables, but cut out the resource keys that don't belong to the "current" table.

That's also a feasible approach, which should yield the same result, I think.

I think it will be problematic to split the source information when the resources are split, since we still have no way to identify the table a source refers to (or am I missing something?)

I agree for some use-cases this will be a problem. @Ludee and I thought had the open-mastr use-case in mind, where one only has one source and a variety of possible table outputs.