Set the source of subclass sync to a merged version of edit and owl

[matentzn]

I had a dream last night that this might not be necessary because of the way that semsql works. I dont know exactly what semsql does though, and now that Chris is gone it may be not possible to find out.

Here my dream:

1. semsql is using relationgraph under the hood (that is a fact)
2. RG may, all by itself, remove the red subclass axiom in the figure below, rendering the change in this PR ineffectual

In my view, nothing bad will come of this change, but we need to check manually, later down the line, if subclass assertions in mondo-edit.owl do not get support, even though it exists. We can stem that in a second round I think

Overview

This PR:

• Changes the source of the subclass sync Mondo DB to a version that contains both the release and edit file axioms
• This was discussed and agreed in the last tech call

Pre-merge checklist

Documentation

Was the documentation added/updated under docs/?

• Yes
• No, updates to the docs were not necessary after careful consideration

QC

Was the full pipeline run before submitting this PR using sh run.sh make build-mondo-ingest on this branch (after
docker pull obolibrary/odkfull:dev), and no errors occurred?

• Yes
• No, there are no functional (code-related) changes to the pipeline in the PR, so no re-run is necessary

New Packages

Were any new Python packages added?

• Yes, requirements.txt.full was updated and an ODK issue submitted
• No

Were any other non-Python packages added?

• Yes, Dockerfile updated and an ODK issue submitted
• No

PR Review and Conversations Resolved

Has the PR been sufficiently reviewed by at least 1 team member of the Mondo Technical team and all threads resolved?

• Yes
• No

Sub-tasks

• Ensure this PR is actually useful & doing what it is supposed to
  As @joeflack4 determine in his comment this PR may, after all, be redundant. We need to figure out the following:

1. If a redundant subclass axiom exists in Mondo (red line), will we gather evidence for it?
2. We may have to adjust the code to handle this case if it is not, but we can put this on the list of priorities in the next quarter

[joeflack4]

Ah I see, you merged them, not pass both as inputs. That makes sense.

[joeflack4]

I had a dream last night...

Haha

RG may, all by itself, remove the red subclass axiom in the figure below, rendering the change in this PR ineffectual

Mmm I see.

In my view, nothing bad will come of this change

Only negative is extra build time. Not a huge problem, but more a problem now than before, given how frequently we run them.

but we need to check manually, later down the line

Hmm, we can't check now?
Wouldn't we expect to see an increased number of new subclass relations in the -added template, with this change?
Edit: Hmm, I checked doid.subclass.added.robot.tsv in the build for this PR (#608), and compared it to another recent build (#606), and it had the same number of added subclass relations.

GH issue?: If we can't check it now for whatever reason, we should make an issue to check on this later; that redundant ancestor subclass relations/axioms are being added.

[matentzn]

Only negative is extra build time

I think the extra build time is not so bad as the only redundant step is the robot merge step, which is fast (less than 8 seconds).

Hmm, I checked doid.subclass.added.robot.tsv in the build for this PR (#608), and compared it to another recent build (#606), and it had the same number of added subclass relations.

Thank you for checking that. In this case, lets just hold of on this PR for now and go ahead with what we previously had. Relieves the pressure a bit. I will

1. Set this PR to draft
2. Update the OP with the result of your investigation
3. Schedule the PR for total closing in 2 months if we determine it is actually not needed.