Target annotations on landing page

[phraenquex]

We have auto-generated content, including uniprot IDs, papers (dois?), etc.

Need:

• somewhere to put it
• somewhere to populate it
• clear links from landing page

Might use Discourse, or possibly something else.

[matteoferla]

Preliminary prototype w/ Blast —> Uniprot —> metadata using old Fragalysis API https://github.com/matteoferla/munged-Fragalysis-targets

[boriskovar-m2ms]

@phraenquex we can put button next to each target on the landing page and when you open it there will be links to additional content. This should ensure that the table is not too busy.

It should be populated from frontend? I think we will need also support from backend.

@matteoferla To be absolutely honest I have zero idea what I'm looking at.

[phraenquex]

@boriskovar-m2ms the information will need to be shown up-front in table form - hiding it behind a link will not be helpful.

Context: the target name is completely meaningless to the general viewer; so we need to show them additional information (gene name, organism, etc) to make it useful. And that information exists in other databases.

This is an ancient problem for websites interfacing to databases of gene and other biology things: the same thing can have many names, and (worse) you don't even know it's the same thing until someone does serious research on it, and (worst) the same thing can show up in different variations, triggering huge fights in that scientific sub-sub-sub-speciality about whether it is or is not the same.

It is this problem that Matteo's code touches on.

@matteoferla would you mind creating a precise mock-up of what you think that panel needs to look like, especially (!) what data need to go in which columns, and what bit of your code retrieves that data.

But @boriskovar-m2ms, it's a replicate of the Projects table (possibly an exact replicate). Just needs different data in the columns.

This is indeed a frontend/backend ticket

