Include SubObjectPropertyOf axioms when reducing.

[gouttegd]

Resolves [#1014, #1208]

• docs/ have been added/updated
• tests have been added/updated
• mvn verify says all tests pass
• mvn site says all JavaDocs correct
• CHANGELOG.md has been updated

This PR amends the Reduce code to include SubObjectPropertyOf and SubPropertyChainOf axioms in the graph used to evaluate redundant axioms.

By including SubObjectPropertyOf axioms, if we have something like

SubClassOf(C, P some D)
SubClassOf(C, Q some D)
SubObjectPropertyOf(Q, P)

then the first SubClassOf axiom can be considered redundant and removed (#1208).

By including SubPropertyChainOf axioms, if we have

SubClassOf(C, P some D)
SubClassOf(C, P some E)
SubClassOf(D, Q some E)
SubObjectPropertyOf(ObjectPropertyChain(P Q) P)

then the second SubClassOf axiom (SubClassOf(C, P some E)) can be considered redundant and removed (#1014).

[gouttegd]

@cmungall Asking for your review since you wrote the original code for the Reduce operation (and you also wrote commit cdbb804, which restricted the types of axioms considered for evaluating redundancy).

@jamesaoverton Should the behaviour be configurable by a new command line option to reduce (something like --include-subproperty-axioms true or similar)?

[matentzn]

This change is very consequential - and I am actually a bit surprised that this was not already happening.

I would, however, suggest to add a test for this change, as it has the potential for huge consequences on a lot of OBO (esp. ODK-managed) ontologies..

[gouttegd]

@matentzn I plan to add tests once I have confirmation the feature (which is more of a bug fix in my opinion, as I think reduce should always do that -- which is also why I didn't include an CLI switch) is wanted. :)

[matentzn]

I personally agree that this is a bugfix, but best get @balhoff and @cmungall opinion on this as well.

[gouttegd]

I personally agree that this is a bugfix

For what it’s worth, the people who reported the #1208 issue (reduce ignoring SubPropertyOf axioms) and the #1014 issue (reduce ignore property chains) both thought it was a bug. :)

[cmungall]

Why not just add a reduce configuration, and preserve the current default behavior?

Redundancy is not straightforward, see:

• vocabulary for different kinds of redundancy/inference at graph and owl level INCATools/relation-graph#63

Apologies for any confusion caused. When I originally proposed this:

• Add op: remove-redundant-axioms #16

I suggested separate commands from removing redundancy (sensu OWL entailment) and graph transitive reduction, we probably should have stuck to that (with graph operations happening in a framework independent of the owlapi / owl reasoning), as these are really different concerns and use cases. But I think I may have overloaded them.

[gouttegd]

@cmungall I don’t mind making the behaviour configurable by a command-line option, but I defer to @jamesaoverton for the decision.

Personally, I think that, if the behaviour is to be made configurable, it should still be enabled by default, with an option to disable it. For two reasons:

(1) There is nothing in the description of reduce to suggest that it is normal for subproperties (and property chains) to be ignored when evaluating redundancy. As I mentioned, both the authors of the #1014 and #1208 tickets considered that to be a bug (and FWIW I agree with them).

(2) This would be consistent with the existing options --named-classes-only and --preserve-annotated-axioms: by default, reduce removes everything it can, unless its behaviour is restricted by an option.

[balhoff]

I think it sounds good to have this feature, but it should be added as a non-default CLI option. We have been relying on the previous behavior, at least in GO, to materialize more standard relations from highly specific ones (e.g. 'part of' from 'bounding layer of') using a combination of materialize and reduce. My understanding is that this would stop working after this change.

[gouttegd]

@balhoff Option tentatively added. :) I defer to @jamesaoverton for the decision as to whether it should be enabled or disabled by default (for now it’s disabled, it’s one line to change in ReduceOperation#getDefaultOptions() if we want to make it enabled by default).

[jamesaoverton]

I agree with @balhoff: we should stick to the old behaviour by default, to maintain backwards compatibility, even if we agree that the old behaviour was buggy. (Sorry, but backwards compatibility is very important to the ROBOT project.)

Thanks very much!

[gouttegd]

@jamesaoverton Fine with me. :) But for the record, I then plan to enable the option by default in ODK workflows (users would still have the possibility to disable it in their ODK configuration).

[cmungall]

I really like this general pattern (robot is rigorous about backward compatibility, ODK may override)

…

On Mon, Mar 10, 2025 at 2:23 PM Damien Goutte-Gattat < ***@***.***> wrote: @jamesaoverton <https://github.com/jamesaoverton> Fine with me. :) But for the record, I then plan to enable the option by default in ODK workflows (users would still have the possibility to disable it in their ODK configuration). — Reply to this email directly, view it on GitHub <#1248 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAMMOPF7NJGJR6YU55OFLT2TX7FNAVCNFSM6AAAAABYP5IHXCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOMJRHA3TIMBUGI> . You are receiving this because you were mentioned.Message ID: ***@***.***> [image: gouttegd]*gouttegd* left a comment (ontodev/robot#1248) <#1248 (comment)> @jamesaoverton <https://github.com/jamesaoverton> Fine with me. :) But for the record, I then plan to enable the option by default in ODK workflows (users would still have the possibility to disable it in their ODK configuration). — Reply to this email directly, view it on GitHub <#1248 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAMMOPF7NJGJR6YU55OFLT2TX7FNAVCNFSM6AAAAABYP5IHXCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOMJRHA3TIMBUGI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

This request has been implemented: the old behaviour remains the default.