In the recent import of a slice of Reactome (#3), many models failed the Shex. Looking into this problem more closely suggests that there is an issue with the way cellular components are being handled in the Reactome models.

Here is an example of a Shex violation from one of the newly imported models:
R-HSA-8850843.ttl Phosphate bond hydrolysis by NTPDase proteins - imported from: Reactome http://model.geneontology.org/R-HSA-8850843 gomodel:R-HSA-8851234 [GO:0017111] BFO:0000066 [obo:go/shapes/AnatomicalEntity] gomodel:reaction_R-HSA-8851234_location_lociGO_0000139 [GO:0000139]

If I am interpreting this correctly, it is saying that there is a violation because a molrcular functions needs to occur in an anatomical entitiy, but GO:0000139 (Golgi membrane), is not an anatomical entity.

Last week when we looked at this closer we confirmed that models made by curators are passing the Shex. For example:
http://noctua.geneontology.org/editor/graph/gomodel:60ff660000001331 has a molecular function occurring in the cytosol, but running the reasoner does not violate Shex.

However, Reactome models that were imported during the last 'official' import are now violating Shex:
in http://noctua.geneontology.org/editor/graph/gomodel:R-HSA-196741, the only changes we have made to the model are in the layout. However, if you look at individuals of molecular functions that are occurring in some cellular component, they are violating the Shex, Edit Instance: gomodel:R-HSA-5223313 and Edit Instance: gomodel:R-HSA-5693319.

It seems like something has gone awry with the the Shex validation of molecular functions occurring in cellular components since the initial import since I think at that time, there were very few Shex violations. Here is the blurb about the violation:

[
{
"shape": "obo:go/shapes/TransporterActivity",
"constraints": [
{
"object": "gomodel:reaction_R-HSA-5223313_location_lociGO_0005765",
"property": "BFO:0000066",
"node_types": [
"GO:0140359"
],
"object_types": [
"GO:0005765"
],
"nobjects": 0,
"matched_range_shapes": [

        ],
        "intended-range-shapes": [
           "obo:go/shapes/AnatomicalEntity"
        ]
     }
  ]

}
]

Removing the information about where the molecular function occurs results in this individual passing the Shex.

@vanaukenk @dustine32 @ukemi

I've taken a little bit of a look at this repo (reactome-go-cams), noctua-models master , and noctua-models dev and I think I have a better handle on what's going on. I believe that:

• The shared reactome (R-HSA-*) models in noctua-models master and noctua-models dev are pretty much the same, except for ordering within the file (eyeballing and the fact that all the files are exactly the same size)
• There are more reactome models in noctua-models dev than master; these are likely due to previous iterations and trials for reactome that were not wiped out in dev, but overwritten
• The files in reactome-go-cams are quite a bit different to the ones in noctua-models: they seem to be structured differently, have different content patterns, and seem to mostly be larger
  • Given their earlier date (14m vs 8m), I believe that what we have in production is "truer"
  • There has been some churn in the reactome files in noctua-models master (i.e. automated saves to GH); while it may be due to tweaks to minerva that have happened, I have not checked to see if no people have ever modified them

What I would propose is:

• The contents of noctua-models master matching R-HSA-* are copied into reactome-go-cams and we declare that to be the source of truth (for things like resetting noctua-dev or emergencies)
• Moving forward, when we next update reactome-go-cams from the reactome upstream (not sure when that's scheduled), all operations pass though reactome-go-cams first
  • ^ I believe this was violated at some point in the last year, given the differences

I'd appreciate feedback on that proposal, as well as somebody maybe double checking my thought process here.

@deustp01 URL for testing?