Export of existing terms and definitions #1020

[stage1407]

Summary of the discussion

Create a script that writes an auto-generated glossary in a markdown table.

Type of change (CHANGELOG.md)

Added

• Added a new script etd.sh
• Added a new script etd.py
• Added a new markdown README.md

Workflow checklist

Automation

Closes #

PR-Assignee

• 🐙 Follow the Pull Request Workflow
• 📝 Update the CHANGELOG.md
• 📙 Add #'s to term tracker item

Reviewer

• 🐙 Follow the Reviewer Guide
• 🐙 Provided feedback and show sufficient appreciation for the work done

[stap-m]

Thanks for the script @stage1407
Could you please add information (to the README?), where the glossary be accessible?
Will the glossary be updated (automaticcaly), when there's a new release?

[stage1407]

Yes, I have added this information.
No, this has to be done manually in the terminal so far. But if this is to be automatic, then someone more familiar with the Makefile should implement this procedure. It should be nothing more than adding the command to the Makefile, but I don't know where in the Makefile. I think a new issue should be started for this one.

[areleu]

The python script is missing a requirements.txt this should include both pandas, openpyxl and tabulate. I would say that this requirements.txt should include also the dependencies of the rest of the scripts.
I had to do some adjustments to be able to run it on windows but these are not critical as we are building this in github aren't we?

There is an issue with some terms appearing as IRIs. I think having all the term appearing as IRIs would be nice. Like making them into a link like:

OEO:00010252

[stap-m]

Looks great, thanks! @areleu
@stage1407 and @carstenhoyerklick can you please take a look?

Once we agreed on a final place (I like the idea of storing it in the wiki), we should also adjust the respective README.md and maybe link the glorrary to the main README.md, too.
EDIT: And if it stays in the wiki, update wiki sidebar.

[l-emele]

Once we agreed on a final place (I like the idea of storing it in the wiki), we should also adjust the respective README.md and maybe link the glorrary to the main README.md, too.

A while ago, we discussed in the OEO Dev meeting, that this should be part of the release cycle:

We discussed today at the OEO DEV meeting, that it would be also nice, to produce such a file during the release process. On option would to be to export a list of IDs, labels (terms) and definitions to an markdown file that is then part of the repo.

Originally posted by @l-emele in #1020 (comment)

So it should be not only in the wiki, but also part of the files that is transferred to the OEP after release.

If I remember correctly, the OEP is able to render markdown files. Is that right, @wingechr ?

[l-emele]

On one hand, I like having the the possibility to jump to a specific letter. But if I see correctly, there are now multiple markdown files. But the original idea was to export all definitions to one single file for easy for facilitate simple re-use.

[areleu]

On one hand, I like having the the possibility to jump to a specific letter. But if I see correctly, there are now multiple markdown files. But the original idea was to export all definitions to one single file for easy for facilitate simple re-use.

I don't think these have mutually exclusive. We can use the same script to generate a csv file on the side. The reason I divided it in different pages was that It seems that GitHub has a limit on the page height and it was being cut.

[l-emele]

Okay then. I just wanted to avoid that we create a solution, that does not solve the original problem, ;)

[stap-m]

I put this PR on the agenda for the next dev meeting to finalize it.

[areleu]

I added the changes we agreed on the last dev meeting. I will also add the option to upload a csv file with the list. I would like to know how can I integrate this into the OEP, is there a way to upload this with the API?

[areleu]

The existing terms and definitions are there as a table availible. We can output markdown and csv files. The open question is where this information should be made availible. Directly in the OEP? if so. How can this be made and where?

Independently of this, I think this PR can be merged as it does not break anything and any further changes needed for the OEP integration can be worked in a new one.

[l-emele]

I think having both a markdown and a csv file to download on the OEP is fine as these target different users. The markdown file can probably also be rendered directly on the OEP.

EDIT: I opened an issue in the OEP repo: OpenEnergyPlatform/oeplatform#1123

[areleu]

@stap-m If you look at the bottom of the job summary there is an optiion to download a zip file with the contents of the tables:

https://github.com/OpenEnergyPlatform/ontology/actions/runs/3713531310

Let me know if there is anything critical to change, otherwise I will just merge it.

[stap-m]

Looks fine from my side!