Some ontologies neither contain a date nor data_version

[cthoyt]

What ways could the OBO Foundry help encourage improving the metadata available through the ontologies it lists in a structured format? With respect to ontologies in the OBO Format, it seems important that all should list at least one of the date or data_version field. After ingesting all of the OBO files listed, the I was able to make the following requests directly:

Ontology	Issue
RXNO	https://github.com/rsc-ontologies/rxno/issues/11
EXO	https://github.com/CTDbase/exposure-ontology/issues/15
olatdv	https://github.com/obophenotype/developmental-stage-ontologies/issues/71
pdumdv	https://github.com/obophenotype/developmental-stage-ontologies/issues/71

[matentzn]

@cthoyt Great to see you here as well :). Last year, we have worked on a quite comprehensive set of tools to check all ontologies exactly for issues like that, see http://dashboard.obofoundry.org/. To see the OBO dashboard directly: http://dashboard.obofoundry.org/dashboard/index.html

[matentzn]

There is this column "Versioning" which checks whether an ontology has a version IRI. There are some related GitHub projects as well:

https://github.com/orgs/OBOFoundry/projects/6 (general OBO dashboard problems)

and

https://github.com/orgs/OBOFoundry/projects/5 (OBO-wide ID cleanup, which may interest you also because of your interest in IDs).

[cthoyt]

@matentzn I think this is working on the OWL level, right? I'm more interested in consuming content in OBO because it's already been formatted in a way that's useful for me (there's a lot of interesting stuff in OWL, but it often serves to distract)

[matentzn]

A thing to talk about tomorrow; generally we really need to move away from OBO as a format, because it has some really major shortcomings for our new provenance focussed world (we need axiom annotations without limitations!) - @cmungall has proposed obographs as a sensible json alternative to the OBO format, but we are not yet 100 % there.

The QC is working on the OWL level, but for us, OBO is just another syntax of OWL. Our check for version-iris in OWL would be functionally equivalent to using the obo data-version field.

The only real advantage of OBO - that's why many of our projects cannot move away without pain - is IMO its diffability hackability. I spend a lot of time fixing OBO ontologies by doing simple sed search and replace kind of things - which is hard in OWL. Also, diffs are really easy to read - I tend to look at OBO diffs for pull requests. Other than that though..

[cthoyt]

I'd support that! looking forwards to tomorrow

[nlharris]

What's the status of this?

[matentzn]

I added all of @cthoyt issues on https://github.com/orgs/OBOFoundry/projects/6

I would vote to close this here (because the OBO foundry cannot deal with the individual issues on the ontologies, and we have a suitable recommendation in place on how to deal with it). That ok @cthoyt ?

[cthoyt]

Fine with me. When possible, I've also opened issues on the trackers that go with each repo (though the metadata on obofoundry isn't always available or correct when it is). Is there a preferred place for issues besides here in the future?

[matentzn]

I would say this:

1. There absolutely must be a tracker for every ontology in the obofoundry. I think only one ontology does not have one. We will soon switch CI to fail if no tracker is provided. If you cant find a tracker, make an issue here.
2. If you have a general issue, you can make an issue here.
3. All issues related to individual ontologies should be placed in their own trackers.
4. To track QC related issues across the OBO foundry a bit, you can drop them here: https://github.com/orgs/OBOFoundry/projects/6

Sounds ok?

[cthoyt]

@matentzn we've come a long way since this! anyway the https://github.com/obophenotype/developmental-stage-ontologies issue tracker has been unresponsve in the last few years and I don't think we will be able to fix this