integrate and compare with bioregistry

[cmungall]

This does most of what we set out to do with this repo and more: https://github.com/bioregistry/bioregistry

There are still some things this repo does that bioregistry doesn't do, but these could probably either be moved there OR this repo could be hollowed out and made more of a simple overlay

• generating JSON-LD contexts from one or more upstream sources
• inclusion of standard non-bio semweb prefixes (rdf, rdfs, owl, xsd, ...)
• allow people to remix their own prefix mappings, choosing priority lists in the event of clashes

Note that there is a ticket for integrating prefixcommons:
biopragmatics/bioregistry#9

But this repo (biocontexts) is distinct from the repo that was integrated... we seem to have caused some confusion here cc @matentzn @cthoyt

[cthoyt]

@cmungall I've included a few semantic web prefixes already. Would you be willing to try adding the rest yourself and report back on how good the documentation is at helping you get there?

I'm open to implementing the new features as well

[cmungall]

Should I go ahead and add directly to your bioregistry.json?

One thing that wasn't clear to me how to deal with forks or incorporating changes from upstream registries that may conflict with things curated into bioregistry.json

[cthoyt]

Yes, feel free to make a PR directly in the https://github.com/bioregistry/bioregistry/edit/main/src/bioregistry/data/bioregistry.json file. Put it wherever you want, there's a linter that will reorganize it and help reduce issues with incorporating changes from other people

[cthoyt]

I updated the way the bioregistry handles preferred cases and added code to automatically generate the JSON-LD context file. It's available here and will update nightly https://github.com/bioregistry/bioregistry/blob/main/docs/_data/contexts/obo_context.jsonld.

[mellybelly]

@jmcmurry can we look at some of the nested prefix handling?

[jmcmurry]

@mellybelly I'm missing some context here. Maybe you mean indigenous vs expat references? eg. MGI:00001 vs monarch:MGI:00001 I'm not convinced that nesting the prefixes is necessarily the best way to display this as it doesn't scale gracefully. That said there could be a good use case for documenting incoming IDs like so: https://github.com/monarch-initiative/dipper/blob/master/dipper/incoming_curie_map.yaml and that could ultimately drive resolution behavior.

[mellybelly]

comment was not about nested identifiers but rather resolution according to nested structured metadata... trying to recall where we documented these examples. maybe @jkunze recalls, maybe in NT2

[jmcmurry]

That doesn't ring a bell but end users can already choose to resolve based on default (up time) or by hard coding a specific provider. https://docs.identifiers.org/articles/docs/resolving_mechanisms.html