frazil + frazile ice both under both material and ABP

[cmungall]

I'm not sure if there an intention for ABP+material to be disjoint, but currently there are only two classes are under both:

small intersections between upper level classes are usually a smell indicating intentional disjointness

Here is frazil and frazil ice

My guess is the intent is FI should be in material and F in ABP?

(and not to be sidetracked, but it's odd how glacial feature floats outside the ABP hierarchy)

[pbuttigieg]

Hmm, this shouldn't be - frazil and frazil ice should just be in the material hierarchy.

Somehow they get trapped in the inferencing due to the partially_surrounded_by some 'liquid water' subclass axiom.

Slightly more involved for cryoform, but still due to the PSB liquid water:

The glacial feature inference still happens, but as that's outside the ABP hierarchy it's expected.

The issue is in the equivalence axiom of hydrographic feature, where the parentheses disconnect the PSB from the geo feature:

[rduerr]

So this is an issue of a misplaced ) ???

On Jun 3, 2020, at 4:26 PM, Pier Luigi Buttigieg notifications@github.com wrote:

Hmm, this shouldn't be - frazil and frazil ice should just be in the material hierarchy.

Somehow they get trapped in the inferencing due to the partially_surrounded_by some 'liquid water' subclass axiom.

https://user-images.githubusercontent.com/2276146/83694374-2e91c900-a5f8-11ea-93e1-aed252141cd7.png Slightly more involved for cryoform, but still due to the PSB liquid water:

https://user-images.githubusercontent.com/2276146/83694581-9cd68b80-a5f8-11ea-84f5-093279be0e29.png The glacial feature inference still happens, but as that's outside the ABP hierarchy it's expected.

The issue is in the equivalence axiom of hydrographic feature, where the parentheses disconnect the PSB from the geo feature:

https://user-images.githubusercontent.com/2276146/83694988-7f55f180-a5f9-11ea-97ce-dfbba07e054d.png — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/EnvironmentOntology/envo/issues/963#issuecomment-638493429, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALZFPD3ZKQQEQTVRP2C3T3RU3EZTANCNFSM4NR5MPXA.

[pbuttigieg]

@rduerr looks like it

[cmungall]

Less disjunctions, more disjointness!!

Another thing triggering me is the only vague connection between textual definition and owl definition

I'll try and make a report showing all potentially suspect equivalence axioms, these are dangerous

On Wed, Jun 3, 2020 at 4:27 PM Pier Luigi Buttigieg < notifications@github.com> wrote:

@rduerr https://github.com/rduerr looks like it

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/EnvironmentOntology/envo/issues/963#issuecomment-638512553, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAMMOO6UKHYGTQUZH4FJ6DRU3L3HANCNFSM4NR5MPXA .

[pbuttigieg]

Another thing triggering me is the only vague connection between textual definition and owl definition

Enhance the expressivity of the system and we'll be closer - but in the meantime we need to log the nuance textually and try to get somewhere close with the axioms we have/can use. We can't change the way communities understand these terms so things look neat.

I'll try and make a report showing all potentially suspect equivalence axioms, these are dangerous

Would be interesting to see - good way to spot where we should push for more relations we can use in non-biomedical applications in RO world.

[cmungall]

On Thu, Jun 4, 2020 at 12:59 AM Pier Luigi Buttigieg < notifications@github.com> wrote:

Another thing triggering me is the only vague connection between textual definition and owl definition

Enhance the expressivity of the system and we'll be closer - but in the meantime we need to log the nuance textually and try to get somewhere close with the axioms we have/can use. We can't change the way communities understand these terms so things look neat.

understand 100%, and I'm not suggesting changing the way the communities understand these, and the text definition should always represent the community understanding in its nuance

However, incorrect equivalence axioms are dangerous - it's almost always better to replace these with subClassOf axiom, especially if they are not doing much reasoning work for us

I'll try and make a report showing all potentially suspect equivalence axioms, these are dangerous

Would be interesting to see - good way to spot where we should push for more relations we can use in non-biomedical applications in RO world.

yep!

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/EnvironmentOntology/envo/issues/963#issuecomment-638678288, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAMMOMJFNGZIKZP43UZY6LRU5H53ANCNFSM4NR5MPXA .

[pbuttigieg]

it's almost always better to replace these with subClassOf axiom, especially if they are not doing much reasoning work for us

Noted with thanks - I'm overly optimistic about the usefulness of these - haven't seen enough catastrophes stemming from them yet, but that's changing fast!

[dr-shorthair]

incorrect equivalence axioms are dangerous - it's almost always better to replace these with subClassOf axiom

Thoroughly agree. Things coming in from different places are more often sub-classes in one direction or other.

[cmungall]

Thoroughly agree. Things coming in from different places are more often sub-classes in one direction or other.

Definitely - but to be clear we may be agreeing about two different scenarios

I think you may be referring to an equivalence axiom between a pair of namedClasses. (we lack good terminology, I say NC-Equivalent-NC). Generally we'd never see this within an OBO (e.g we'd never have ENVO:1 = ENVO:2)

We also have checks to prevent unintentional inferred equivalence - see the robot reason docs http://robot.obolibrary.org/reason

We'd also rarely have NC-Eq-NC between two OBO classes, but this does happen (e.g. GO:cell=CL:cell).

Things get interesting when we talk about NC-NC-Equivs across disparate ontologies. Much has been written in the semweb community on problems with owl:sameAs... a lot of which I disagree with. When crossing between an OBO and an external ontology, it can be useful to be bold and state an equivalence axioms over a weaker skos axiom, this can have unintentional consequences when reasoning over the union, there is a lot more to be said here. Our kboom approach uses probabilistic owl reasoning to figure out optimal merges between different ontologies: https://www.biorxiv.org/content/10.1101/048843v3

The scenario here is a "defining OWL axiom" or "logical definition". This is more of an OBO vernacular term, formally it is an equivalence axiom between a named class (the class being defined) and an anonymous class expression, where the purpose of the axiom is provide necessary and sufficient conditions a reasoner work with. NC-Equiv-Anon. Frequently in OBOs the class expression is of genus differentia form. i.e Genus AND R some Y AND R2 some Y2...

These are incredibly useful for compositional concepts. E.g. "blue car" = "car and has-color some blue". See Rector Normalization Technique. But they can be dangerous if the class expression is even the tiniest bit more general than the intended expression, because you end up over-classifying under the defined class. This can be a bit unintuitive, because normally in an ontology it's OK to be a bit more general and leave things out. One way to think about this is that A=B <=> A sub B, B sub A.

More thoughts on definitions here (heavily cribbed from an excellent paper by Selja Seppälä, Barry Smith, and Alan Ruttenberg):

https://douroucouli.wordpress.com/2019/07/08/ontotip-write-simple-concise-clear-operational-textual-definitions/

Sorry, I hijacked our frazil to hold forth on a favorite topic, back to your regular scheduled programming....

[kaiiam]

xref to my ENVO SWEET Cryosphere mapping. Perhaps something that could be dealt with during the upcoming ESIP summer meeting semantic harmonization session? Or is this too technical and deep in the weeds for that venue?