Skip to content

Make FOODON versionIRIs resolvable#1087

Merged
jamesaoverton merged 1 commit intoOBOFoundry:masterfrom
allenbaron:foodon
Feb 3, 2026
Merged

Make FOODON versionIRIs resolvable#1087
jamesaoverton merged 1 commit intoOBOFoundry:masterfrom
allenbaron:foodon

Conversation

@allenbaron
Copy link
Contributor

Currently FOODON is not resolvable using versionIRIs. This adds a - prefix redirect to make them resolvable.

Resolves FoodOntology/foodon#361.

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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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:

  1. Ensure that for every release, there is a tag released (the lastest release, for example, does not have a tag
  2. the tag must be v2025-12-30, NOT 2025-12-30.

Else this intervention here wont work. Its still technically correct of course, but..

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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. 😅

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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"

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 ????

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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, NOT 2025-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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

@allenbaron allenbaron Feb 4, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

@ddooley
Copy link

ddooley commented Feb 2, 2026

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.

@matentzn
Copy link
Contributor

matentzn commented Feb 2, 2026

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.

@jamesaoverton jamesaoverton merged commit d2f20d2 into OBOFoundry:master Feb 3, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

version IRIs don't resolve & other release issues

4 participants