Document expectations about TBox axioms in ABox

[cmungall]

I had assumed that a model only contained ABox axioms.

However, it seems that many contain TBox axioms - sometimes label declarations, sometimes just class declarations

https://github.com/geneontology/noctua-models/blob/master/models/586fc17a00000381.ttl

• label axioms for CL, GO
• declaration axioms for everything

https://github.com/geneontology/noctua-models/blob/master/models/59dc728000000555.ttl

• label axioms for ZFA genes
• declarations for ZFA and UBERON, not GO

Based on the current state I believe the formal documentation should say

• clients MUST obtain TBox axioms from TBox graph, not model graph
• minerva SHOULD NOT place TBox axioms in ABox graph, but in some cases these may leak through, due to owlapi weirdness

[balhoff]

I think the gene product classes get declared in the model because the terms are not in the Tbox (e.g. because of geneontology/neo#17). However I'm not clear on the pathway by which the label annotations creep in (need to think about it further).

[cmungall]

Minerva is able to query solr to obtain labels and to inject these, I assume they got in this way.

[goodb]

I noticed this property hanging on this ZFIN class declared within 59dc728000000555
http://geneontology.org/lego/derived "true"^^http://www.w3.org/2001/XMLSchema#string ;

What does this property mean? Maybe this is a clue about where the class defs are leaking in - e.g. if Minerva is inferring them and needs to add them into the model to create required axioms.

[goodb]

Maybe a tangent from debugging how these came in through the editor/minerva path, but when generating GO-CAM models from other sources, I have hit cases where the required classes either do not exist in neo or just don't exist anywhere at all (e.g. complexes). So far I've gotten around this either by creating them and adding them into the go-cam model owl file or just defaulting to an uninformative upper level class (e.g. macromolecular complex). The Noctua (v1) editor appears to accept such additional classes if they are present in the models that it loads.

This points to the use case of editors/importers needing a mechanism to propose new classes to be added to the global tbox (perhaps a v2 feature). Also a question - are OWL models that follow the GO-CAM modeling practices but contain additional classes or refer to classes outside of the GOC TBox considered 'valid'? Should they be allowed into GOC GO-CAM collections? Should software that consumes go-cams try to work with them (the way Noctua is doing now) ?

[cmungall]

This points to the use case of editors/importers needing a mechanism to propose new classes to be added to the global tbox (perhaps a v2 feature)
+1

I think we should impose some SHOULDs. I see the use case for inject TBox axioms info but there are problems here with axioms getting out of sync.

[balhoff]

@goodb I think you're right about the lego:derived property being the answer here. Minerva has a ModelWriterHelper and a ModelReaderHelper. These are run just before writing and just after reading from the database. They appear to inject certain annotations and class declarations. But these are stripped as the file is loaded.

It's not clear that this serves any purpose at this point. Previously it was used to add the embedded JSON-blob of the model. I removed that a while back and perhaps could have removed the rest of this as well.