Versioning flag for new ontologies dashboard

[pfabry]

The "versioning" flag in the dashboard checks the following: "The version IRI MUST resolve to an ontology artifact that is associated with the same version identifier as used in the version IRI." cf. Versioning (principle 4)

However, we shouldn't expect a newly submitted ontology to pass this check, as it is by definition not yet integrated in the OBO Foundry. There are, at least, 2 possible actions:

• Remove the versioning flag for the NOR dashboard;
• Modify the versioning flag so that it verifies whether the version IRI versioning is well formed. Ex. OWL: http://purl.obolibrary.org/obo/idspace/YYYY-MM-DD/idspace.owl

[nataled]

A newly-submitted ontology should still have a version even if it doesn't have a Foundry PURL, and there should be a version IRI associated with it. I think it still applies.

[pfabry]

I agree with the need of having a version IRI for all new ontology. However, the problem is more about the need for this version IRI to resolve, which is something that is, to my understanding, managed by the OBO Foundry once an ontology is accepted.

[nataled]

I don't think that is correct. Consider the many (most) ontologies that are not collaborators in the Foundry. Those still must be downloadable from somewhere.

[pfabry]

Just to be sure we are talking about the same thing: by "resolve" I understand that a URL points to a valid resource somewhere. In practical term, when I input an ontology IRI (ex: http://purl.obolibrary.org/obo/obi.owl) in my internet browser navigation bar, I access the ontology file. And the version IRI should point to the same file.

For this to happen, there needs of a configuration file that associate the IRI to an valid internet address. My understanding is that it's the OBO Foundry that take care of this once an ontology is accepted.

This is different form being able to download an ontology where you just need to know the address (generally a GitHub page).

[nataled]

Okay, I see where we differ. Regarding 'resolve', we are indeed talking about the same thing. The difference has to do with the configuration file aspect. You are referring to setting up a PURL--which is indeed done by the Foundry once the ontology is accepted. So, using the same example, currently the version IRI for http://purl.obolibrary.org/obo/obi.owl is:

http://purl.obolibrary.org/obo/obi/2023-07-25/obi.owl

and this file contains the statement:

<owl:versionIRI rdf:resource="http://purl.obolibrary.org/obo/obi/2023-07-25/obi.owl"/>

That version IRI resolves to

https://raw.githubusercontent.com/obi-ontology/obi/v2023-07-25/obi.owl

Thus, the artifact itself (that is, the ontology file) is physically(?) located at that address. So, prior to acceptance, the version IRI in the file should be that address, which is a testable condition. It's just that the PURL isn't used (yet).

Whether or not the versionIRI should be changed after acceptance is something I'm not sure about; maybe needs discussion within the Ops call. Certainly there's no real need to change it other than to maintain consistency with future releases. Are new ontologies being submitted with Foundry PURLs for version IRIs?

[matentzn]

Hmm. What is more important? Resolvability or correct form (if it cant be both)? https://raw.githubusercontent.com/obi-ontology/obi/v2023-07-25/obi.owl is not really an IRI in our sense, its more like a URL.

I kinda tend towards form for the NOR, because you can manually check that the version PURL has a corresponding tag on the GitHub repo. But I am not all sold..

[nataled]

If it can't be both, resolvability is paramount. Without it, there's no way to get the desired version of the ontology! In any case, though shortcuts have been taken here and there, the primary purpose of the dashboard is to evaluate conformance to the principles, and this particular principle requires that the version IRI resolves. So yes, ultimately the IRI must point to a valid URL.