composite-metazoan: review use cases, strategy

[cmungall]

CM is incredibly ambitious. It attempts:

• to account for every single ID in every single ontology
• to retain all axioms from those ontologies (as GCIs, if term merged)
• to try and make a single consistent coherent structure despite the fact that the underlying ontologies are massively different in design
• to do the merge in automated way

Note that it is not the fact that we are integrating across species that is the most ambitious aspect (though that is ambitious). It is the fact that the implicit design patterns are massively different, regardless of species differences. Seemingly minor modeling differences (e.g. treatment of X vessel vs X vasculature) can lead to big complications when making a single consistent structure.

we are forced to remove the strict disjointess axioms from uberon but even then there are things that look odd

Additionally a lot of the code is old owltools code and hard for people to mentally reason about

We should review use cases and see if we can explore simpler strategies, perhaps splitting CM into two files, one more minimal and coherent and the other maximal and experimental

• reduce number of species
• exclude intermediate classes, if the main use case is leaf classes

We can also experiment with more pre-empting slurping - if more leafy classes are given uberon IDs and put in the main ontology then they become more visible to normal automation and manual QC workflows

[github-actions]

This issue has not seen any activity in the past 6 months; it will be closed automatically in one year from now if no action is taken.

[paolaroncaglia]

@matentzn @cmungall should this ticket be added to the technical board for future action? I know it requires Chris.

[matentzn]

yes, can add to tech

[shawntanzk]

no one will deal with this ticket until there is pressure to do so.

[shawntanzk]

We have collected the composite metazoan tickets under the label 'composite' (might not be complete)
@ANiknejad @jahilton @sbreiff @jenjou @fbastian - you had tickets related to the composite files, could you write a single sentence describing your uses case and maybe even a link to the resource? that would really help us with this. Thanks!

[matentzn]

Yes, @shawntanzk, thank you! We are now elevating the composite files and any issues related to them to high alert! It would really help if we knew exactly which composite files (metazoan? owl or obo?) you are using and for what exact purpose!

[jenjou]

could you write a single sentence describing your uses case and maybe even a link to the resource?

I'm not sure I can share the link to the file we generate using composite-metazoan.owl itself, but this is the script that we use to parse the file: https://github.com/ENCODE-DCC/encoded/blob/dev/src/encoded/commands/generate_ontology.py

To summarize it, we take composite-metazoan.owl (along with owls from a few other ontologies) and extract each term in the file. For each term, the script partially traverses the graph to collect the related terms, and stores some of the defined relationships (e.g. part of) that are most relevant for our needs. It produces a large JSON file at the end with all the terms.

We encountered an issue with the composite file where some of those relationships disappeared unexpectedly. It appeared to only be affecting relationships between CL and UBERON terms, which helped us narrow it down to a potential issue with composite-metazoan.owl.

Please let me know if it would help to go into more detail!

[matentzn]

Thank you very much, that is very helpful!

[github-actions]

This issue has not seen any activity in the past 6 months; it will be closed automatically one year from now if no action is taken.

[anitacaron]

@gouttegd was this included in PR #3129?

[gouttegd]

Not really. The only aspect that #3129 addresses is this one:

Additionally a lot of the code is old owltools code and hard for people to mentally reason about

OWLTools is no longer used anywhere in the composite-* pipeline. It’s all ROBOT, with the Uberon-specific code all grouped in a single ROBOT plugin that should be easy to maintain and evolve (well, “easy” if you don’t mind playing with the OWL API).

As for the rest:

We should review use cases and see if we can explore simpler strategies

Since this ticket has been opened two years ago, only one user of composite-metazoanhas bothered to chime in to let us know what their use case is. How are we supposed to “review use cases” that we are not even aware of?

This is not a technical issue. It’s nothing the “tech group” can do anything about. It’s primarily up to the Uberon stakeholders to decide what they want/need composite-metazoan to be, and then we (the “tech group”) can start thinking about how to do it. But that’s assuming said stakeholders actually care, which, if this ticket is any indication, they don’t.