Open cmungall opened 1 year ago
These are all good thoughts @cmungall. A few points:
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)
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.
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:
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.
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.