Add stable link to latest oemetadata version

[danielhuppmann]

I'm a bit confused by having version numbers hard-coded in the folder structure. Say I want to include a link to the latest metadata version, is there a smarter approach than linking to the entire repository?

[Bachibouzouk]

@4lm, as you implemented the repository's structure, could you reply to this?

[4lm]

IMO to be explicit is a good thing, because the folder structure also work as modules for the Python implementation. This repo is IMO a living code base and not a fixed resource for linking against an permanent URL. As I suggested in #22 you could put the schemas on zenodo.org, there you also get a DOI and a permalink which always links to the lasted version.

[jh-RLI]

@Ludee Should we host the files on zenodo.org? We could also offer these on the oep?

[jh-RLI]

#16

[Ludee]

They are example files for "data packages". So they can be used as examples and templates to upload data. But it makes sense to have them as live examples in the database as well.
Zenodo is an option to have a DOI to cite in publications.

An easy solution is a folder oemetadata-latest and have a copy without version number on master branch. Then we have a stable url.
Perhaps there are better solutions.

[christian-rli]

I agree that being explicit is good, so I approve of version numbers benig hard coded in the folder names. I also like @Ludee 's suggestion to use oemetadata-latest. This is also used for data downloads that change frequently, for example in openstreetmap.

[jh-RLI]

Generally, I think we should publish the OEM via the OEP or the API (or both). On the one hand, this will make the platform affiliation clear (even if oemetadata is quite clear) and on the other hand, we have a clear release without confusion about the current/latest release and also make the OEM more publicly available even outside of GitHub. This would complete the representation of OEM on the OEP, as we already have the functionality to create, read and edit OEM implemented on the OEP.

I see three options here:

1. implementing the oemetadata-latest folder (and link it on the OEP)
2. Implement a new view/API function on the OEP that publishes the latest version of the OEM (from static file or database), a new OEM release would trigger a deployment procedure that includes updating the OEM version on the OEP
3. Use Zenodo

[jh-RLI]

I think the implementation of a "latest-release" and a "current" version is reasonable. Therefore I would implement this structure regardless of the option chosen here.

[jh-RLI]

Since the discussion, there is related to this issue: OpenEnergyPlatform/omi#26

@MGlauer What do you think about this:

2. Implement a new view/API function on the OEP that publishes the latest version of the OEM (from static file or database), a new OEM release would trigger a deployment procedure that includes updating the OEM version on the OEP