Make FOODON versionIRIs resolvable#1087
Conversation
| replacement: https://raw.githubusercontent.com/FoodOntology/foodon/master/imports/ | ||
|
|
||
| - prefix: /releases/ | ||
| replacement: https://raw.githubusercontent.com/FoodOntology/foodon/v No newline at end of file |
There was a problem hiding this comment.
I think you will need to talk to @ddooley:
To make FOODON URLs (http://purl.obolibrary.org/obo/foodon/releases/2025-12-30/foodon.owl) resolvable you will have to:
- Ensure that for every release, there is a tag released (the lastest release, for example, does not have a tag
- the tag must be
v2025-12-30, NOT2025-12-30.
Else this intervention here wont work. Its still technically correct of course, but..
There was a problem hiding this comment.
Ha... I only looked at the 2025-07-31 release initially which has the v (but the wrong release date), so I assumed the others did too. 😅
There was a problem hiding this comment.
But if tag is say "v2025-12-30" - which I'm now trying on "http://purl.obolibrary.org/obo/foodon/releases/v2025-07-31/foodon.owl" , then the above replacement URL should NOT have a "v" at end right? So tag just gets merged in to create: http://purl.obolibrary.org/obo/foodon/releases/v2025-07-31/foodon.owl . At moment prefix yeilds "http://purl.obolibrary.org/obo/foodon/releases/vv2025-07-31/foodon.owl"
There was a problem hiding this comment.
Or is it that a release URL, from OBO Foundry perspective just mentions date, i.e. releases/2025-07-31/foodon.owl, even though tag over on Github side always has form of e.g. https://github.com/FoodOntology/foodon/releases/tag/v2025-07-31 ????
There was a problem hiding this comment.
Or is it that a release URL, from OBO Foundry perspective just mentions date, i.e. releases/2025-07-31/foodon.owl, even though tag over on Github side always has form of e.g. https://github.com/FoodOntology/foodon/releases/tag/v2025-07-31 ????
Yes, this is correct.
You can find the expected pattern for versionIRIs inside ontology files at https://obofoundry.org/principles/fp-004-versioning.html#implementation. The extra v in the GitHub release tag, which is NOT in the ontology versionIRI, is handled by the prefix/replacement pattern in foodon's config file here, which is what I added.
Nico stated that on GitHub (not in the ontology file):
2. the tag must be
v2025-12-30, NOT2025-12-30.
I don't know why that is. Technically, I think you could get by without the v in GitHub releases by simply removing the v from the replacement part of the PURL redirect prefix rule I added, but apparently you're not supposed to do that.
There was a problem hiding this comment.
@allenbaron now that you are calling me out on this, I tried to remember how this habit emerged but I simply cant!
https://chatgpt.com/share/6982fdd6-7aa0-8004-b12a-036bcb0150cf
There was a problem hiding this comment.
It's just convention. OBO PURLs have always used dates (no v) while GitHub projects have used the v to tag releases (usually v1.2.3). When we started pointing PURLs to GitHub releases, this is where we ended up.
There was a problem hiding this comment.
I didn't mean to call anyone out. I always assumed it was inherited from software engineering, as James suggested. I do think ChatGPT makes some good points for including the v.
It seems FOODON hasn't really had the v until recently, which makes me wonder if it should be required or not. I opened a new issue on the OBO Foundry repo regarding requirements/principles/standards for GitHub repos (OBOFoundry/OBOFoundry.github.io#2840).
|
Thanks for the help here, I will get FoodOn lined up to work this way. Frankly as evidenced here I had always found it rather confusing about what the correct URL is for past versions given a published FoodOn GitHub release. |
Ping me on slack if you need help. In the meantime, this PR here is ok to merge, its technically correct, it just wont work because of the FOODON side and its not making the current situation any worse. |
Currently FOODON is not resolvable using versionIRIs. This adds a
- prefixredirect to make them resolvable.Resolves FoodOntology/foodon#361.