💾 Archived View for thebird.nl › gn-gemtext-threads › issues › edit-metadata-bugs.gmi captured on 2023-04-19 at 23:22:12. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

Cannot Edit Metadata of BXD Traits Effectively

Tags

assigned: bonfacem
keywords: metadata
priority: high
closed

Tasks

[ ] I cannot edit the PMID number

[ ] There is inadequate feedback on whether or not changes have been accepted (PMID: 24640950. Publication below)

https://pubmed.ncbi.nlm.nih.gov/24640950/

[X] I am unable to add the Abstract for the paper

[X] There is no place to enter the volume number of the journal. Please see GN1.

[X] I cannot change the "authors" text.

[X] Fix Typos

[X] Remove some form fields (Sequence)

[X] Adjust the size of some form fields

[X] Remove the "Reset" button

[X] Move the update history to it's own page

[X] Re-order form fields to match common citation styles

[-] Re-design the button for uploading the forms

Description

This is closely related to:

/issues/metadata-edits-improvements

Here's a list of UI elements and how the should be:

Links should be in blue and highlighted ("History").

Make important things stand out in a user-friendly way. Right now, the most important thing: editing metadata by downloading a file is at the very bottom.

Editing the pubmed id should have a cascading fx on the related traits .i.e. editing the pudmed id of one trait should update the pubmed id for all the related traits.

Hide the "reset" button.

"Sequence" should not be part of the form.

Historical reasons for the "pre-*" field e.g. pre-publication was explained in detail. They are there to mark a sort of "confidential" not-yet-ready data.

The word "sample data file" is confusing to users.

When adding case-attributes, new columns should be added on the fly.

Useful idea: For small datasets, allow edits on UI. For large datasets, or data that has new case-attributes, provide excel files.

There are some fields which are important, but not really used much: "lab code", "Authorised Users".

UI tweaks: left justify buttons.

No need to edit the case attribute names that are similar in the db. I'll need to find a way to infer this using existing information. This means to remove this hack: Sex(3), Sex(14). Notice the id's embedded in the names.

Set up a meet with Suheeta. See how she uploads the data.

Typos: "Pre" is not a word on it's own. "Pre Publication" should be "Pre-publication". Key idea here is to correct typos when spotted, and not to leave this to the hands of the end-user.

Hints on certain forms. When the authors form is empty, the user is showed a grayed templet of the input format for the authors. For other form element, if feasible, collaborate with Rob to see what useful hints we can provide the end-user.

A note about some confusion about PublicationId and PubMed_ID (credits: Zach):

There might be some confusion over the "PublicationId" vs "PubMed_ID"; the
latter isn't in PublishXRef and is only in the Publication table, while the
former is the foreign key you mention in the PublishXRef table
corresponding to Publication.Id

What happened in this situation is that Suheeta tried to change the
PubMed_ID for a trait when that PubMed_ID was already associated with a
different PublicationId. So when the UPDATE query was executed, the DB
threw an error because it was trying to assign a value to
Publication.PubMed_ID that already existed in another Publication row.

The change in logic I'm suggesting is that, if a user tries to change a
trait's PubMed_ID to one that already exists (but is associated with a
different Publication), its PublicationId (in the PublishXRef table) should
be changed to the PublicationId already associated with that PubMed_ID
(because there was likely a mistake at some point where a new Publication
row was created when the trait should have been assigned to one that
already existed). It probably also makes sense to remove the former
Publication row if no other traits are associated with it.

To maybe help clarify further, in this case there were at least 3 traits
that should all have been associated with the same Publication. But
instead, the situation was like this:
BXD_18435 -> PublishXRef.PublicationId = 14055 / Publication.PubMed_ID =
34552269
BXD_18441 -> PublishXRef.PublicationId = 14055 / Publication.PubMed_ID =
34552269
BXD_21473 -> PublishXRef.PublicationId = 24165 (wrong, should have been
14055, and when the user tries to set the PubMed_ID to 34552269 for 24165,
the DB will throw an error since that value is already associated with
14055)

Some useful feedback from Suheeta:

[...]

Instead of just throwing an error message back about duplicates, it will be better if it recognizes the existing PubMed_ID and
reverts to it.

Also, [Rob's suggestion of] secondary PMID makes sense since many of our publications are now using the same or part of the same dataset. For individual BXD
data, we have a case attribute that lists the samples used for a particular publication (KM20, SR21, KM21, EW21), would it make sense to link the respective
PMIDs with those attributes? Like a clickable link that would take you to that publication in PubMed.

[...]

Resolution

Most of the UI issues were fixed in:

UI/Improvements to data uploader