Do not give a version IRI to bridge files. #3434
Conversation
The current process that generates the cross-species bridges automatically inserts into them a Version IRI that includes the date of the day (e.g. <http://purl.obolibrary.org/obo/uberon/releases/2024-11-25/bridge/uberon-bridge-to-fbbt.owl>). I think that Version IRI is of very dubious usefulness. * Many of our components do _not_ have a Version IRI. * The bridges are primarily intended for Uberon's own purposes (for building Composite-Metazoan), even though they _are_ published and available to anyone wants to use them. * The date in the inserted Version IRI does not necessarily match the date of the Uberon release the generated bridges will be a part of, since the bridges may not be re-generated on the same day than a release will me made. In fact the only thing those Version IRIs do is pollute the diff of every "refresh external resources" PR (such as the last one: #3433). So I hereby propose to get rid of them, so that every bridge has only a Ontology IRI (e.g. <http://purl.obolibrary.org/obo/uberon/bridge/uberon-bridge-to-fbbt.owl> but _no_ Version IRI.
There was a problem hiding this comment.
I think that Version IRI is of very dubious usefulness.
Examining arguments a bit here:
Many of our components do not have a Version IRI.
All by itself not a great reason, as we would ideally want all components to have a version iri.
The bridges are primarily intended for Uberon's own purposes (for building Composite-Metazoan), even though they are published and available to anyone wants to use them.
I know a few outside places the bridges are used for many years, like uPheno, ubergraph and Monarch (and perhaps bgee). So I would weight this argument a bit lower.
The date in the inserted Version IRI does not necessarily match the date of the Uberon release the generated bridges will be a part of, since the bridges may not be re-generated on the same day than a release will be made.
Shouldnt we just push for this?
If your concern is lack of consistency, I personally believe we should tag all components rather than removing the date from some.
I think knowing when a file was generated is useful information so I am asking for a more convincing argument :P Sorry.
No problem. But then I leave you amend the release pipeline to amend the version IRI in all bridge files to ensure that it is always correct (and while you are at it, adding a version IRI to all other components), since you’re the one thinking it is useful. |
|
Not immediately agreeing with a change does not equate volunteering for solving the issue, but I might consider fixing it if you think its a high priority issue! |
|
We’ve had version-less components for years, so you tell me: is it a high-priority to ensure that our components have a version IRI? |
|
I am not one to insist on any sentiments. You know I trust your judgement. My intuition was: it is useful, even if incomplete, so I didn't see the reason to change; if you think consistency beats that argument you are probably right, and I shall approve on the grounds that I defer to your better judgment! |
The problem is not that it is incomplete, it is that the bridge version IRIs are potentially wrong. Whenever the Uberon release happens on a different day than the day the bridges were last re-generated, the bridges end up with a version IRI that has a different date than the date of the Uberon release itself. This happened for example last August. I posit that bogus version IRIs are worse than no version IRIs at all. The fact that not all components have a version IRI (which is what you mean when you say “incomplete”, I presume) is another issue, one that you now think is important and therefore you want a solution to solve both the potentially incorrect version IRIs in the components that do have one, and the lack of a version IRI in other components. That’s sensible and I have no objection to that, but a solution to both problems would be more complicated than just removing the bogus version IRI in the bridges (this PR), and I have no time for that now. |
The current process that generates the cross-species bridges automatically inserts into them a Version IRI that includes the date of the day (e.g.
http://purl.obolibrary.org/obo/uberon/releases/2024-11-25/bridge/uberon-bridge-to-fbbt.owl).
I think that Version IRI is of very dubious usefulness.
Many of our components do not have a Version IRI.
The bridges are primarily intended for Uberon's own purposes (for building Composite-Metazoan), even though they are published and available to anyone wants to use them.
The date in the inserted Version IRI does not necessarily match the date of the Uberon release the generated bridges will be a part of, since the bridges may not be re-generated on the same day than a release will be made.
The last point notably means that the Version IRI may not be resolvable, if the Uberon release happened on a different day than the day the bridges were generated. This happened for example for the 2024-08-07 release, whose bridges have a version IRI dated from 2024-08-06 (e.g. http://purl.obolibrary.org/obo/uberon/releases/2024-08-06/bridge/uberon-bridge-to-fbbt.owl).
In fact the only thing those Version IRIs do is pollute the diff of every "refresh external resources" PR (such as the last one: #3433).
So I hereby propose to get rid of them, so that every bridge has only a Ontology IRI (e.g.
http://purl.obolibrary.org/obo/uberon/bridge/uberon-bridge-to-fbbt.owl) but no Version IRI.