Related to Principle #3 URIs: resolvability of term IRIs

[nataled]

P3 currently requires ("MUST") that ontology-as-a-whole IRIs (like http://purl.obolibrary.org/obo/ont.owl) resolve to an artifact (that is, pulls up the ontology file). The same is not true for individual term IRIs. Guidance on the use of term IRIs can be found instead in the ID policy) document referenced by P3. There, it is stated "The URIs should resolve to useful information about a term". Thus, our recommendation up to now has fallen short of a hard requirement that IRIs resolve to a page. Our current wording for term IRIs are consistent with the definition of a 'Web resource' given by w3c:

...
Web Resource
A Resource that MUST be identified by an IRI, as described in the Web Architecture [webarch]. Web Resources MAY be dereferencable via their IRI.
...

Thus, based on strict definition of an IRI, resolving (dereferencing) is not a required part of their use, and our documentation reflects that. However, in the time since our guidelines were put in place, FAIR best practices were developed. One could argue that FAIR practices imply that the ability to resolve an IRI should be elevated from our SHOULD (which is already stronger than w3c's MAY) to MUST.

This issue intends to open a discussion on whether or not we wish to change this policy. If so, the EWG will revise the wording accordingly.

[pfabry]

My understanding is that IRI resolution is a service provided by the OBO Foundry for accepted ontologies through this GitHub repository. There are two types of resolution:

• Ontology-level resolution – Resolving the entire ontology/ontology version, typically linking to the corresponding file on GitHub.
• Component-level resolution – Resolving individual ontology elements (e.g., classes, object properties), which typically links to the corresponding Ontobee page.

As I understand it, an ID space cannot be requested before an ontology has been submitted. Consequently, I find Principle 3 somewhat paradoxical. Accordingly, an ontology must both follow the OBO Foundry IRI format and be resolvable to be accepted. However, for an IRI in this format to be resolvable, the ontology must already be accepted.

This raises several questions:

• Should the OBO Foundry allow ID space requests before an ontology is submitted, despite the risk of spamming the service?
• Should a submitted ontology with pre-existing resolvable IRIs in a non-OBO format replace them with OBO-format IRIs upon acceptance?
• If candidate ontologies are required to resolve upon submission, is it still necessary for the OBO Foundry to provide this service?

[nataled]

@pfabry we already allow certain exceptions for new ontologies. The ability for individual terms to resolve will just be another that will be added to the exceptions list. Full compliance with principles is something we require of already-accepted ontologies. Thus, switching from SHOULD to MUST for term IRIs resolving will have no impact on newly submitted ontologies.

[pfabry]

@pfabry Full compliance with principles is something we require of already-accepted ontologies.

Thanks for the clarification. In this case, perhaps the introduction to the principles should be revised to clarify that only accepted ontologies are expected to fully comply with the principles. Right now it says:

These principles are intended as normative for OBO Foundry ontologies, and ontologies submitted for review will be evaluated according to them. [...] Where we use capitalized words such as “MUST”, and “SHOULD”, they will be interpreted according to RFC 2119: Key words for use in RFCs to Indicate Requirement Levels when the principles are applied during reviews of ontologies for inclusion in the Foundry.

This seems to imply that principles must be respected for an ontology to be accepted, rather than all accepted ontologies follow these principles.

@pfabry Thus, switching from SHOULD to MUST for term IRIs resolving will have no impact on newly submitted ontologies.

What bothers me about the current wording is that, unlike all the other principles, which outline actions the submitter is required to take for its ontology to be accepted, the "resolving" of an OBO PURL IRI is something provided by the OBO Foundry and cannot be fulfilled by the submitter. Therefore, perhaps "SHALL" would be more appropriate than "MUST."

[pfabry]

Returning to the question, we can break Principle 3 into two parts:

Ontology IRIs MUST follow the OBO PURL format.
Ontology IRIs following the OBO PURL format SHALL resolve.

A key question, in my view, is how to handle submitted ontologies that resolve independently using an IRI format different from OBO’s. The issue #2667 discussion addresses this, and I agree that a non-OBO IRI must, at a minimum, have a sustainability plan. But is that enough? Or should submitters be required to modify their ontology’s IRIs to conform to the OBO PURL format?

[nataled]

Submitters are already required to use OBO PURL format. What is at issue here is whether or not those PURLs are required to resolve. Here's what's being asked:

When an ontology term IRI (an OBO PURL) is entered as an address on a web browser or clicked as a link, the Foundry PURL resolver kicks in and redirects to the ultimate destination address. The question being addressed in this issue is whether or not that destination address must be a web page that actually works. That's it. The alternative is that we follow w3c recommendation, which states that IRIs do not need to land on a page and are, by implication, just identifiers.

As you mentioned before, no PURL will resolve until the ontology has been accepted. I think your concerns can be addressed by specifying that:

1. Ontology term IRIs must use well-formed OBO PURLs (http://purl.obolibrary.org/obo/TERM_ID, where TERM_ID is to be understood as Ontology-IDspace-in-caps + Underscore + local-identifier) as opposed to, for example, http://purl.obolibrary.org/TERM_ID (that is, missing '/obo') or http://purl.obofoundry.org/obo/TERM_ID (that is, using the wrong domain)
2. The Foundry PURL handler will take care of redirections, pointing to the PURL destination given by the ontology provider
3. These destinations either MUST or SHOULD or MAY or SHALL or whatever-else-proposed resolve to a web page.