Extended prefix map support

[joeflack4]

Overview

There are namespace situations that simply cannot be handled by a bimap. For these situations (e.g. prefix or uri_prefix synonyms), we need extended prefix map (EPM) support.

Context

We've already experienced issues where lack of this support caused issues:

• Bugfix: clean_prefix_map() not detecting prefix synonyms #485

[matentzn]

We need a clear driving usecase for this. I think the parse command absolutely needs to support EPMs, perhaps the merge command as well, but other than that, I am not convinced. For publishing sssom files, we certainly need the good old unambiguous bimap.

[joeflack4]

Aren't synonyms a clear enough use case? What do people do when they have synonyms? Would we ask them to merge them in preprocessing?

[matentzn]

Aren't synonyms a clear enough use case? What do people do when they have synonyms? Would we ask them to merge them in preprocessing?

Can you give an example? Unfortunately the word synonym has too many meanings. Are you talking about the case that the same user wants to use ICD10:Q10 and ICD10CM:Q10, and both refer to the same URI?

[joeflack4]

I mentioned in the OP about accounting for either prefix or URI prefix synonyms. Your example is of a prefix synonym. But yes, that is the primary case I am concerned about / think will come up more often.

[matentzn]

My argument against this is that there are few reasonable scenarios where synonyms should be allowed. I would need to see a real case (other than merge and parse), for publishing a mapping set with synonyms.. I can't think right now of any good reason to do it.

[joeflack4]

Hmm I see. Well if that's the case, then I'm out of ideas and you could probably close this issue. I'm just surprised that we would advocate for EPMs generally, in OAK, etc, but can't find a use case for it in SSSOM!

[matentzn]

I am not dying to be dismissive or anything - if you have a concrete use case describe it and we will talk about it. Any scenario that in involves merging data from multiple sources needs EPMs, because there may be inconsistent use of IRIs and CURIE prefixes. Hence their need in sssom parse and oak/semsql (where you may interact with merged ontologies).