[HIGH] "Create New Condensate" Functionality

Nadia to make the design for the form and provide it to the frontend developer

Data points that can be stored in DDCODE as of now:

0. Biomolecular/Synthetic *
1. Condensate Name *
2. Condensate Synonyms
3. Species Taxonomy ID (& name) as per NCBI *
4. List of proteins along with related details *

4.1. Pubmed IDs for this protein in this condensate *
4.2. Functional type for this protein in this condensate
4.3. Driver criterion fulfilled (if any) [options already provided]
4.4. Experimental evidence (if any) [options already provided]

assigned to @rostam

changed the description

changed title from Create New Condensate Form to [HIGH] Create New Condensate Form

added 1 design

Add_a_new_condensate_template.pptx

I have attached the template form for adding a new condensate in .ppt and .tiff Please let me know if something is unclear. I am not completely sure how you add this from frontend. What is important is that when someone wants to adda new condensate there should be the option of adding more than one protein (protein 1,2,3,4, etc), also for each protein they should be allowed to add the further information as shown in the form (eg, for criteria for being a driver they should be able to choose the criteria from add new protein form and for type of experiment they should be able to choose between in-vitro, in-vivo etc). @sghosh

marked this issue as related to #49 (closed)

changed the description

Task #49 (closed) is pre-cursor to this task

changed the description

changed title from [HIGH] Create New Condensate Form to [HIGH] Create New Condensate Functionality

@moon @raghosh Need to create a new collection/table from Strapi named "NovelCondensates" and related CRUD functions from the frontend.

The data structure would be as follows:

Attributes	Data Type	Frontend Label
is_experimental *	boolean	Condensate Type (Synthetic ? Yes/No)
name *	string	Suggested Name of Condensate
synonyms	list of strings	Other Commonly known names
species_tax_id *	int	NCBI Species Taxonomy ID
proteins *	list of dicts (JSON)	Proteome Members
status	string[enum]	N/A
submission_comments	long-text	N/A
submitted_by_user_id	user_id	N/A
submitted_at	datetime	N/A
reviewed_by_user_id	user_id	N/A
reviewed_at	datetime	N/A
sync_response	string	N/A
synced_at	datetime	N/A

The attributes with the label N/A are populated by the system and not inputted by the user. The attributes after proteins are similar in nature to those from UpdateItems

For proteins, the data type would be a list of key-value (hash) objects, with each having the following structure again:

Attributes	Data Type
uniprot_id *	string
functional_type	string[enum]
pubmed_ids *	list of string
driver_criterion	list of string[enum]
experimental_evidence	list of string[enum]

A new page/form needs to be put up which contributors can use to submit new possible condensates. Maintainers see this submission and can accept or reject these entries. The accepted entries will be synced to the main database by script.

NovelCondensate would be better since Strapi uses two api calls, one is singular /novel-condensate and the other is pluralized /nove-condensates similar to UpdateItem.

I hope the actual table name in PostgreSQL is novel_condensates

This is the dump of table creation in postgreSQL.

create table novel_condensates
(
    id                  serial
        primary key,
    name                varchar(255),
    is_experimental     boolean,
    species_tax_id      integer,
    proteins            jsonb,
    synonyms            text,
    status              varchar(255),
    submission_comments text,
    submitted_at        timestamp(6),
    reviewed_at         timestamp(6),
    sync_response       varchar(255),
    synced_at           timestamp(6),
    created_at          timestamp(6),
    updated_at          timestamp(6),
    created_by_id       integer
        constraint novel_condensates_created_by_id_fk
            references admin_users
            on delete set null,
    updated_by_id       integer
        constraint novel_condensates_updated_by_id_fk
            references admin_users
            on delete set null
);

alter table novel_condensates
    owner to strapi;

create index novel_condensates_created_by_id_fk
    on novel_condensates (created_by_id);

create index novel_condensates_updated_by_id_fk
    on novel_condensates (updated_by_id);

We do not need to take the input for species_tax_id from the user. Will discuss this in tomorrow's meeting.

I made a mistake with the protein's embedded attribute. It should be experimental_evidence and not experimental_evidences just to keep it in sync with the already present backend attributes.

changed title from [HIGH] Create New Condensate Functionality to [HIGH] "Create New Condensate" Functionality

assigned to @moon and unassigned @rostam

changed due date to June 03, 2022

added new feature label

For the data structure of proteins, please enforce it from the frontend form

I think there two way to add a condensate. One is from ProteinDetailPage and the other is from LandingPage. The former does not need to specify protein since we can use the protein loaded already. However, the latter needs collection of proteins. Do you think we need to consider new proteins which are not in our database?

I think we should consider adding new proteins which are not in our database, yes. However, once we have the condensate added in any way (which you prefer), one can go and use the option of "add new protein" to add the proteins to it.

Create new condensate from a ProteinDetailPage doesn't sound so wrong to me. However, the label should be something like Create new condensate with this protein. Add new condensate to this protein sounds kind of wrong.

Also, where is the option from the landing page? Do you mean home page by landing page?

I feel there should a new page for "Create New Condensate" and the tab should be a sub-tab under the Condensates tab.

No problem. @rostam guided us to have it here as you asked.

Perfect !!

Also, where do the maintainers see the list of submitted condensates, where they can accept or reject such requests.

We have two options. one is have another tab for maintainer to see add condensate related requests or have it shown on all submitted changes below or above the updateItems table which may look like a bit crowded.

The second option is preferable- have a new table to show add condensate requests.

...

From: "raghosh (@raghosh)" gitlab@git.mpi-cbg.de To: sghosh@mpi-cbg.de Sent: Monday, May 16, 2022 09:23:23 PM Subject: Re: dd-code-web | [HIGH] "Create New Condensate" Functionality (#69 (closed))

raghosh commented on a discussion :

We have two options. one is have another tab for maintainer to see add condensate related requests or have it shown on all submitted changes below or above the updateItems table which may look like a bit crowded.

— Reply to this email directly or view it on GitLab . You're receiving this email because of your account on git.mpi-cbg.de. If you'd like to receive fewer emails, you can unsubscribe from this thread or adjust your notification settings.

Some notes from the form I see as of now:

1. No need to add accept species_tax_id from the user. This will be computed by the sync script based on the proteins submitted
2. For condensate-specific protein details (protein-sub-form), two more data points need to be accepted from user: functional_type, pubmed_ids (* - mandatory)
3. synonyms to be a list of strings instead of comma-separated strings. Also, this is not mandatory input
4. Would suggest removing the add option from the proteins detail page as this might create confusion for the pre-filled protein (I don't see this pre-filled now)
5. When accepting Uniprot ID in the form, we need to show a not explain exactly what the Uniprot ID of a protein is. This can be shown using the (I). Will share the text soon.
6. The radio buttons for is_experimental should rather be: Synthetic or Biomolecular

Those are handled except Proteins-search bar list with 'Add New Protein'. You can check it in the dev instance.

Uniprot ID explanatory note:

The UniProt ID (accession) is the 6 to the 10-character-long name displayed on the heading of the protein page from Uniprot. It is a unique identifier for a protein from the whole Uniprot database (https://www.uniprot.org/help/accession_numbers). Please note that different proteins from the same gene will also have different Uniprot IDs. For example, The Uniprot ID of "FUS Human" is P35637 (https://www.uniprot.org/uniprot/P35637). It is usually the last part of the URI of the HTTPS link of the protein page.

changed due date to June 10, 2022

mentioned in commit e53bc40d

closed