Closed kltm closed 6 months ago
@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: 1) have minerva able to identify / skip these "constructions". This would be preferred as graphstore creation takes time, but... 2) 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.
@kltm implementation of 1 in #542. Add --check-graph-type
to your command line.
Recently, we discovered that minerva will bomb out when trying to QC the entire store. To reproduce:
master
wget http://skyhook.berkeleybop.org/blazegraph-go-lego-reacto-neo.jnl.gz
gunzip blazegraph-go-lego-reacto-neo.jnl.gz
wget http://skyhook.berkeleybop.org/snapshot/products/blazegraph/blazegraph-internal.jnl.gz
gunzip blazegraph-internal.jnl.gz
reset && 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:
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.
We need to either