-
-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Converter.prefixmap
should be a bimap
#96
Comments
Converter.prefixmap
should be a bimap
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 mapping-commons/sssom-py#469
The text was updated successfully, but these errors were encountered: