Alliance instantiation of pathways widget fails in some^H^H^H^H all cases

[kltm]

This came up in an email thread with PaulT and Chris. Basically, one would expect the GO-CAM models represented on https://amigo.geneontology.org/amigo/gene_product/WB:WBGene00004055 and https://www.alliancegenome.org/gene/WB:WBGene00004055 to be the same. However, the Alliance one turns up "0" models. Odd.

Looking at the queries, we see: https://api.geneontology.org/api/gp/WB:WBGene00004055/models?causalmf=2 vs: https://api.geneontology.xyz/gp/http%3A%2F%2Fidentifiers.org%2Fwormbase%2FWBGene00004055/models?causalmf=2

So there are a couple of questions here: "how is http://identifiers.org getting in there" and "why does switching back to the WB namespace still not work"?

I know there have been issues with the release of Alliance 6.0.0(?) this week. Could this be related? Is this otherwise expected for some reason? Is it time to switch over to api.geneontology.org, instead of api.geneontology.xyz, for consistency either way?

[kltm]

Tagging @dustine32 and @tmushayahama . Also tagging @pkalita-lbl , to keep him in the loop.

[kltm]

Talking to @dustine32 may need to dig into agr_ui.

[kltm]

Okay, that's more clear: pathwayWidget.js basically includes code (loadGOCAMList) that converts CURIEs to IRI, for use against api.geneontology.xyz, which is apparently backed by a SPARQL instance pretty close to the surface.

If we switch to api.geneontology.org, we may be able to cut that portion out. That would be one fix.

I'm also curious, however, why api.geneontology.xyz no longer seems to have the data needed.

[dustine32]

@kltm I got a local instance of api-gorest-2023 running and edited the code to return the entire response. It's getting a status code 301 (Moved Permanently) when trying to send a SPARQL query to GO's RDF endpoint. http://localhost:8888/gp/http%3A%2F%2Fidentifiers.org%2Fwormbase%2FWBGene00004055/models?causalmf=2

I then noticed that the config.json is still pointing to http, not https: https://github.com/geneontology/api-gorest-2023/blob/2eeb11be62610ba6c10e5049f91b26f2c6dfcfef/config.json#L2

Updating this to https locally fixed the issue and returned models!

[kltm]

@dustine32 Okay, not that you're not 100% right here (I've merged the PR), but the mechanism is still a little weird to me.

What exactly is the issue. The apache proxy at rdf.geneontology.org is trying to do the right thing, but it's not working? Is the client in the api.geneontology.xyz unable to follow a 301?

[dustine32]

@kltm Yeah, I'm not sure of the correct way a client should be handling a 301 - maybe there's a redirect URL elsewhere in the response that body api.geneontology.xyz should follow? But the client code is currently setup to return { "error" : error } for anything that's not a 200: https://github.com/geneontology/api-gorest-2023/blob/958712f53db0e72544820795f6a26f388675c8ad/utils.js#L139

We could update the code to handle a 301 correctly but I just figured this would get us a fix real quick.

[kltm]

@dustine32 Ahh, yes--that makes perfect sense then. A bit of an oops, but the https solves it for now and that codebase is winding up, so no need to spend more time in there. Thank you for satisfying my curiosity!

[kltm]

@dustine32 This looks to be working now in production. Thank you!