You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What is the policy on having different types within a namespace, and having these be partitioned?
There seem to be some decisions inherited from identifiers.org, for example, using the . to partition, e.g. DATABASE.TYPE
For better or worse, these seem locked in so I would elevate this from convention to recommendation.
E.g. a NS MAY be partitioned, if it is partitioned, the .MUST be used, and a . MUST not be used in a NS except to partition. The authority for the partitioned NS must be the same as the base NS
I think some of these should be actively reviewed. The subnamespacing convention can lead to different ways to write the same ID. To be honest, many of these were created simply as workarounds for legacy databases that had issues with providing a single URL to resolve all types within that database.
For example, there are two ways to write the same dictyBase gene
This was agreed on with the maintainers of that database (@cybersiddhu).
However, identifiers.org registered both "dictybase" as well as "dictybase.gene" and "dictybase.est". The base "dictybase" doesn't seem to be useful and if I click on the example on the bioregistry page I get
Note that the GO registry may be responsible for some confusion here. We used to have a lot of entries where we dealt with this problem by having sub-patterns within a single namespace:
however, we gradually started splitting some of these out to be consistent with identifiers.org, but we had previously used underscore as separator, e.g.
I have a few recommendations on how to proceed but I wanted to start just by laying out some of the heterogeneity here and propose that we are proactive here and propose a robust system rather than being tied to arbitrary decisions based on what a CGI script in 2001 could or could not do.
The text was updated successfully, but these errors were encountered:
What is the policy on having different types within a namespace, and having these be partitioned?
There seem to be some decisions inherited from identifiers.org, for example, using the
.
to partition, e.g.DATABASE.TYPE
For better or worse, these seem locked in so I would elevate this from convention to recommendation.
E.g. a NS MAY be partitioned, if it is partitioned, the
.
MUST be used, and a.
MUST not be used in a NS except to partition. The authority for the partitioned NS must be the same as the base NSI think some of these should be actively reviewed. The subnamespacing convention can lead to different ways to write the same ID. To be honest, many of these were created simply as workarounds for legacy databases that had issues with providing a single URL to resolve all types within that database.
For example, there are two ways to write the same dictyBase gene
GO uses dictyBase:DDB_G0282931. E.g. http://amigo.geneontology.org/amigo/gene_product/dictyBase:DDB_G0282931
This was agreed on with the maintainers of that database (@cybersiddhu).
However, identifiers.org registered both "dictybase" as well as "dictybase.gene" and "dictybase.est". The base "dictybase" doesn't seem to be useful and if I click on the example on the bioregistry page I get
http://bioregistry.io/reference/dictybase:DDB0191090
Note that the GO registry may be responsible for some confusion here. We used to have a lot of entries where we dealt with this problem by having sub-patterns within a single namespace:
however, we gradually started splitting some of these out to be consistent with identifiers.org, but we had previously used underscore as separator, e.g.
Another category is where the namespace and subnamespace are smoothed together e.g
http://bioregistry.io/registry/ncbigene
http://bioregistry.io/registry/ncbitaxon
I have a few recommendations on how to proceed but I wanted to start just by laying out some of the heterogeneity here and propose that we are proactive here and propose a robust system rather than being tied to arbitrary decisions based on what a CGI script in 2001 could or could not do.
The text was updated successfully, but these errors were encountered: