Property chains over develops_from
#814
Assignees
Comments
This was referenced Nov 4, 2024
|
No point in making a “PR” (here or in Uberon) as the effects of the addition or removal of the property chains would not be shown in the diffs (the diffs in use on the Uberon repository are computed over the So I’ll post the diffs here instead. For both chains, I compare (1) Chain (A) 'develops from' o 'part of' SubPropertyOf: 'develops from'Injecting this chain adds 350 inferred classifications:
Chain (B) 'part of' o 'develops from' SubPropertyOf: 'develops from'Injecting this chain adds 1922 inferred classifications:
|
|
@cmungall @dosumis @balhoff ⬆️ Please have a look at the inferred classifications that result from both chains. FWIW, I observe that the vast majority of these classifications involve terms like |
|
Thanks for setting this up, laying it out cleanly, and linking to the relevant ticket. My preference is: remove the property chain in both places. While in the past I have been an advocate of these, balancing coverage vs precision has been hard, especially as a number of structures may have well defined boundaries. And we are entering an age where we should have precise lineage maps at the cell type level, and more precise composition recipes for anatomical structures, allowing more precise answers to the question of how one structure relates to another developmentally (in many cases it will be a complex story, but we will be able to tease it apart to the lineage) In the short term, we will likely have some incompleteness for questions of the form "develops-from some " where X is a multicellular structure, but I am fine with this. Ones like this may look alarming:
But in fact we still retain the correct path to the cell type:
|
Minus the x-derived structure terms:To make these easier to review I stripped out all terms with derived in the name Chain (A) 'develops from' o 'part of' SubPropertyOf: 'develops from'
Chain (B) 'part of' o 'develops from' SubPropertyOf: 'develops from'
|
|
So we currently have one clearly formulated opinion against both chains. I suggest the following:
|
|
Thanks for filtering the list @dosumis - a lot of the remaining ones are still probe classes like "structure with developmental contribution from neural crest" and we have had separate discussions about the utility of endo-ecto epithelium (IMO there are more than enough ways to classify epithelium and we should obsolete these). This is bonkers:
The logical def is absurdly weak id: UBERON:0010312
name: immature eye
def: "Developing anatomical structure that develops into the eyeball and associated structures." [ZFA:0001678]
synonym: "future eye" EXACT []
xref: TAO:0002201
xref: ZFA:0001678
intersection_of: UBERON:0005423 ! developing anatomical structure
intersection_of: has_developmental_contribution_from UBERON:0003071 ! eye primordium
relationship: develops_from UBERON:0003071 {evidence="definitional"} ! eye primordiumThe logical def should be removed, or we should make the immature X terms follow the |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This issue is intended to supersede both #784 and #785, as well as obophenotype/uberon#2723. Those issues are interrelated and I believe it would be clearer to discuss them in a single place.
Current state
Uberon currently injects the following two property chains:
(A) 'develops from' o 'part of' SubPropertyOf: 'develops from'
(B) 'part of' o 'develops from' SubPropertyOf: 'develops from'
(Of note, the chains are injected just prior to reasoning, and are then forcibly removed, so that they are not present in any Uberon released artefacts.)
RO also contains the following related chain:
(C) 'has part' o 'develops from' SubPropertyOf: 'has developmental contribution from'
The question is about the correctness and usefulness of chains A and B.
Stated opinions
@balhoff “I still think both chains are incorrect. In any case the chains should be added to RO to not to Uberon.” src
@cmungall “We agreed a year ago [that woud mean around 2022] to get rid of [chain B], no controversy. Let’s make a separate RO issue for adding the rollification constraint on [chain A].” src Which I take to mean, chain B should not exist at all anywhere (not in Uberon, not in RO), and chain A should be in RO where it may optionally be further refined. The “separate RO issue” is #784, which has not been acted upon yet (likely for lack of clarity of the issue’s message).
Attempt at resolution and objection
Since there was apparent agreement (as stated by @cmungall) that chain B should be removed (“no controversy”), a PR to do just that had been submitted to Uberon (obophenotype/uberon#3197), from where it emerged that, in addition to removing the B chain, the C chain (in RO) should be updated to become
(C’) 'has part' o 'has developmental contribution from from' SubPropertyOf: 'has developmental contribution from'
(This is issue #785, which has not yeen been acted upon.)
But then, @dosumis dissented about the removal of chain B: “We are unsure why this property chain is being removed (apart from that it ultimately should come from RO). It is doing useful work for inference that we likely can’t effectively manage by hand.” src At the same time, he proposed that chain A (the chain that @cmungall wanted to keep and move from Uberon to RO) “should be removed --
has_developmental_contribution_fromis sufficient`”.There thus seems to be a fundamental disagreement about the correctness of the A and B chains. The one non-controversial aspect, I suppose, is that, should they be kept, they should belong to RO and not to Uberon (which is why I created this ticket here rather than in Uberon, where the problem originated).
The text was updated successfully, but these errors were encountered: