In some cases, minerva exits early exception when performing QC on graphstore
kltm opened this issue · 3 comments
Recently, we discovered that minerva will bomb out when trying to QC the entire store. To reproduce:
- checkout minerva
master - enter repo root
wget http://skyhook.berkeleybop.org/blazegraph-go-lego-reacto-neo.jnl.gzgunzip blazegraph-go-lego-reacto-neo.jnl.gzwget http://skyhook.berkeleybop.org/snapshot/products/blazegraph/blazegraph-internal.jnl.gzgunzip blazegraph-internal.jnl.gzreset && MINERVA_CLI_MEMORY=12G ./minerva-cli/bin/minerva-cli.sh --validate-go-cams --shex -i blazegraph-internal.jnl -r /tmp/ --ontojournal blazegraph-go-lego-reacto-neo.jnl
Errors are like:
08:49:30 2024-05-08 08:49:30,161 INFO (org.geneontology.minerva.cli.CommandLineInterface:1104) preparing model stats...
08:49:30 java.lang.IllegalStateException: Optional.get() cannot be called on an absent value
08:49:30 at com.google.common.base.Absent.get(Absent.java:47)
08:49:30 at org.geneontology.minerva.model.GoCamModel.<init>(GoCamModel.java:49)
08:49:30 at org.geneontology.minerva.cli.CommandLineInterface.validateGoCams(CommandLineInterface.java:1107)
08:49:30 at org.geneontology.minerva.cli.CommandLineInterface.main(CommandLineInterface.java:406)
08:49:30 2024-05-08 08:49:30,182 INFO (org.geneontology.minerva.cli.CommandLineInterface:1266) done with validation
Trying to patch some of these up with exception handling didn't really work as it's a more fundamental issue that the models are not always containing the expected identifier. E.g.
2024-05-08 14:42:15,902 INFO (org.geneontology.minerva.json.InferenceProvider:82) Done with shex validation. model is conformant is: false
java.lang.NullPointerException
at org.geneontology.minerva.validation.ShexValidationReport.getAsTab(ShexValidationReport.java:69)
at org.geneontology.minerva.cli.CommandLineInterface.validateGoCams(CommandLineInterface.java:1204)
at org.geneontology.minerva.cli.CommandLineInterface.main(CommandLineInterface.java:406)
2024-05-08 14:42:16,582 INFO (org.geneontology.minerva.cli.CommandLineInterface:1269) done with validation
We need to either
- fix the core functionality to not expect this
- add this info to the models
@kltm now I think I see what's happening. The validate-go-cams command does not expect to be checking models in the graphstore. The graphstore is organized differently from the internal Minerva database (where every graph is a GO-CAM source model). The graph store has GO-CAM source models, GO-CAM inferences graphs, GAF-CAM graphs, an ontology graph, etc. Is this a new strategy, or was this being done before?
@balhoff Well, good news / bad news.
This was never done before, but we were thinking that it would likely work, as it's the same thing but more. But now that you mention it, we are adding a lot of weird stuff during construction of the "final" graph store that may be problematic.
So, the solutions would then be:
- have minerva able to identify / skip these "constructions". This would be preferred as graphstore creation takes time, but...
- we could create a "raw" graphstore that is just the models and no other additions, like noctua expects
While 2 is totally doable, I'd be curious as to the difficulty of 1.