legacy virtual ontology id to acronym resolver broke

[alexskr]

virtual (legacy numeric based ontology id) to acronym resolver no longer works. UI throws 500 error when browsing bioportal.bioontology.org/ontologies/1032 which used to redirect to bioportal.bioontology.org/ontologies/NCIT

I, [2023-01-26T13:34:13.641574 #10222]  INFO -- : Started GET "/ontologies/1498" for 10.130.10.10 at 2023-01-26 13:34:13 -0800
I, [2023-01-26T13:34:13.642816 #10222]  INFO -- : Processing by OntologiesController#show as HTML
I, [2023-01-26T13:34:13.642903 #10222]  INFO -- :   Parameters: {"id"=>"1498"}
I, [2023-01-26T13:34:13.651313 #10222]  INFO -- : Completed 500 Internal Server Error in 8ms (Allocations: 4354)
F, [2023-01-26T13:34:13.652648 #10222] FATAL -- :
NameError (uninitialized constant OntologiesController::BPIDResolver
Did you mean?  BpidResolver):

[alexskr]

Is it even worth fixing this issue? virtual ontology ids are legacy and have not been in use for a number of years.

[jvendetti]

I know the reason for the breakage, and it shouldn't be a difficult fix. I'll take a look at this tomorrow.

[jvendetti]

I agree though, that having ontology ID resolver code in the Rails app feels a little messy. If there are better alternatives, I'm all ears.

[alexskr]

we could look at the logs and determine which virtual ids are still in use and add redirects on the web server level. After this, we could remove the resolver from the rails. There is no need for it in the ontoportal appliance anyway. That or perhaps have a generic redirect list in the app where redirects can be added/removed on demand

[jvendetti]

@graybeal expressed a preference that we continue to accept the old numeric identifiers and resolve them to the corresponding acronyms in our current system. So, I fixed the code because it wasn't a significant effort. I agree that we should use a better solution for resolving the old IDs, but I think spending time on this should be a lower priority than a lot of the other things we have to work on. In the event we decide to tackle this, I think the work should be tracked under a new ticket that's characterized as an enhancement request.