rebrand bioregistry to be domain-neutral

[cmungall]

bioregistry functions technically as a resolver for prefixes for any scientified or non-scientific domain; in fact many of the prefixes are not bio-specific.

However, for bioregistry to function sociotechnologically for domains like earth or environmental science then it can't have bio in the name. If we want the bioregistry issue tracker to be a place where the community to come together to resolve prefix issues then we need to broaden it:

This issue was mention in #870, @cthoyt says:

Bioregistry isn't necessarily limited to bio, despite its name, so I think having this system registered is fine, especially given that references appear in some OBO Foundry ontologies.

This is a valid position, however, many people from outside the bio community will simply not use it if it has bio in the name. OBO already has this problem.

Note: the Bioregistry web site can be run with a fully custom data set that isn't the base Bioregistry (or one that's derived from base Bioregistry). We're doing that for our ASKEM project .

Making a clone of bioregistry is one option. This is analogous to bioportal -> ecoportal, etc. But there are lessons to be learned here. cc @graybeal. This necessitated setting up an ontoportal alliance, and coordinating not only over codebases, forks, but also on synchronizing metadata curation, deciding if and where there should be a canonical location for a resource.

For example, let's say the environment community set up an envregistry. Would ENVO be registered in both registries? How would we sync metadata?

I think it is perfectly reasonable to close this issue and say that bioregistry does not have the resources to explicitly cater to the non-bio community (while still allowing registry of environmental or materials science or whatever else prefixes, where the bio community finds this useful).

However, I think this would be a missed opportunity. If instead bioregistry became an alias for something like "global prefix registry", positioned where n2t was, this is not a large technical lift and we can solve a lot of problems for other communities.

[bgyori]

These are all good thoughts @cmungall. A few points:

• As far as biology/life sciences/medicine goes, the Bioregistry doesn't have to be too strict about scope: any identifiers resource that people use in this line of research is a useful addition.
• However, diluting the scope too much into something completely generic, I think, is not so great. I think there is value to having a profile for Bioregistry with some amount of domain focus that a community can feel is close to their interest.
• The Bioregistry already has the architecture / implementation in place to be deployed in other contexts with other content and we have a couple of examples of having done this, mostly for internal purposes. In these other contexts, we just refer to it as the Metaregistry. The technology stack in these variants is exactly the same, only the specific content of the resource files differs.
• So it is straightforward to deploy something with resources tailored to another scientific field. I think the more difficult part is community adoption and engagement.
• You're right about issues like metadata synchronization and I'm not sure I have any perfect answers there. A model similar to Bioregistry's harmonization of sources could work where there is a core registry (a subset of) which is automatically pulled by domain-specific registries, but these more specific registries can also add custom overrides. E.g., this is the identifiers.org->Bioregistry model of synchronization currently.

In any case, it would be good to discuss these ideas further, perhaps at the next community workshop (https://github.com/biopragmatics/biopragmatics.github.io/issues/2)

[graybeal]

wrt BioPortal, we have lessons from multiple directions: creating virtual appliances without an Alliance; rebranding to OntoPortal and adding the community Alliance; and letting any domain use BioPortal itself, with the new emphasis being research ontologies. Yes there is a real social 'acceptance' issue, but we have reasonably good adoption beyond biomedicine and medical science. The Alliance was formed as a response to the challenge of coordinating multiple forks and deployments; there are all sorts of stovepipes and collaborative issues as soon as you begin allowing redeployments of open source code.

BioPortal has a mechanism that allows multiple communities to each see BioPortal in their own way (read: with only their related assets), via suburls (e.g., CTSA. This mostly works functionally, despite no visual branding and not-entirely-complete consistency across the platform. But like @bgyori says, the hard part is creating widespread community adoption—that typically takes retail politics/sales/support.

Still, it's possible to build a single solution that also supports arbitrarily many sub-domains with specific views. Aside from the initial construction, I'm not sure that the addition of multiple domain scopes would subtract from the core domain scope. If you call the totality Metaregistry and the Bioregistry domain part Bioregistry, how does that hurt Bioregistry?

Another option to consider is the bit.ly model, wherein all sorts of different branded domains are created by communities that just redirect the branded links (whether creating or lookup up links) through to bit.ly itself. You wouldn't get the effect of slices for each domain, though; I think that would require internal software/logic. And that is a significant part of the value proposition you want, I daresay.