Distribute OBO context / and extended prefix map in ODK

[matentzn]

From @gouttegd

obophenotype/uberon#3141 (comment)

We should make a plan on how to best synchronise this extended prefix map (EPM) across resources. Right now we sync it in sssom-py. The reason for this is that I want to review every single change to the EPM myself, so I can go and intervene if I don't like something (say, the expansion of a new prefix being added).

The question is where this "protected" epm should live ideally. ODK is certainly an option!

[gouttegd]

Having it in the ODK would be great, but it can’t be the only distribution medium. People must be able to get that map without having to “exfiltrate” it out of the ODK image.

My thoughts for now (ideas only, nothing definitive or (too) opinionated):

• It should be maintained in a repository dedicated to OBO-wide resources. Not in a repository of a completely unrelated project that just happens to use the map – so, not in the sssom-py repository, not in the ODK repository, etc. If needed, such a repository of “OBO-wide resources” should be created if none already exists (“OBO-commons” or something like that).
• The main, “canonical” distribution medium should be a PURL. That’s the main distribution medium for almost everything else produced by OBO, so that seems the most logical option to me. Something like http://purl.obolibrary.org/obo/obocommons/obo.epm.json. Alternatively, somewhere on the OBOFoundry website, but that would seem strange to me (“why must I download all OBO products on purl.obolibrary.org, but the EPM on obofoundry.org?”).
• From there, any software package that needs that map can either (1) download it dynamically at runtime (using a hardcoded URL pointing to whatever location was agreed upon), or (2) donwnload it once at build time and embed it in whatever form is suitable for the type of software package we are talking about (for example in the case of the ODK, that would simply mean putting it somewhere in the ODK image, such as /resources/epms/obo.epm.json).

[matentzn]

Yes, this makes sense. I will make an issue to see if OBO foundry would be open to host such a context.

[matentzn]

OBOFoundry/OBOFoundry.github.io#2497