implement objectUnionOf

[goodb]

If it would be possible to add support for the ObjectUnionOf construct during ontology classification it would be a big help to the Gene Ontology group. See geneontology/go-ontology#14984 (comment) for more details.

[ykazakov]

Some (harmless) occurrences of ObjectUnionOf are already supported by ELK. For example it is possible to say "A or B is-a C" (which is short for "A is-a C" and "B is-a C"). An example of unsupported use of ObjectUnionOf would be "A is-a B or C". I need to see an example of inference in your case to understand if it is harmless or not.

Unfortunately, full support of ObjectUnionOf is not easy, and would require a completely different algorithm. In general, ObjectUnionOf causes intractability (and with unrestricted role chains, undecidability) of the logic, which means that, the implementation could be much slower. Long time ago we did some test implementation (see the paper), but we did not find a sufficient number of use cases to evaluate whether this approach is practical. There are not many ontologies available that use ObjectUnionOf in some non-trivial way.

[goodb]

Hi @ykazakov . I believe our current representation falls into the 'harmful' category above. I'm attaching two mini ontology examples here. The one titled "GO_LRUnion_Example.ttl" reflects what we think is the correct representation (from the biochemical perspective) but results in problems for ELK because of the use of objectunion. (Note: this little example classifies correctly with Hermit v 1.3.8.413 but Hermit can't finish on the full Gene Ontology.) The other ontology "GO_NoLR_Example.ttl" provides a simpler representation that works with ELK (no union used), but results in an incorrect inference (GO_0047863 should not be a subclass of GO_0004452).

To give a little context, we are trying to represent biochemical equations in OWL here. The idea is that these classes are determined by the composition of the two sides of the equation e.g., (A + B = C + D). The tricky part is that there is no stable way to determine which side of the equation is which. (C + D = A + B) is the same equation as above. If we just say that the class is determined by the presence of two specific sets without specifying a 'side' as in the NoLR example, we get problems like this (which you can see if you run a reasoner on that ontology):

eq 1: (A) = (B)
eq 2: (A, B) = (C, D)
incorrect inference eq2 subclass of eq1

We can fix that by asserting a specific side for each set (changing the property has_substance_bag to has_left_substance_bag and has_right_substance_bag). But then, we need the union because we can't be sure which side is which..

Hope that makes sense and perhaps provides you with a useful use case for future work. Any feedback greatly appreciated. Apart from advancing the reasoner capabilities, maybe there is another less computationally expensive representation we could come up with to solve the problem.

GO_examples.zip

[ykazakov]

Thanks for the detailed example! I think I understand the problem. Indeed, the use of ObjectUnionOf in your example is non-trivial.

I am, however, not completely sure you need to model equations using ObjectUnionOf. As far as I understand, if you have an equation (A) = (B) then it means that it can be applied in both directions (A) => (B) and (B) => (A). This looks like a conjunction to me. What if you describe it something like:

Equation and hasApplication some (hasInput some (Set and hasElement some A) and hasOutput (Set and hasElement some B)) and hasApplication some (hasInput some (Set and hasElement some B) and hasOutput some (Set and hasElement some A))

So, essentially, the same encoding that you have but ObjectUnionOf replaced with ObjectIntersectionOf.

I think this encoding should have a desired effect:
in this example:
eq 1: (A) = (B)
eq 2: (A, B) = (C, D)
it will not classify eq2 as subclass of eq1

in this example:
eq 3: (A) = (B)
eq 4: (A, C) = (B, D)
it will classify eq4 as subclass of eq3

[goodb]

I tried it, but seems to behave like the NoLR example above. See attached - maybe I didn't translate correctly? I just changed the OR to an AND. ELK works on this one, but I still get that incorrect inference.

Also not quite sure that the semantics are what we need. I think your interpretation is correct "(A) = (B) then it means that it can be applied in both directions (A) => (B) and (B) => (A). " but a problem I see is that one of our use cases is to classify reaction instances that are only represented going in one direction, hence they they wouldn't have all the conditions to be classified correctly. We could automatically add the reverse direction for all of the instances we wanted to classify to solve that problem I suppose, just seems a bit verbose. Maybe that is the correct consequence of the bidirectional semantics.. I guess I don't like it so much because while the principle of bidirectionality is sound, in practice we usually work in one direction at a time - so an instance of a reaction could be said to be going in just one direction, yet we would still want it classified as a member of the master reaction set.

GO_LRUnion_Example_TEST1.ttl.txt

[ykazakov]

