Add prefix [seed.role]

[samseaver]

Prefix

seed.role

Name

The SEED

Homepage

https://theseed.org/

Source Code Repository

https://github.com/orgs/TheSEED

Description

With the growing number of available genomes, the need for an environment to support effective comparative analysis increases. The original SEED Project was started in 2003 by the Fellowship for Interpretation of Genomes (FIG) as a largely unfunded open source effort. Argonne National Laboratory and the University of Chicago joined the project, and now much of the activity occurs at those two institutions (as well as the University of Illinois at Urbana-Champaign, Hope college, San Diego State University, the Burnham Institute and a number of other institutions). The cooperative effort focuses on the development of the comparative genomics environment called the SEED and, more importantly, on the development of curated genomic data.

License

MIT

Publications

doi:10.1093/nar/gki866

Example Local Unique Identifier

Histidinol dehydrogenase (EC 1.1.1.23)

Regular Expression Pattern for Local Unique Identifier

No response

URI Format String

No response

Wikidata Property

No response

Contributor Name

Sam Seaver

Contributor GitHub

samseaver

Contributor ORCiD

0000-0002-7674-5194

Contributor Email

No response

Contact Name

No response

Contact ORCiD

No response

Contact GitHub

No response

Contact Email

No response

Additional Comments

No response

[cthoyt]

Hi @samseaver, there doesn't appear to be enough information in this new prefix request to make a follow-up.

It appears that the example you gave is an EC number. This already has a prefix eccode. More information at https://bioregistry.io/eccode.

It might be helpful to describe the semantic space itself instead of the resource that it comes from. What is a "role" in SEED? What kinds of things appear in this semantic space? Is there something other than enzymes, or is it just a duplicate of EC?

You might also want to take a look at existing SEED prefixes:

1. https://bioregistry.io/registry/seed
2. https://bioregistry.io/registry/seed.compound
3. https://bioregistry.io/registry/seed.reaction

[samseaver]

Hi, so, this is basically an ontology that is controlled by the organization known as SEED, there's not much other than their own publications and web-pages that describes how they curate their ontology, the paper I linked pretty much describes it. The "subsystem" is a collection of molecular roles, and the molecular roles describe the function of one or more protein in microbes and plants. It is in fact an ontology much like many of the other biological ontologies that are registered in bioregistry.io, but its parent organization does the curation. It then follows that the text of the curation, though they don't use identifiers, is what they decide it should be, as in essence, it can differentiate from what other ontologies use. The use of an EC number or in the case of transporters, a TC number, etc. links the descriptive text of the molecular role to another ontology of course, but doesn't necessarily mean that the role itself is exactly what you would see elsewhere.

Does this help?

[samseaver]

Hello, is there any update to this?

[bgyori]

Hi @samseaver, I think to properly address this, we would want to carefully review of all the existing prefixes related to SEED and your contributions in that context, and come up with a comprehensive solution for its representation. Unless someone else volunteers to do this, I think @nalikapalayoor could take this on and dig into the details to understand what is going on and how to best organize all the metadata surrounding SEED.

[nalikapalayoor]

Hi, yes I am happy to look into this!

[bgyori]

Hello, @nalikapalayoor and I have looked into this issue in more detail, here is a summary of our findings and what we think the next steps should be:

• The current seed prefix in Bioregistry is specifically for subsystems, and as noted in Update SEED Subsystem #1339, we could rename this prefix to be explicitly seed.subsystem. Further, the current uri_format for this prefix is outdated, and will have to be replaced to one that we found to be working, e.g.: https://pubseed.theseed.org/SubsysEditor.cgi?page=ShowFunctionalRoles&subsystem=Biotin_biosynthesis
• The seed.compound and seed.reaction entries look appropriate and resolving identifiers works as expected.
• As suggested in Add prefix: seed.role #1341, we agree that a dedicated seed.role prefix is appropriate, and in addition, found a URL format to resolve identifiers, e.g., https://pubseed.theseed.org/SubsysEditor.cgi?page=FunctionalRolePage&fr=Histidinol%20dehydrogenase%20(EC%201.1.1.23) for the example ID referenced in the PR. These are at the end of the day derived from EC-codes but in this case due to the custom style in which these IDs are resolved, a dedicated prefix seems practical.
• Since all the prefixes (i.e., seed.subsystem, seed.reaction, seed.compound and seed.role) reference a shared resource, we should harmonize shared metadata such as publication info, homepage, descriptions, contact, etc. to the extent appropriate.

