uniprot prefixes in prefixmap seem to be a bit random and not uniprot purls

[JervenBolleman]

e.g.

  "UNIPROT.ISOFORM": "http://identifiers.org/uniprot.isoform/" 
"UniProtKB": "http://identifiers.org/uniprot/",

in the context.jsonld

these should be

"UniProtKB": "http://purl.uniprot.org/uniprot/",
and
"UNIPROT.ISOFORM": "http://purl.uniprot.org/isoforms/",

This was fixed in part in 5ddb324
but got overwritten by something.

[sierra-moxon]

Thanks @JervenBolleman - Biolink imports prefix maps from a variety of sources, one of which currently is prefixcommons, which establishes the UniProt expansion "UniProtKB": "http://identifiers.org/uniprot/",
Since we generate the jsonld file automatically as part of the build process without an exception for this in the "prefixes" section of the biolink-model.yaml, the changes to the jsonld file will be overwritten with the canonical expansions from these upstream sources (prioritized in the default_curi_maps section of biolink-model.yaml)

I'm working towards incorporating prefixmaps prefix maps into the default_curi_maps section of biolink too as bioregistry is being actively maintained, etc. (merged maps from prefixcommons, identifiers.org, bioregistry, etc). Right now, that source has the identifiers.org expansion for UniProt as well.

It would be ideal if we could change the expansion upstream in one of these sources, but if we can't we can certainly add an exception in Biolink as we've done with other cases. :)

[kltm]

Tagging @cmungall . I'm assuming we use this metadata; wouldn't a change in identifier have consequences for what is already in play?

[JervenBolleman]

@kltm I suspect not, considering it has in the past already had a uniprot purl and a uniprot www address expansion :) They still represents the same thing.

[cmungall]

Let's make an exception in biolink for now and solve this in prefixmaps - prefixmaps is designed specifically to allow for different contexts for different purposes.

Note that to make an override in biolink the correct place to do this is in biolink-model.yaml - any PRs on the generated jsonld context like 5ddb324 will be overridden as this is generated from the yaml plus upstream sources

[sierra-moxon]

closing as completed - for now we will put in exceptions in biolink, fixing later upstream in prefixmaps.