Improve handling of ad-hoc OBO namespaces in ShortFormAnnotator

[cthoyt]

Related to #935

This PR extends ShortFormAnnotator.java to handle ad-hoc namespaces in the OBO PURL space that take the form http://purl.obolibrary.org/obo/<lower>#<luid>, such as http://obolibrary.org/obo/mesh#C

This PR will give more accurate short form names that does not rely on implicit capitalization conventions

[cthoyt]

I wasn't able to find a place to write some unit tests - @haideriqbal could you advise where I can put some?

[haideriqbal]

@cthoyt we don't have unit tests in OLS, we do manual testing at the moment of comparing the dataload files for different test scenarios...

for this change i will need to do that and will let you know... we are looking into automating the testcases as some point

[cthoyt]

@haideriqbal I added some unit tests, but I'm not sure the best way to run them/incorporate in CI

[haideriqbal]

@cthoyt we don't run unit test in traditional sense for OLS. We have a testcases folder where we add specific kind of ontologies to address various OLS use cases. If you can have a look at the folder and formulate a test which depicts this change that will be awesome. Also, have a read through OLS readme to get a gist of how we run the testcases for dataload in OLS.

[cthoyt]

hi @haideriqbal I started going down the road of adding some end-to-end tests but found that it was pretty inaccessible as an outside developer. Instead, I got the unit tests to work as part of the build, which can also be built with mvn clean test and are also now part of mvn clean package. This is more than sufficient to demonstrate that we have an understanding of what the code is doing and why.

However, it might be the case that improving the short form annotator invalidated other end-to-end tests, and I'm having a hard time seeing if that's the case since they don't give very pointed output (i.e., there's way too much logging, I can't see what is important)

[cthoyt]

@haideriqbal I'd appreciate a second look at this - I can confirm that mvn clean test works for the code I modified.

The test failures are likely unrelated, and are also failing on the main branch, but it's also not 100% certain that there are not subtle changes introduced here that would also need to be updated in the unit tests

[haideriqbal]

@cthoyt test failures are not related to your PR... it's the way the tests are designed at the moment for OLS. We do manual testing where we compare the result of dataload part of the pipeline and then also run API testing. Details of these two methods are written in our README. The issue is as this is done via file comparison and almost everytime we have false positive where pipeline writes some json object at a different place then where it was before which results in a mismatch and test fails.

This situation is not suited for automated testing hence we have failures everytime in the github actions. Until unless, we change the way we test OLS I personally don't see a point of having automated testing where its going to fail everytime.