renormalizing to latest owlapi

[cmungall]

This PR contains no content changes. It only contains the results of re-saving (normalizing) between 3 different people on different platforms. Scroll down for result summary...

[cmungall]

Prior to this PR, master's last commit was an edit from @pbuttigieg using Protege 5.6.1 (Windows)

• 88f9fc9 - normalize using robot 1.10.0-SNAPSHOT by @cmungall (large spurious diff)
• b9564c0 roundtrip through Protege 5.6.1 (windows) by @pbuttigieg (large spurious diff)
• 7d6b51a roundtrip using robot 1.9.4 by @turbomam
• 280c67f further roundtripping by @turbomam through Protege 5.6.1 (windows) and robot (one line spurious diff)
• At this point @cmungall made fake edits in Protege, saved, no spurious diff

Additional data:

both @turbomam and I did additional saves to rdf/xml using both Protege 5.6.1 and robot and confirmed both get:

<!-- Generated by the OWL API (version 4.5.25.2023-02-15T19:15:49Z) https://github.com/owlcs/owlapi -->

Main Conclusion: Mac Protege 5.6.1 and robot 1.9.4 are in sync and will not produce spurious diffs.

However, there is something different about windows Protege, either it is using a different version of the owlapi or there is underlying non-determinism that only manifests for different OS's

Minor conclusion:

Even when using synced tools, we get this spurious diff

< Prefix(:=<http://purl.obolibrary.org/obo/envo.owl#>)
---
> Prefix(:=<http://purl.obolibrary.org/obo/envo.owl/>)
> Prefix(iso:=<https://www.iso.org/obp/ui/#iso:std:iso:>)

[cmungall]

I will merge this for now as Mark needs to do edits today and master should be normalized relative to him and me, but this is not sustainable long term.

As an intermediate measure I leave these instructions for @pbuttigieg, but I am asking for broader help on the Protege channel.

Prior to commit, normalize this way:

robot convert envo-edit.owl -o temp.ofn
mv temp.ofn envo-edit.obo

Making sure you are on 1.9.4