chrismungall
I'm going to address a few themes that have emerged, hopefully this is informative and can generate useful discussion.
Yes, the OBO site is not really very biologist friendly (or really anyone-friendly). It is more geared towards ontology developers, biocurators, and the kind of people who might build tools biologists would use. I would recommend portals such as the OLS (https://www.ebi.ac.uk/ols) for biologists -- but even this site tends to be used by bioinformatics-savvy folks. Domain scientists and users often use ontologies indirectly. For example, the Human Phenotype Ontology is used in many clinical settings for entering patient phenotypes, and subsequently in diagnosis (making use of the logical structure of the ontology). The cell ontology is central to many single-cell seq efforts. And of course the GO is ubiquitous in interpretation of experimental data via enrichment analyses.
One thing we have tried hard to do with the OBO site is ensure we have up to date metadata for all registered ontologies -- including GitHub trackers. So if you have comments on any particular ontology then engaging the developers via their issue tracker is strongly encouraged. And OBO itself has a tracker, as well as a mail list anyone can join.
One thing we have not done a great job of is in giving any kind of order to the many ontologies now listed. It can be overwhelming to someone not familiar with the field. Which ontology should I use ?(or avoid?) Which ontologies integrate well together, and which ones have duplication or incompatibilities? We have a number of new developments in the pipeline that should improve the situation here through the development of a new mid-upper level ontology called OBO Core (https://github.com/OBOFoundry/Experimental-OBO-Core/). We're also encouraging all ontology developers to use standard tooling and best practice which will make interoperation easier (https://github.com/INCATools/ontology-development-kit).
A few people were asking for explainers on ontologies and bio-ontologies in particular. We have a few on our resources page, which is linked from the main site: https://github.com/OBOFoundry/OBOFoundry.github.io/blob/mast... (pull requests welcome!)
Finally, the OBO project itself receives only a tiny amount of short term funding, and most of the ontologies that comprise it have little or no direct funding (exceptions being widely used ones such as GO). A lot of work is community effort. Not saying that to deflect any criticism - constructive criticism is good! Just to provide an explanation of which some things are the way they are.
For a Python library that intends to provide a level of abstraction more appropriate to bioinformatics use cases see https://github.com/biolink/ontobio/
The ontology data model for this is based more on obograph json than on OWL. See https://douroucouli.wordpress.com/2016/10/04/a-developer-fri... and https://douroucouli.wordpress.com/2016/10/04/a-developer-fri...
Of course, it's always possible to use an RDF level library such as rdflib, but this can be low-level for OWL. Even simple bio-ontologies often make frequent use of existential restrictions and axiom annotations.
And of course it's possible to use a python-jvm bridge to access the fully featured java OWL API.
(I am involved in both ontobio and funowl)
For "data" / ABoxes we have had a lot of success with the RL subset. We use this a lot https://github.com/balhoff/arachne
But ultimately it depends on what you want to do. In the life sciences subsets of FOL only buy you so much, and some kind of statistical or probabilistic inference is required. Mostly this is combined with logical inference in crude ad-hoc ways...
I think having an alternative OWL->graph mapping that utilized the features of property graphs would help a lot with using non-RDF graph databases. The RDF layering is sub-optimal.
I wrote about this here: https://douroucouli.wordpress.com/2019/07/11/proposed-strate...
- https://github.com/fastobo/fastobo - https://github.com/fastobo/fastobo-owl
It has been tested heavily on all the ontologies on the obofoundry site.
But I agree in general that working with OWL ontologies (particularly those that use nested OWL constructs) can be difficult to work with in non-JVM languages.