Background: https://www.ebi.ac.uk/panda/jira/browse/GO-307

 * limb.owl illustrates the general issue
 * limb_gci.owl: Additiona of GCIs
 * limb_gci_qc.owl: Additiona of GCIs, plus query class

The correct inferences can be seen in limb_gci_qc - switch on Elk and
look in the inferred hierarchy under 'part of limb development'. You
can see the correct inferences, entailed by GCIs of the form

  (development and has-outpu some P)
    SubClassOf
  part_of some (development and has-outpu some W)

Derived for every axiom P SubClassOf part_of W

There are a few issues with this approach:

Issue: Invisible inferences

As can be seen via the query classes, the correct inferences are
retrieved. However, these inferences are essentially invisible unless
a query class is materialized. We would be unlikely to do this in GO,
so this would have to be some kind of procedure that runs regularly,
and hides the query classes. Awk-ward.

We have an extended reasoner interface in OWLTools, and an
implementation called 'materializing expression reasoner' (see the
Makefile for generating a report). However, this reasoner interface
is not supported by Protege.

Issue: GCI Synchrony

We need a process for keeping GCIs in sync with upstream
ontology. This is fairly easy when the upstream is external, as we
just regenerate the GCIs when we regenerate the import (TG will have
to regenerate every time however). However, when the upstream is
within GO this is harder. For example, if the derived class is in the
assembly hierarch, and the upstream is a cellular component, then
chaging the CC partonomy will lead to stale/incorrect inferences until
the CGIs for CC are regenerated.

This is doable - e.g. some kind of process running within Protege....

...But if we start going down this route, why not just calculate the
inferences outright