Theiler stages ids not working when submitting to Minerva

[tmushayahama]

It all started here geneontology/noctua-form#152

For Example when you put TS12 in the autocomplete, it will not save with an error

To reproduce

1. Add Individual
2. Autocomplete TS12
3. Click Add
   tagging @balhoff @vanaukenk @ukemi @kltm

[vanaukenk]

@ukemi will discuss with Terry at MGI to see if the TS terms in EMAPA can be assigned curies

[balhoff]

@kltm I think this may be primarily an issue between Noctua and the autocomplete service (GOlr?). This is the requests value being sent to Minerva:

[
  {
    "entity": "individual",
    "operation": "add",
    "arguments": {
      "expressions": [
        {
          "type": "class",
          "id": "TS12"
        }
      ],
      "model-id": "gomodel:61f3310500000000",
      "assign-to-variable": "113c31d8-9f68-4c08-8613-9c32ff96f277"
    }
  }
]

The id value is supposed to be a CURIE, as Minerva says:

"message": "Could not successfully handle batch request. Exception: org.geneontology.minerva.MolecularModelManager$UnknownIdentifierException. Relative IRIs are not allowed: TS12"

My guess is that GOlr or Noctua are tripped up by the unusual IRI structure for the Theiler stages.

[kltm]

@balhoff Can you outline what this structure is? It's mostly invisible to me until it reaches NEO (and AmiGO). I.e., the damage seems to already be in place in NEO (http://noctua-amigo.berkeleybop.org/amigo/term/TS12), so the autocomplete is doing as expected.

So, in emapa.owl (assuming this is the origin file--I may be wrong about that), grepping for oboInOwl:id returns stuff like: EMAPA:38000 and things like TS12. I feel like most of the IDs in our universe are usually CURIEs; why are these the exception? With that, I'm also curious why TS:0 has a colon, but none of the children do (http://noctua-amigo.berkeleybop.org/amigo/term/TS:0#display-lineage-tab)?

[balhoff]

The URIs for the stages look like http://purl.obolibrary.org/obo/emapa#TS12. Probably this is intended to be http://purl.obolibrary.org/obo/TS_12 like it is for TS:0. So that could be fixed in EMAPA and probably solve this problem (although TS is not a registered OBO prefix; they really should give these EMAPA IDs).

As a separate issue, I don't think any software should use the oboInOwl:id annotation for anything. Maybe the GOlr loader is looking at this?

[kltm]

@balhoff Sorry, I'm not actually sure what the loader looks at off the top of my head, I was just using oboInOwl:id to show my work and try and make a point about the IDs.

I would agree that I feel that this is more of an upstream ontology issue in EMAPA, rather than one that is occurring within our data flow. Even if we tried to fix it at this end, I feel that it would likely boil down to essentially CURIEifying them at some level anyways.

[balhoff]

I opened a PR on EMAPA, in case they want to accept it.

[vanaukenk]

@ukemi @balhoff
Do either of you know what the current status of this work is?
Thx.

[ukemi]

I can check on this today.

[ukemi]

No new updates.

[vanaukenk]

@ukemi - can you post an update on this ticket so we know where things stand? Thx.