Skip to content

Make FOODON versionIRIs resolvable #1087

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
jamesaoverton merged 1 commit into from
Feb 3, 2026
+2 −0
Merged

Make FOODON versionIRIs resolvable #1087

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions config/foodon.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -17,3 +17,5 @@ entries:
- prefix: /imports/
replacement: https://raw.githubusercontent.com/FoodOntology/foodon/master/imports/

- prefix: /releases/
replacement: https://raw.githubusercontent.com/FoodOntology/foodon/v
Copy link
Copy Markdown
Contributor

@matentzn matentzn Feb 2, 2026

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
Copy Markdown
Contributor Author

@allenbaron allenbaron Feb 2, 2026

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
Copy Markdown

@ddooley ddooley Feb 3, 2026

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
Copy Markdown

@ddooley ddooley Feb 3, 2026

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
Copy Markdown
Contributor Author

@allenbaron allenbaron Feb 3, 2026

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

@matentzn matentzn Feb 4, 2026

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
Copy Markdown
Member

@jamesaoverton jamesaoverton Feb 4, 2026

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
Copy Markdown
Contributor Author

@allenbaron allenbaron Feb 4, 2026 •
edited
Loading

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

Loading
⚡