• the data will need to be stored in the DB
• the frontend will need to allow the user to run the code to populate the DB
• the frontend will need to allow the user to curate the data (doesn't need complex GUI - a text window might be enought)
• the frontend will need to be able to squirt the curated data into the backend - and the validation by the backend will need to made visible to the user, so they can fix things if they've messed it up.
• the backend needs to serve it to that frontend panel.

[matteoferla]

Summary: The Database would need 6 new character fields. The backend would need to pass these 6 the front end, along with the other fields. In terms of displaying I agree icons or an icon to a modal over table.

Detail

@phraenquex —I would argue that gene/protein synonyms is not a problem if uniprot IDs are stored. PDB wisely runs on those (see below). Discussion got bogged down in special case leading to plans getting deorbited. But the simplest implementation is fine for 99.99% of use cases.

Let's play devil's advocate and get a nasty case and treat it simple: XX01ZVNS2B.

The following can be generated once for the "primary" peptide (i.e. would need to be store in the backend)

1. Chain letter
2. Protein name as manually defined by a human to keep humans happy: NS2 protease
3. Uniprot ID of "primary" peptide (Q32ZE1) — and link: https://www.uniprot.org/uniprotkb/Q32ZE1/entry
4. Range of structure sequence in said Uniprot ID: 1499-1676
5. Organism scientific name: Zika virus: https://www.uniprot.org/taxonomy/64320
6. Protein domain family: PF00949 https://www.ebi.ac.uk/interpro/entry/pfam/PF00949/

The following is already stored and presented:

7. Myserious lb18145-1 gibberish
8. Is SGC target
9. Link to discorse

Generated from Backend DB on each load:

10. N hits
11. Date last visit (Is the project dead)
12. Data version number (I assume this is kept somewhere) —useful for computational folk

Info that could be useful, especially for analysis, but hard to enforce as a restricted dictionary of what is the protein. For NS3: "Protease", "enzyme", "peptide-binding". This would be useful for anyone using Fragalysis data to do analyses (eg. say were Anna doing her study today she would be able to classify the hits into peptide-binding pocket and nucleotide-binding pocket (cf. discussion PPI pockets yield lots of amide hits). But is non trivial to generate automatically, so might be a dont-go-there zone.

These 12 are info I would like. But I agree with @boriskovar-m2ms that a table would not fit. So 5 options:

• Mega table on own page separate from project links
• Mega table squished with project links
• info button that triggers a modal
• boxes with info in header (akin to https://asapdiscovery.org/pipeline/)
• icons with hoverover info akin to this would make sense.

Footnote

In terms of nastiness. The protein is a complex of NS3 and NS2B, which as it's viral is unlike most protein and made as a single polypeptide. The PDB already deals with these annotations. For example https://www.rcsb.org/structure/6l50 However, the metadata is not simple to handle. Hence why for the sake of sanity, just defining the primary polypetide and annotating that is by far easiest. Likewise, PDB does handle mutations and non-canonical amino acids (phosphoserine etc), but is complicated and actually one could figure it out...

[matteoferla]

@tdudgeon / @alanbchristie — In the above points 10–12, are they easily doable?

[boriskovar-m2ms]

@matteoferla if I understand this correctly 1-6 are user defined? @phraenquex Is it OK that anyone logged in is able to curate this data?

[phraenquex]

@matteoferla asked about the target name. @boriskovar-m2ms confirms it shows up EVERYWHERE, acting as a de facto database key. Including snapshot json and stuff. So currently it functions as a CODE, that doubles up as a name.

So we need an explicit separate target name field, that is easy to edit and curate.

Some reach-through: some frontend things might need the backend to dereference the CODE from the NAME, because users might not realise when they're differen.t E.g. the upload interface, etc. @alanbchristie can investigate.

[matteoferla]

Meeting points:

• No to icon solution for space
• Both tables interactive (filterable/sortable)
• Implement two tables and deal with space issue later (e.g. split into two pages etc.)
• A new view in Fragalysis would be required to edit the metadata for a give target code: code is immutable, while Name etc. are not

I will aim to get a CSV with data after dealing with OpenMM and completing my current documentation dive — 2 weeks?

[phraenquex]

Stuff copied from decprecated #1072:

Scope: make the left-most panel of the homepage more informative. Likely:

additional columns, with meaningful entries (date, creator, description field, links to other databases)
rework format - likely reuse changes made for right-side projects panel
links to other databases - see 

https://github.com/m2ms/fragalysis-frontend/issues/1063.

Might need some small backend-changes - likely additional fields in the target table.

[phraenquex]

@matteoferla we need the CSV more or less NOW - any chance you can do it today?

Even incomplete would be fine - @RoboMatuska cannot otherwise proceed.

[phraenquex]

Order of proceedings:

• @RoboMatuska copy Project table to Target table - populate with dummy columns
• @matteoferla provide CSV file
• Then Matteo help IM spec out backend requirements.

Priority for this ticket is the FRONTEND stuff - the backend we can populate later. As long as the API calls are extensible - please design accordingly.

The key USER problem to address now: people cannot find their targets. The tools for this exist in the Projects view, they need to come across in the Targets view. If this is resolved, we can move the rest to a new ticket.

[matteoferla]

@RoboMatuska — Apologies for the lateness of the file, but it is still technically today in British Summer time, just about.

Here is the simplest version of the data:

simple_values.csv

• 'Id': Database index. Not to be shown to users
• 'Target': Called "title" in the API ("model" in DB). The foreign key used everywhere to refer to the target
• 'Number of chains': a number
• 'Primary chain': a single character
• 'Uniprot': a string displayable as a link https://www.uniprot.org/uniprotkb/👾👾👾
• 'Range': a string of type number hyphen number
• 'Protein_name': long string
• 'Gene_name': short string
• 'Species_id': Not to be shown to users. Used for the link of 'Species'
• 'Species': string displayable as a link https://www.uniprot.org/taxonomy/👾👾👾 using the id from Species_id
• 'Domain': string
• EC number: string
• 'N hits': this number should be generated from the server
• 'Date last edit': I am hoping this exists
• 'Version id': I am hoping there is some data version scheme

I will upload the data used to generate it for the sake of reference tomorrow.

Regarding the two entries that could be displayed as a link: if there was talk that clicking the whole row opens the Fragalysis page, please ignore these then.

Regarding the fact that it is "simple", the ideal and more correct solution is that most of the entries would be served not a simple value, but as a mapping of the chain ids to the values, eg. {'A': 'P12345', 'B': 'P92345'}, where you'd have the use the value in 'Primary chain' to get the value that is actually wanted. I have generated a dataset like this, but can only be passed as a JSON. And is a pointless complication, which I hope won't be needed.

[phraenquex]

The backend work might only be completed after the full v2 release (dark-purple). Probably by target loader.

[matteoferla]

For record-keeping. Notebook used to generate data: https://github.com/matteoferla/munged-Fragalysis-targets/blob/main/Fragalysis_targets.ipynb

[phraenquex]

The spec on this ticket is now required only for dark-purple release, as part of V2 makeover.

The preparatory front-end work is now specced out in #1161, which remains on the light-purple release.

Moving this ticket into ASAP swimlane, out of in-progress.

@RoboMatuska @boriskovar-m2ms please acknowledge.