Extended prefix map support

[joeflack4]

Overview

There doesn't seem to be much support yet for EPMs in OAK.

Questions

1. Should there be a mirror issue for this in SemanticSQL?

Additional info

Context
Recently I was trying to use some extended prefix maps (EPM) in lexical_index_to_sssom() (#697), and I noticed it wasn't supported.

[cmungall]

Can you say more about what you expect here? Is this for normalizing prefixes that are inputs? Or for normalizing as outputs?

[joeflack4]

I actually don't entirely know what all the use cases for this would be. I do know that there was a situation in #697 where I was able to prevent an error from occurring by passing an EPM. IIRC, the first error I got was because it detected that oio and oboInOwl were conflicting. Then, after deleting oio, it threw an error because it was missing. For now we're solving it instead by not passing any meta or prefix_map to that function. Nico said there would be some drawbacks from that. I don't know what those are, but it hints that maybe EPM support is needed at least for the #697 case. And so I suspect perhaps similar problems could occur elsewhere in OAK.

[matentzn]

This is relevant for two reasons.

1. Some assumptions are being made within the code about prefixes, which the user does not know about and would have to be standardised somehow prior to running services Hard coded CURIES in OAK code cause confusion when ontologies use different prefix maps #698
2. Some external sources need to be standardised when mapped in, and for that, an epm is much more convenient than a prefix map (for example, when the ontology uses snomed:123 and the dataset uses scit:123).

• We should implement a method runoak normalise-prefixes -i ont.db --epm epm.json that standardises and existing db towards a prefix map after it has been created.
• Even better, of course, or in addition: runoak generate db -i ont.owl -o ont.db --epm epm.json --relation-graph true taking the role of semsql which is a real hamper in the uptake of oak imo.