I was wrong. Switching OR to AND is not enough for your translation. Notice the property "hasApplication" in my translation. You do not not have it in GO_LRUnion_Example.ttl. This property is used to separate the two directions of the reaction. Otherwise a reaction would just have two left-hand sides and two right-hand sides. I adjusted your example according to my proposal and it seems to get the classification that you expect (provided, I did not mess up the braces - please double check).

GO_LRIntersection_Example.ttl.txt

Regarding the semantics, it depends on what exactly you want to represent.

• Variant 1: (A) = (B) is a reaction that can be applied in both directions. Then I think my translation is accurate.

• Variant 2: (A) = (B) is a reaction that can be applied in one of the directions (but this direction is unknown). Then this corresponds to your translation in GO_LRUnion_Example.ttl

Now, regarding the classification of reaction that go in one direction with respect to two variants above. If (A) => (B) denotes a reaction can be applied from left-to-right then the difference will be that the reaction (A) = (B) in Variant 1 will be a sub-class of (A) => (B), but (A) => (B) will be a sub-class of the reaction (A) = (B) in Variant 2. Note that the semantic in OWL is open world, which means that (A) => (B) describes a reaction that can definitely be applied from left-to-right, and does not mean that it cannot be applied from right-to-left. Therefore (A) = (B) from Variant 1 is a sub-class of (A) => (B). The reaction (A) = (B) from Variant 2 is not a sub-class of (A) => (B) because we cannot tell that (A) = (B) can definitely be applied from left-to-right (we do not know the direction). The reaction (A) => (B) (and (B) => (A)) will be a subclass of the reaction (A) = (B) from Variant 2 because it is applied in one of the directions.

[goodb]

Thanks. That explanation helps clarify things for me. Your example worked as predicted (braces lined up perfectly). However, I think that the behavior we want out of this is Variant 2. We want a master grouping reaction (A) = (B) that has subclasses (A) =>(B) and (B) => (A). Without using union, perhaps another option is to assert the subclasses directly, e.g., for all (A) = (B) reactions manually add subclasses (A) =>(B) and (B) => (A). ?

[ykazakov]

The translation I described allows you to classify the "symmetric" reactions, e.g., obtaining that (A, C) = (B, D) is a subclass of (A) = (B), and avoiding unintended inferences like (A,B) = (C,D) is a subclass of (A) = (B). The translation can use any other property in the place of "hasApplication", and you can freely define the intended meaning of the "directions of the reaction" that this property specifies. For example, instead of "hasApplication" you can use "hasPotentialApplication", which could mean that the reaction can potentially (but not certainly) be applied in this direction. Then, to define the reactions whose directions are certain, you can use another property, say, "hasDefiniteApplication" asserted as a sub-property of "hasPotentialApplication", and use that for directions of the reactions that are definitely applicable. For example, the definition for the reaction (A) => (B) will be like:

Equation and (hasDefiniteApplication some (hasInput some (Set and hasElement some A) and hasOutput (Set and hasElement some B))) and (hasPotentialApplication some (hasInput some (Set and hasElement some B) and hasOutput some (Set and hasElement some A)))

Notice that you will still need a conjunct for the opposite direction with "hasPotentialApplication". Otherwise (A) => (B) will not be classified under (A) = (B). That maybe look not very nice, but at least it shows that what you want is achievable without using disjunctions. Notice that this way you still get an inference, for example, that (A) => (B) is a subclass of (A,C) => (B,D), but it will not be a subclass of, say, (A,B) => (C,D).

[cmungall]

Just back from 2 weeks off and have not digested the full discussion above so may be missing some thing

for the particular design patterns we have, can we use SubPropertyOf to get the inference?

E.g

• has-left SubPropertyOf has
• has-right SubPropertyOf has
• X = has some A and has some B
• X1 = has-left some A and has-right some B
• X2 = has-left some B and has-right some A

Should entail X1 SubClassOf X and X2 SubClassOf X

Formally weaker than a union but should suffice for basic classification purposes

[goodb]

I think you would still generate the incorrect entailment:
(A,B) = (C,D) is a subclass of (A) = (B)

X = has some A and has some B
X1 = has-left some A and some B, has-right some Z
X1 subclass of X because X1 has-left->has some A and X1 has-left->has some B

I think you need the additional edge referred to above as 'hasApplication' to group the sides of the reactions to avoid the mixing.

[cmungall]

OK, but isn't this an issue regardless of directionality?

My thinking here was a kind of weak closing of worlds, where we would indicate the number of types of substance on each side. This would not be complete for reasoning purposes, but would block unintended inferences, and still allow classification under "open structures".

[goodb]

I'm not really following you. It is possible to avoid that incorrect inference via either the disjunction or the pattern @ykazakov proposes. @cmungall could you explain further?