We can make changes accordingly, let us know if there is anything else we missed!

[samseaver]

Hello, this is great! I appreciate that you two took the time to look into this, and it's very helpful. We're glad that we're on the same page with the system of dedicated prefixes, and I think that covers it.

Thank you!
Sam

[cthoyt]

I'm not sure I agree that identifiers like Histidinol dehydrogenase (EC 1.1.1.23) which correspond to an existing semantic space (albeit, in a non-trivial way) are sufficient to warrant a new prefix, which would imply that this is a new semantic space.

The use of an EC number or in the case of transporters, a TC number, etc. links the descriptive text of the molecular role to another ontology of course, but doesn't necessarily mean that the role itself is exactly what you would see elsewhere.

I'm not quite sure I understand this, does it mean that there are other kinds of things that appear as a SEED role? Like from the Transporter Classification Database (which is what I guess you mean by TC)? Can you give some more examples of things that are SEED roles to cover all different varieties?

---

In situations where the semantic space is reused in a trivial way, e.g., like how record for the SABIO-RK (sabiork.ec) prefix directly reuses the eccode semantic space, we are able to annotate a provides relationship. This is a bit more straightforwards, and any downstream tooling can automatically standardize a sabiork.ec CURIE to eccode. We don't typically curate things this way in the Bioregistry, but instead use the provides relationship to help consolidate historic curations, e.g., from Identifiers.org.

However, here, it's not clear if it's fair to say this is a new semantic space, or just an implementation detail of SEED in representing an existing semantic space. Since the job of Bioregistry is to represent semantic spaces, and not projects/tools/databases, this is where my concerns come from.

Therefore, I would like some time to investigate further if there are any examples of other prefixes that are minted this way. I think it's probably the case that we haven't done this before (intentionally)

Further, I re-read the contribution guidelines and found that I had not included any guidance on what constitutes a semantic space itself. I think that such a section would necessarily need to draw from W3C guidelines/specifications on CURIEs, the Identifiers for the 21st century: How to design, provision, and reuse persistent identifiers to maximize utility and impact of life science data, and maybe some other sources. I would like to make clear some guidance to help in future submissions

---

Given that I haven't given very positive feedback after you all put some thought and effort into this, I'll pose three alternatives for consideration:

1. Curate seed.role provider in the eccode prefix, so you can see that seed.role corresponds to EC codes. There's a bit of an issue here about the non-trivial transform required to create a URL
2. Modify the seed.role record to point to eccode, despite this being uncommon. If it's more important that you have a specific record for seed.role, then this might be an acceptable compromise, but this makes less sense if seed.role is the union of eccode, tcdb, and potentially more
3. Consider a more heavyweight solution where we can include SED-like string processing commands that help transform SEED-flavored EC codes into standard ones.

[bgyori]

Only some roles are EC-code related. There are many roles with no corresponding EC-code, e.g.,

• Archease: https://pubseed.theseed.org/SubsysEditor.cgi?page=FunctionalRolePage&fr=Archease
• Xylan oligosaccharide ABC transporter, substrate-binding component : https://pubseed.theseed.org/SubsysEditor.cgi?page=FunctionalRolePage&fr=Xylan%20oligosaccharide%20ABC%20transporter,%20substrate-binding%20component
  etc.

So I still maintain that having a dedicated prefix for seed.role is the right conclusion.

[cthoyt]

Okay, so I don't think any of my suggestions are actionable. Let's just add some example_extras to cover those additional example local unique identifiers then finish the PR

[samseaver]

I'm late responding as we had a holiday weekend, but thanks again for the feedback, we appreciate that it isn't a straight-forward situation with semantic spaces.

[bgyori]

I just pushed example_extras with non-EC-code examples which I think resolves everything we discussed so far