Synchronization: subClassOf axioms (MVP)

[joeflack4]

Overview

Take subClassOf of all the sources, and then migrate them. This entails a robot template that has all subClassAxioms of the source.

There should be a way to exclude subClassAxioms (explanation in comment below).

We don't want more python files being generated get a click CLI (tangent; explanation in comment below). Make a CLI.py that has a sync command. And that sync command has a subcommand which is subClassOf.

FYI, Nico will be migrating lots of Python stuff to this Click cli (e.g. mondo-ingest CLI).

Click boilerplate:
What am using as boilerplate: This is what I am using as boilerplate: https://github.com/monarch-initiative/pheval/blob/main/src/pheval/cli.py
what should use: (can't find) official cookie cutter

Sub-tasks: cases

See also

• Google doc about cases
• Cases spreadsheets on Google Drive

Cases

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10

Sub-tasks

• 1. Robot template
• 2. CLI (click based) (moving to a separate PR
• 3. Synchronization: subClassOf axioms (misc follow-ups) #392

Sub task details

1. Robot template

Columns:

• term_id: ID - a mondo id
• parent_id: rdfs:subClassOf - a mondo id
• xref: ? (dk property; nico can fill in; for now maybe I can useA oboInOwl:hasDbXref; idk if it needs a > at beginning) - e.g. a DO identifier

Related

• Synchronization #87
• Plan for full Symbiont pipeline (incl publication plan) #27

[joeflack4]

edit: updated contents of this comment into the OP

[joeflack4]

@matentzn I re-read instructions for this. I dictated during a meeting last March. Want your input on a couple things.

1. This part is unclear to me:

There should be a way to exclude subClassAxioms. We don't want more python files being generated...

I understand the need for the robot template. But (1.1) by 'exclude', I don't know what's being asked of me here, if anything.

Also, (1.2) regarding "don't want any more Python files being generated", I don't know how that applies here. Do you remember what we were thinking about here ? I could (a) write a Python script to make the robot template, etc (easiest thing), or (b) I could do things in make/ShellScript. But this anit-Python statement also is in conflict w/ the ask for a click CLI.

2. Do I have the right idea regarding robot template format?

2-col robot template w/ term_id and parent_id.

[joeflack4]

Met with Nico today. His answers are in this comment and the one below.

There should be a way to exclude subClassAxioms.

There's an input to this process. A set of excluded sub class axioms that should not show up. There will be an input table; its purpose to document the excluded classes. How to generate: query in sparql for excluded subclass. Open Mondo to find the IRI for that. Use that to make a sparql query to get the excluded classes. should have parent and child. Anything that is that combo of parent and child, i will filter out to not appear in robot template.

[joeflack4]

We don't want more python files being generated...

Less python script run manually e.g. via goals, and we want to move towards pip installing mondo-ingest. And then we run everything via click.

One place for these moving forward. Modular. Testable.

[matentzn]

The goal of this issue is to synchronise the subclass axioms from the external sources with Mondo. For example, if DO has added a subclass axiom between :A and :B, then we should (consider to) as well.

Three important concepts to understand before you read on:

• "asserted" means the axiom is physically in the ontology (in OAK, this corresponds to direct parents)
• "implied" means that the axioms is not asserted, but can be inferred through simple graph walking (on OAK, this corresponds to ancestors minus direct parents)
• "supported" means "asserted or implied".

This is the rough approach:

INPUTS:

1. mondo
2. mondo-ingest (maybe individual components?, not sure)
3. mondo.sssom.tsv
4. (excluded subclass of will be supplied by mondo itself)

OUTPUTS (for now, there will be quite a few before we are done).

1. source.subclass.confirmed.robot.tsv (e.g. ordo.subclass.confirmed.robot.tsv). This is the set of subclass axioms that are asserted in mondo and supported the source, e.g. ordo. If the axioms is asserted by the source, follow the "both asserted" pattern in the google doc ("Axiom is in both Source and Mondo."). If the axiom is implied by the source, follow the "source implied" ("Axiom is not in the source, but implied by the source, and asserted in Mondo.") pattern for the ROBOT template.
2. source.subclass.added.robot.tsv (e.g. ordo.subclass.added.robot.tsv). This is the set of subclass axioms that are not supported by Mondo, not excluded by Mondo, but are supported by the source.

Rough approach (could be wrong/incomplete):

1. Get all subclass axioms |S(A,B)| from the external sources (you did something like that for migrate command, and I think even deprecate-mapped.
2. For all axioms S(A,B) in |S(A,B)|, you map A to Mondo and B to Mondo using mondo.sssom.tsv, resulting in S(Am,Bm). The set of |S(Am,Bm)| is the set of all "syncable axioms".
3. For all S(Am,Bm) in |S(Am,Bm)| determine which file above (if any) they go to. Ideally, all axioms from the source end up either flagged as "excluded", "included" or "syncable".

[joeflack4]

Ok, this is a much better explanation. If you look at what I wrote at the top of the issue ("1. Robot template
"), it's not even close. Possibly some of my work on this so far was for naught, but a lot should be re-usable. It did seem to me something similar to slurp/migrate would be needed here.

I don't have any questions now until I do my next Mondo block and fully take in everything here, as well as look more closely at the inputs (mondo-ingest.owl or components). I'll get back to you. My guess is we should probably also meet this upcoming Thursday.

[joeflack4]

Gonna ditch terminology inferred/asserted for our purposes. We will think in terms of direct child/parents vs ancestors/descendants.