Hi, thanks for reporting this. So the java manchester OWLAPI might have problems reading the latest foodon github release file version, but I'd be surprised if it couldn't read the github root's foodon.owl . Did you try that?

I am working on a new release shortly that validates byway of the "apache jena riot" command. If above doesn't work perhaps this will. I should have it up in a day or so.

Thank you for your quick response! I did try using a previous version of foodon, but that didn't work. It still doesn't work (same error).

Can you use Apache jena riot to validate? That tool has ability to validate and identify in one swoop any owl file syntax issues via:

riot --validate [path to]/foodon.owl

If using some other tool, you have to turn on verbose error reporting in your parser if possible to have a chance at diagnosing which part of owl file is triggering this. The OWL API "Exception in thread "main" " isn't enough to go on, and usually its the verbose log line before that hints at what phrase or line couldn't be parsed.

Right now with master branch foodon.owl I'm not getting any errors. I just uploaded a version of it with a few tweaks so I'd be dumfounded if you weren't able to load that.

Thanks for your reply, @ddooley. I can confirm that the current foodon.owl in the master branch, i.e., this file, seems to validate with Jena riot,

sramsey$ export JVM_ARGS="-Djdk.xml.totalEntitySizeLimit=0 -Djdk.xml.entityExpansionLimit=0"
sramsey$ riot --validate foodon.owl
WARNING: java.io.tmpdir directory does not exist

(assuming that riot follows the UNIX philosophy of no output means it ran successfully; I am a first-time user of this tool).

I suspect this issue may be an issue with our pipeline's attempting to convert foodon.owl to obograph JSON. Specifically, in our workflow, we are trying to do:

./owltools foodon.owl -o -f json foodon.json

and this is causing errors, as shown here:

sramsey$ ./owltools foodon.owl -o -f json foodon.json
Exception in thread "main" java.lang.ClassCastException: class uk.ac.manchester.cs.owl.owlapi.OWLObjectInverseOfImpl cannot be cast to class org.semanticweb.owlapi.model.OWLObjectProperty (uk.ac.manchester.cs.owl.owlapi.OWLObjectInverseOfImpl and org.semanticweb.owlapi.model.OWLObjectProperty are in unnamed module of loader 'app')
	at org.geneontology.obographs.owlapi.FromOwl.getDRBuilder(FromOwl.java:597)
	at org.geneontology.obographs.owlapi.FromOwl.generateGraph(FromOwl.java:212)
	at org.geneontology.obographs.owlapi.FromOwl.generateGraphDocument(FromOwl.java:112)
	at owltools.io.ParserWrapper.saveOWL(ParserWrapper.java:264)
	at owltools.io.ParserWrapper.saveOWL(ParserWrapper.java:209)
	at owltools.cli.CommandRunner.runSingleIteration(CommandRunner.java:3712)
	at owltools.cli.CommandRunnerBase.run(CommandRunnerBase.java:76)
	at owltools.cli.CommandRunnerBase.run(CommandRunnerBase.java:68)
	at owltools.cli.CommandLineInterface.main(CommandLineInterface.java:12)

Similarly if I try to do the conversion using robot, I get an error:

/robot convert --input foodon.owl --output foodon.json
OBO GRAPH ERROR Could not convert ontology to OBO Graph (see https://github.com/geneontology/obographs)
For details see: http://robot.obolibrary.org/errors#obo-graph-error
Use the -vvv option to show the stack trace.
Use the --help option to see usage information.

So there may just be an issue that foodon.owl is using an OWL feature that is not supported by obograph JSON. So I think we may be able to use the technique described on this page to work around it, using robot remove. In the short term, we can use foodon-base.owl which both owltools and robot can convert to obograph JSON with no issues.

Ahh. I run your robot convert command with -vvv and it indicates it can load the ontology, but not save it. We could check with the robot folks about that. Indeed, it is not indicating why it can't save in obo format, but good news is it seems to pass rdf validation such that it can load.

I see now, perhaps there are some terms with two definitions by accident etc. that would cause error on obo save. We will be implementing ODK soon on the foodon site that should bring some of the obo format specific error reporting into our build pipeline so we can solve that. In the meantime I'd appreciate if you could let us know if your "robot remove" strategy works.

I'm also seeing this issue with FOODON v2024-02-21 - it does not appear to convert to obojson with ROBOT, and the usual robot remove strategies (those described in the robot docs) do not help.

Edit: spoke too soon. This works:

$ robot -vvv remove --input foodon_relaxed.owl --exclude-term IAO:0000115 --output foodon.json