Versioning doesn't match ChEBI

[cthoyt]

I think it would be valuable to have this match the versioning of ChEBI (which is using sequential version numbers) instead of introducing an arbitrary date versioning system

[matentzn]

This is going to put a bit of a burden on the maintainers, but you are probably right.

[cthoyt]

Based on a similar question today https://obo-communitygroup.slack.com/archives/C01BTR3E8CU/p1662209700361059?thread_ts=1662209122.517419&cid=C01BTR3E8CU it looks like having a reusable tool that can get the version out of an arbitrary ontology IRI would be nice

[matentzn]

A two step process is to convert the ontology to json, then us jq. You can never be really sure what serialisation the ontology is stored in otherwise. Or just use sparql?

[cthoyt]

Sounds good enough for this

Some notes:

robot convert -I http://purl.obolibrary.org/obo/chebi.owl -o chebi.json
cat chebi.json | jq ".graphs[0].meta.basicPropertyValues

[cmungall]

I can foresee a frequent need to get a new slim in between CHEBI releases. I'm assuming we in fact want to automate this repo and push releases after PRs on the txt file.

This would necessitate either making the slim versions patch releases on the chebi major/minor system, which doesn't sit so well. Or treating the slim as a separate obo product and maintaining a triple that points back to the source chebi release.

[matentzn]

We will go for the latter, documenting the CHEBI version a slim was sourced from I think. I need to make frequent re releases, sometimes more than one per week.

It's a pity that GH actions can't handle CHEBI at all.I would feel better with a SLME module over a graph module but if we obtain for a more OBO-esque upper level anyways, we can explore options.