ttl oddities

[cmungall]

https://raw.githubusercontent.com/geneontology/noctua-models/master/models/591f58ab00000003.ttl

1. The triple <http://model.geneontology.org/591f58ab00000003> a <http://www.w3.org/2002/07/owl#Ontology> is there twice
2. Classes are injected into the abox
3. oio:id injected everywhere

Hypothesis: some kind of invalid triple was added onto http://model.geneontology.org/591f58ab00000003, causing the owlapi to inadvertently pun. The imports is on the punned IRI, which renders it invisible to the owlapi. this in turn lead to existing class declarations leaking in.... I dunno.

@balhoff any ideas?

This model was created 2 days ago.

We should at least test adding some new models, make sure nothing odd has happened

[cmungall]

my hypothesis is not quite correct, the OWLAPI is reading the imports.. but it doesn't rule out that it was in an odd state pre-save.

[cmungall]

Hmm, direct output from OWLAPI via minerva:

http://noctua.berkeleybop.org/download/gomodel:591f58ab00000003/owl

• The injected oio:id is present on the Ontology nowhere else
• We have class declarations but the label tbox axioms are gone (good)
• there is only one owl:Ontology triple, as expected

[balhoff]

I can comment on one part so far: the <...> a owl:Ontology triple is seen twice because I had put in a hack to workaround the RDF parsing bug in OWL API. I manually injected the owl:Ontology declaration ahead of any other triples so that ontology annotations would be correctly parsed. This can probably be removed now.

[balhoff]

I don't think it's just this model. I looked at a few others and see oio:id and rdfs:label on gene product classes, but not on GO terms.

[balhoff]

Current guess: this stems from adding classes to the model that aren't already in the tbox. This will happen for every gene product that has the IRI mismatch described here. In this model you can see the oboInOwl:id isn't getting stored for the PRO IRIs, which have OBO PURLs that match what's in NEO.

[balhoff]

But why is the OWL API direct ttl different?

[balhoff]

The cause of this behavior is ModelWriterHelper and ModelReaderHelper: 843e5d6

It seems like this was mainly for the benefit of the formerly embedded JSON blob. I've disabled this now in a branch that is being tested.