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

lack of connection between cell types and anatomical structures #30

Open
kltm opened this issue May 26, 2017 · 4 comments
Open

lack of connection between cell types and anatomical structures #30

kltm opened this issue May 26, 2017 · 4 comments

Comments

@kltm
Copy link
Member

kltm commented May 26, 2017

From @krchristie on May 8, 2017 17:44

Often, it seems really ridiculous that I have to have the cell type and the anatomical structures in separate individuals and label the evidence between them. For example, in PMID-23525783-KRCX, I am trying to represent that 4 genes (Dnah5, Dnah9, Dnaic1, & Dnaic2) have been shown (by immunofluorescence evidence) to be present in a (9+2) motile cilium that is in an ependymal cell from a lateral ventricle (of the brain).

For lack of anything sensible to do, I have labelled these two edges with the same immunofluorescence evidence that shows that each gene is present in the motile cilium.

  • 'occurs in' edge between the individuals that indicate that (anonymous) function of each of these genes occurs in the '9+2 motile cilium'
  • 'part_of' edge between 'ependymal cell' and 'lateratal ventricle'

However, I keep finding to redundant and really time consuming that I have to add the same evidence 3 times for something that isn't separable. In an experiment like this, the fact that the cililum is part of an ependymal cell that is part of a lateral ventricle is not shown by immunofluorescence, but is basic info based on the experimental setup, i.e. what tissue was used for the experiment.

Copied from original issue: geneontology/noctua#420

@kltm
Copy link
Member Author

kltm commented May 26, 2017

@krchristie As stated, I'm not sure if this is a modelling issue (pinging @cmungall @vanaukenk @ukemi) or a use case for the template mechanism that is outlined #231 .

@kltm kltm added the question label May 26, 2017
@kltm
Copy link
Member Author

kltm commented May 26, 2017

From @cmungall on May 9, 2017 4:49

This is a curation best practice question.

I would opt for not including evidence, and taking these as given. This is analogous to what we do now for c16, and I would assume that the evidence should not be required to get the CL class into c16 -- see #418 for general issues regarding GAF export. We should do an experiment and test this is rendered to GPAD as expected.

@kltm
Copy link
Member Author

kltm commented May 26, 2017

From @vanaukenk on May 11, 2017 13:41

We may want to work through a few more use cases here to agree on best practices. I have models where I have experimental evidence that a gene/product is expressed in a given cell or tissue (e.g. by a promoter reporter fusion) but only ISS or IC evidence for a specific CC. Sometimes, the supporting evidence for these two statements comes from different papers.
I would like to be able to include both pieces of information in the GO-CAM model, but if the evidence for the two statements is different, we may need to restrict the GPAD export to the CC annotation only, without the accompanying cell/tissue in C16.

@kltm
Copy link
Member Author

kltm commented May 26, 2017

From @krchristie on May 16, 2017 16:0

I agree that we may not always want to tie things specific things together, but this is a situation that comes up a lot for mouse, and it is tedious to add the evidence in triplicate for something that is not separable in this particular experiment.

In moving forwards as part of being more specific with the evidence, it might be worth thinking of giving the curator some options to decide which things are tied together based on the same evidence.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant