QC of new Ubergraph builds

[balhoff]

What kind of QC should we have in the Ubergraph build? Right now there is very little. If the build completes, and the database is about the expected size, I deploy it. I save the previous database file so that we can easily roll back if a problem is noted.

I can imagine adding some queries that are run against the new build and against the live endpoint, checking that counts haven't decreased.

@dosumis @matentzn any ideas?

[matentzn]

I would suggest this:

• Create a directory with positive and negative sparql patterns
• run through all of them on ingest time
• if we need anything specific (when we see something wrong) we just add them
• A typical thing to look for would be:
  • a class should either be deprecated, from BFO, the target of an IAO:0000700 annotation or have a parent (prevents floaters due to erroneous treatment of base files)
  • any ontology should have at least 100 subclass of axioms