Principle #4 versioning - automated validation

[beckyjackson]

FP 4 - Versioning

Automated checks:

1. The ontology must have a version IRI
2. The version IRI must resolve
3. The versioning should follow the date system
4. The ontology should have version info annotation

Mechanisms:

We can extract the version IRI from the ontology to ensure that it is there. If it is missing, this check fails. We can make sure the version IRI resolves (HTTP status < 400).

The principle recommends that versioning follows the date system, though it is not required. We can look for the pattern:

http://purl.obolibrary.org/obo/idspace/YYYY-MM-DD/idspace.(owl|obo)

or

http://purl.obolibrary.org/obo/idspace/releases/YYYY-MM-DD/idspace.(owl|obo)

It is also recommended to have an owl:versionInfo tag, though this is only applicable to OWL files. Perhaps if this is missing, it should only be an info message.

[beckyjackson]

If the version IRI does not follow the date system, it will get a warning. It is not an error.

Additional versioning check:
We want to make sure that things that exist in old versions are never dropped. Every ID ever created and released is maintained, even if obsolete. This would require looking at the previous version of the ontology and comparing it to the new one.

The new release should have a different version tag than the previous one. A released file should not be modified and not have a different version IRI.

[beckyjackson]

Checking if old IDs are dropped should be a separate principle. This principle should be about resolvable, dated versions- @cmungall

[allysonlister]

Hi everyone,

SWO has always used release numbers (e.g. 1.7) rather than release dates. As I update the versionInfo and versionIRI to be compliant with the next release, please can you confirm that maintaining these release numbers will not result in an error in the OBO Dashboard?

Specifically, this test should pass for SWO if I update the versionIRI from
http://www.ebi.ac.uk/swo/swo.owl/1.8
to
http://purl.obolibrary.org/obo/swo/1.8/swo.owl
?

(Apologies if this is the wrong ticket - please redirect me if so).

Thanks!

[allysonlister]

Good evening everyone - just a follow-up on my last question from a few months ago - how would retaining a version number rather than a version date affect how the dashboard implements http://obofoundry.org/principles/checks/fp_016, which seems to expect a date value?

Thanks!

[matentzn]

Hey @allysonlister, sorry I missed this!

According to our rules: http://www.obofoundry.org/principles/fp-004-versioning.html
The version iri should be using a date, but yes, the precise way the principle is framed is using the SHOULD -> not sure how this reflects on the check. The advantage of a date based version iri is that it has semantics: you know exactly how old the release is. This way, the user knows when the ontology was last updated etc.. Is there any specific reason you want to keep using the release version instead of the date for the version IRI? Sorry to answer question with question - the true answer is that I don't know the answer :D

[nataled]

Clarification: the principle states that versions be either of date format (specifically YYYY-MM-DD) OR use version number (such as NN.n), but that the IRIs for each version be a dated PURL. Thus, this validation should actually check that there is a functioning versioned PURL. At the moment this isn't done; instead the check is for the version IRI in the ontology file. Ontologies using the major/minor system with an IRI based on that system will currently fail this check, even if they have a date-based PURL.

[allysonlister]

Is there any specific reason you want to keep using the release version instead of the date for the version IRI?

Habit, mostly. Certainly something we could look at changing :-) Thanks!