Closed matentzn closed 11 months ago
Hmm weird my ide didn't see it. Thanks! Anyhow, this only solves problem number 1. what about compress?
I am not sure I understand what you are asking. When compressing, it only ever goes to the preferred prefix, which is dictated by the structure of the EPM.
If you use the prefix map data structure that has duplicates of the URI prefix, then there can't be any guarantees which one gets made the "primary" (I think the implementations picks the first)
Not relevant anymore
Right now, the prefixmap in the converter object (converter.prefixmap) is a 1:n object, which means that any prefix can be linked to a number of prefixes, which makes it ambiguous (or rather, for those who like splitting hairs, order-dependent). In my opinion, this here should pass (but it does not):
This is important, because otherwise I cannot control, as a user, which prefix (not, uri-prefix) should be used in SSSOM. Right now, both are included in the exported curie map, eg.
but only the second, the one I do not want, decides over which prefix should be used during compression. So there are two issues here:
Is this an implementation issue with the prefixmap, or do we need a special extension,
converter.bimap
to cover this.See https://github.com/mapping-commons/sssom-py/issues/469