pombase / fypo

Fission Yeast Phenotype Ontology
Creative Commons Attribution 4.0 International
15 stars 6 forks source link

elongated cell phenotypes #611

Closed fypoadmin closed 9 years ago

fypoadmin commented 11 years ago

should elongated mononucleate aseptate cells be a child of elongated inviable vegetative cells

(this is from a discussion with Antonia)

elongated mononucleate aseptate must always be inviable?

Original comment by: ValWood

fypoadmin commented 11 years ago

I am now struggling with this. I think when the cell phenotype elongated mononucleate aseptate occurs this is always inviable..... but if not all of the cells in the population have this pehenotype, this does not make it an inviable phenotype right?

Would it be better to have elongated mononucleate aseptate and elongated mononucleate inviable aseptate. (I think there may be 2 distict variations of this phenotype, one which is fully penetrant and inviable, and one which throws off the odd elongated cell with low penetrance and the arrested cell is inviable but the rest of the population is viable)

After the next update we can check the annotations to both (I will look to see if elongated mononucleate aseptate is always fully penetrant?

Does that make sense?

I think there is a similar issue with "cut" we have this as an inviable phenotype. Probably this means that the cells which display "cut" phenotype are inviable, but that the population may not be inviable, should we remove "inviable" from this phenotype?

I guess my question is, when we refer to viability should we always be thinking about the population, not an individual cell

Original comment by: ValWood

fypoadmin commented 11 years ago

This came to me by email but isn't showing up here, so trying again ...

Viability is defined as a cell phenotype, i.e. a phenotype that applies to a cell. (In theory you can see it even if you only look at one cell.) So,

but if not all of the cells in the population have this pehenotype, this does not make it an inviable phenotype right?

wrong ...

If every cell that is elongated, mononucleate, and aseptate is also inviable, then we can add the link in the original summary. It doesn't matter whether every cell in the population is (elongated + mononucleate + aseptate +inviable) or not; we only need two separate terms if an individual cell can be (elongated + mononucleate + aseptate + viable).

Penetrance is orthogonal to the phenotype definition itself. If the second variant you mentioned has some cells that are (elongated + mononucleate + aseptate + inviable) and others that are viable, but the viable ones aren't (elongated + mononucleate + aseptate), then you have (elongated + mononucleate + aseptate + inviable) with incomplete penetrance.

should we remove "inviable" from [cut]?

No, because every cut cell is inviable.

I guess my question is, when we refer to viability should we always be thinking about the population, not an individual cell

And my answer is "no". For viability/inviability (and for any other cell-level phenotype), looking at the population will tell you about penetrance.

Original comment by: mah11

fypoadmin commented 11 years ago

OK, this all makes sense for the above and I can see completely now that "cut" and "elongated vegetative aseptate" should have inviable parentage, because when this phenotype occurs they are always inviable

After the next update we should have a look:

  1. How many cuts intersect with viable and then check if we should add "low penetrance" to the cuts.
  2. How many "elongated vegetative aspetate" intersect with "viable". This should enable us to predict which are "high penetrance", and which are "low penetrance", and if this is not recorded, to check and add it.

My only remaining issue is that for say, the genome wide deletion collection, when we called "inviable" we meant that the population was inviable. How should we capture this with the current system?

Should we i) Add a penetrance to all of these "high" to all of these (this could be done automatically for the inviable from this PMID), or even add another penetrance term "complete" for cases when 100 % of the population displays a specific phenotype? Or ii) Have an inviable population level term? which it seems is semantically equivalent to a cell level phenotype with complete penetrance?

Suggestions?

Original comment by: ValWood

fypoadmin commented 11 years ago

Surely if the whole population is dead, that's inviable at 100% penetrance?

And it'd be easy to add a term for complete/100%, is_a high, to the mini-ontology.

Original comment by: mah11

fypoadmin commented 11 years ago

I think an extension for complete could be useful, lets add that. It is going to be a querying nightmare for people to get inviable/ viable lists as we will really need access to the penetrance in the query interface to do this properly but we can worry about that later.

Do increased necrotic cell death increased apoptocic increased autophagy have inviable parentage?

Original comment by: ValWood

fypoadmin commented 11 years ago

None of them do at the moment, and increased autophagy definitely shouldn't (because autophagy doesn't always lead to cell death).

Increased necrotic cell death is directly under abnormal cellular process now, so moving it wouldn't cause much upheaval. How much do we need it or increased necrotic cell death, anyway? I think I added it because SGD has analogous phenotypes, but we don't have to keep absolutely everything they've got, and they don't have the same parentage and reasoning worries that we do.

Increased apoptosis is a tough one, because it has a parent (abnormal apoptosis) and siblings (decreased, abolished) that obviously shouldn't go under inviable. Maybe a has_output link?

This reminds me of [#538], and has renewed my sense that there's a danger of overcomplicating viability

...And this has strayed a long way from the original question, which I think is "do you ever see a cell that is elongated, mononucleate, aseptate, and viable?"

Original comment by: mah11

fypoadmin commented 11 years ago

OK summary of ToDo for this item... i) OK re autophagy ii) I don't think we need term "necrotic " term, I have never some across it. obsolete? iii) add extension for "complete" penetrance iv ) "elongated mononucleate aseptate", vegetative cells I am pretty confident are always inviable so this term parentage/name should reflect this. Any terms which specify viable can be obsoleted, and any terms which specify neither can be merged. vi) val to add SF tracker item for global addtion of "complete penetrance" extension to all genome project inviable/viable deletions vii) Val to check elongated/monunucleate apseptate and cut annotations in V 33

Original comment by: ValWood

fypoadmin commented 11 years ago

ii) done iii) done in the relevant mini-ontology iv) there's only the one term (FYPO:0000839), so I added a link that gives it a path to inviable

Original comment by: mah11

fypoadmin commented 11 years ago

Diff:


--- old
+++ new
@@ -1,4 +1,3 @@
-
 should
 elongated mononucleate aseptate cells
 be a child of

Original comment by: ValWood

fypoadmin commented 11 years ago

I am trying to assign this to me to complete the ticket (I don't know if this will work)

Also, this might be a dim question, but does everything which has the parentage to viable mention that it is an viable phenotype in the def?

Original comment by: ValWood

fypoadmin commented 11 years ago

does everything which has the parentage to viable mention that it is an inviable phenotype in the def?

one way or another, yes (in some cases the wording is "dies")

Original comment by: mah11

fypoadmin commented 11 years ago

am I right in thinking there's no more to do on the ontology for this, and it's still open for annotation review?

m

Original comment by: mah11

fypoadmin commented 11 years ago

Original comment by: mah11

fypoadmin commented 11 years ago

Original comment by: mah11

fypoadmin commented 11 years ago

Original comment by: mah11

fypoadmin commented 9 years ago

Original comment by: mah11

fypoadmin commented 9 years ago

last activity 2 years ago; must be superseded by curation-tasks tickets

Original comment by: mah11