Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Paper value import when pipe-separated entry in GPAD #31

Open
vanaukenk opened this issue Feb 14, 2019 · 9 comments
Open

Paper value import when pipe-separated entry in GPAD #31

vanaukenk opened this issue Feb 14, 2019 · 9 comments

Comments

@vanaukenk
Copy link
Contributor

From evidence rules 2 and 3 in the Google doc, we said that if there was more than one reference separated by a pipe, we would import only one reference using this descending list of preferences:

Order of preference for references:
PMID
GO_REF
doi
Other resource, e.g. MOD paper ID

Do we still want to do this?

Right now, it looks like both IDs (i.e. PMID and WBPaper ID) are being imported from the WB annotations, but only the WBPaper ID is displayed in the graph editor and both are exported in the Annotation Preview.

I can't quite make out how the paper ID is selected for the corresponding form view; both seem to be used but I can't discern a pattern.

@vanaukenk
Copy link
Contributor Author

Hi @dustine32

I'm re-opening this ticket because I think there may be a case-sensitivity issue with the references that use a DOI rather than a PMID.

The abbreviation in the GPAD is actually 'DOI' rather than 'doi'.

This model has two examples of where the DOI is not being included as the Source, probably because 'DOI' is upper case:
http://noctua-dev.berkeleybop.org/editor/graph/gomodel:c2304f62-ce53-4ef9-9a3e-feeba6fcbe8f

At some point we will need to talk about what to display for a DOI in Noctua, but for now I think it's sufficient to just display the full string.

@dustine32
Copy link
Collaborator

Hey @vanaukenk , got this DOI showing up now in test model for WB:WBGene00015350:
image

I just normalized the cases of the comparison strings.

@vanaukenk
Copy link
Contributor Author

This looks good to me @dustine32
Thanks!

@vanaukenk
Copy link
Contributor Author

Update: 2021-03-02
Import references exactly as they are found in the incoming GPAD, so, for example, there may be lines with both a PMID and a MOD reference - both would be taken and pipe-separated.

@dustine32
Copy link
Collaborator

Update from 2021-05-25 MOD imports call:

Resurrect the reference preference code! Pick only one reference per annotation, preferring in this order (same as top comment but clarified here):

  1. PMID
  2. GO_REF
  3. doi
  4. Anything else

Confirming with @vanaukenk @ukemi @sabrinatoro

@ukemi
Copy link

ukemi commented May 27, 2021

PMID
GO_REF
doi
MOD reference
Anything else?

@dustine32
Copy link
Collaborator

@ukemi "MOD reference" would just be a list of all MOD reference prefixes? Is a comprehensive list available somewhere or should I just handle MGI, WB, ZFIN, SGD references for now?

Also, is there an MGI case where the reference field would contain something like MGI:MGI:2154458|ANYTHING_ELSE:1234 that I can use to test?

@ukemi
Copy link

ukemi commented May 27, 2021

Hi @dustine32 I don't think we would have that example at MGI. They would all contain an MGI:MGI: value piped with one of the other types in the list.

As for the prefixes, maybe in a YAML file somewhere, but that assumes that all databases use the same prefix for all database objects. This is a good point I hadn't considered. Maybe stick to your original plan?

@dustine32
Copy link
Collaborator

@ukemi Right, I agree we probably don't need to consider all MOD references prefixes right now. We can always implement some more nuanced logic later if needed though.

dustine32 added a commit to biolink/ontobio that referenced this issue Jun 1, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: In progress
Development

No branches or pull requests

3 participants