README.md: Modernize readme

[JAB1305]

Modernize readme
Closes #475
Superseeds / inspired by #490

Open (for discussion):

• Keep RDF support feature? Is this relevant? (last activity apparently 2y ago)
• Move Eclipse Contributor section to Contributing.md? (no mention there, at least duplicate?)
• Badges for python min / python max point to not yet merged branch (Restructure versions to a single point of truth #610). Should point to main, note that dev readme would then always be outdated on version bump until merged. Acceptable?

Fixes #475

[s-heppner]

Thank you for the draft! Let me answer your questions:

Keep RDF support feature? Is this relevant? (last activity apparently 2y ago)

Yes, let's keep it and keep reference to it. If more people know the problems (#422) with it, the more IDTA might change something with their RDF schema.

Move Eclipse Contributor section to Contributing.md?

Makes sense to me. Somewhere we do mention in the CONTRIBUTING.md that you need an Eclipse Account and sign the ECA already.

Should point to main, note that dev readme would then always be outdated on version bump until merged. Acceptable?

Can we not have the badge refer to the current branch's central config file? I don't think a badge on develop with outdated version is good, if someone actively needs a new feature they'd be massively confused.

[JAB1305]

Can we not have the badge refer to the current branch's central config file? I don't think a badge on develop with outdated version is good, if someone actively needs a new feature they'd be massively confused.

Unfortunately I was not able to find a way that allows for branch aware extraction of the version. The current version for the badge references a hardcoded raw.githubusercontent... URL that can in the future be either pointed to main or develop but have no way to just use "current". Also this method can only extract one value, so something like 3.10 - 3.12 in single badge would not be possible.

I think the two best options are either something like this:

(Imagine different version here)

Or to introduce a CI step that surfaces the versions, but that seems a bit overkill.

[s-heppner]

I see. And what if we used: "Python min" from main and "Python max" from develop? Then it's technically correct at all times and hopefully the times where develop diverges from main should be small.
But then again, this is also a good argument to simply use the versions from main...

I don't have a good opinion.

[JAB1305]

I am not sure if I like the idea of a merged range from main.min to dev.max as that is not what a potential reader would expect.

That would leave us with just having the main versions. What I would maybe add is something like:

Q: I am looking for a newer python version than the supported one on the release. Where can I find it?

A: Our develop branch will adopt newer python versions earlier than the latest main release. Currently - is supported there.

to the QA section?
Thats the idea I probably like most at the moment.

[s-heppner]

I like your idea, maybe without the actual version on develop.

The other option would be of course to simply remove these two badges.

[JAB1305]

In the current version the badges do not work, that is intentional.
I have pointed them at the main branch that does not have a versions.toml file yet. The image above shows behaviour with develop instead.

[JAB1305]

I have added the Q/A and tried a version with the actual develop versions in the answer part. Not sure If I am convinced. What do you think?

[s-heppner]

LGTM, thank you very much!