Creation of ENVO planned process DOSDP

[kaiiam]

Following from the discussion in #932, @pbuttigieg called for the creation of a planned process DOSDP. @cmungall suggested it have the following structure:

planned X = planned process and X

e.g. planned deforestation

with equivalence class:

'planned process'  
    and deforestation

[pbuttigieg]

Thanks @kaiiam - note that it's more...

Equivalence

P and (realizes some (concretizes some 'plan specification'))

With textual def in the form

P which is planned and executed by humans.

Inference should then place it under `planned process' due to its equivalence axiom: http://purl.obolibrary.org/obo/OBI_0000011

[kaiiam]

Thanks @pbuttigieg for weighing in. I believe the DOSDP's input csv file would need to be something like the following:

defined_class	defined_class_label	process_class	process_class_label
ENVO:01001435	planned deforestation	ENVO:02500012	deforestation

Inference should then place it under `planned process' due to its equivalence axiom: http://purl.obolibrary.org/obo/OBI_0000011

@pbuttigieg I'm not seeing how that would work as described with P and (realizes some (concretizes some 'plan specification')) as equivalence axiom. I tried running it with ELK and I only saw the inference when I explicitly put planned process into the axiom.

I.e. the axiom 'planned process' and deforestation worked to infer subclass whereas deforestation and (realizes some (concretizes some 'plan specification')) didn't.

[kaiiam]

Do we want an equivalence axiom like the following?:

'planned process'  
    and deforestation 
          and (realizes some (concretizes some 'plan specification'))

When reasoned using ELK, this infers planned deforestation to be subclass to planned process

[kaiiam]

Examining OBI's planned process They already have the equivalence axiom realizes some concretizes some plan specification. For some reason the version of this class in ENVO edit doesn't have this axiom, maybe an import chain e.g. envo importing an old version from IAO? However, if we were importing the latest from OBI, we'd already have that realizes some ... axiom so we wouldn't need to add it to ours like above and I think @cmungall's original suggestion of 'planned process' and deforestation would be sufficient.

[kaiiam]

Yes as I suspected the version of planned process in the iao_import.owl import is missing the equivalence axiom. @cmungall how do we prevent these kinds of cross imports from occurring? Is there a way to explicitly state (in a make file or something) not to import x class in y import.owl? Maybe it's not needed in this case as long as we're pulling the latest from OBI?

[pbuttigieg]

@kaiiam

@pbuttigieg I'm not seeing how that would work as described with P and (realizes some (concretizes some 'plan specification')) as equivalence axiom. I tried running it with ELK and I only saw the inference when I explicitly put planned process into the axiom.

I think that's because the ENVO import of planned process doesn't have its equivalence axiom imported along with it, so running the reasoner in ENVO won't pick it up.

I.e. the axiom 'planned process' and deforestation worked to infer subclass whereas deforestation and (realizes some (concretizes some 'plan specification')) didn't.

Yes, that would work (in a trivial sense) because you're effectively asserting it as a subclass of planned process by having it on the LHS of the "and"

But that's effectively multiple inheritance rather than population by inference, so I don't see it as desirable.

Examining OBI's planned process They already have the equivalence axiom realizes some concretizes some plan specification.

Yes, that's why the equivalence axiom originally suggested should work, if the equivalence axiom was imported (see below)

For some reason the version of this class in ENVO edit doesn't have this axiom, maybe an import chain

I believe this is the default behaviour for imports - we don't want all of their equivalence axioms coming along for the ride as they may reference terms that we don't import, causing issues.

We have to decide if we want/need an exception in this case and then @cmungall would need to let us know if that's wise.

I'd be fine with just setting up the equivalence axioms ENVO side. Even if the terms aren't inferred under planned process in ENVO, they would be if someone build an application/specialist ontology using OBI and ENVO. There's no strong need to have these under planned process in ENVO itself.

I also don't see any equivalence axioms in the OBI import.

[kaiiam]

I believe this is the default behaviour for imports - we don't want all of their equivalence axioms coming along for the ride as they may reference terms that we don't import, causing issues.

I'm confused about this because for example when I import ENVO concentration terms into my ODK created application ontology, the equivalence axioms are imported. I did a little experiment re-running ENVO's OBI and IAO imports to see if it would fetching the OBI:planned process equivalence axiom, it doesn't, but it does bring in the equivalence axiom from OBI:organism.

That aside I'll try to figure out how to make the DOSDP as @pbuttigieg describes above.

[pbuttigieg]

That's strange - did you compare the parameters for the imports in the Makefiles?

[kaiiam]

In the Makefile the mirror/obi.owl: envo-edit.owl has the flags --remove-axiom-annotations and --remove-annotation-assertions perhaps one of these this removes equivalence axioms? However, it doesn't explain why organism has an equivalence axiom and planned doesn't. I can investigate this more later but for now I'll focus on making the DOSDP.

[cmungall]

Note that so far we have only brought in IAO as a metadata ontology.

I would recommend we keep doing this and just adopt a simple `P and 'planned process'' definition for now, for the following reasons:

• adding additional dependencies makes things more fragile
• (realizes some (concretizes some 'plan specification')) is meaningless to normal users, and even to people who have done a lot of ontology work, and is outright confusing
• you lose precisely zero entailments by using my propose logical form. The two are equivalent
• the pattern is likely to change anyway post-COB

[kaiiam]

In that case the plan would be back to the first post @pbuttigieg if that's OK with you I'll try to make it.