Guidance on whether to make redundant assertions between terms in the ontology

[rjyounes]

Some examples of redundant assertions which are currently not included in the ontology but are left to inferencing:

• inverseOf on both of the inverse properties, rather than just one
• A and B are inverses, A has range r, we don't explicitly assert B has domain r.
• A1 and A2 are inverses, B1 and B2 are inverses, B1 is a subproperty of A1, therefore B2 is a subproperty of A2

Pros for leaving the redundancies to inferencing:

• Eliminates redundancy (sounds circular, but the point is this is a fundamental principle, other things being equal)
• Reduces the number of assertions in the ontology

Cons:

• Users reading text files cannot see the relationships
• Users may not run a reasoner to get the inferred triples
• The absence of these redundancies makes the ontology harder to understand

Another option: provide a file with materialized inferences that people can use or not. Need to configure reasoner to not include empty inferences such as every class being a subclass of itself (though judging from inferencing results in Protégé, this may not a problem).

It's probably not advisable or feasible to make a blanket policy, but rather decide on a case-by-case basis. E.g., asserting transitive subclass relationships seems like unnecessary clutter (though I'm not sure how to rationalize the difference between this and the other cases.)

[uscholdm]

@rjyounes says:

It's probably not advisable or feasible to make a blanket policy, but rather decide on a case-by-case basis.

I agree. Best we can do is offer guidelines. I think we should err towards:

1. readability / understandability
2. usability
3. maintainability

Having things scattered around makes it hard to read/understand the ontology w/o running inference (as @rjyounes points out).

Including explicit inverses can improve usability, not forcing to use an non-intuitive direction of the triple, or using the owl:inverseOf function, which is hard to work with for many people.

Redundant imports illustrate the maintainability argument. Excluding redundant imports means that an import that was being relied on to bring in another ontology might go away. Safer to include it explicitly. The general principle is: if having the redundancy helps avoid mistakes or otherwise makes life easier as the ontology evolves, then keep it.

Another example might be domains and range of sub properties. They might change in a different ontology which was being relied on. Having the information explicitly in both places is useful. It might catch a logical error too.

Yet another example is if you create subproperties of a functional property. They are inferred to be functional. But if the super property in a different ontology changes to no longer be functional, then the sub properties need to be explicitly functional. If it was explicit in the first place this error would not happen. This is fairly analogous to the import example.

[uscholdm]

@rjyounes Maybe we should close this, as we both agree that there should be no blanket policy. Perhaps a comment to the effect of: "It is generally good policy to avoid redundancy. There are times when it may be justified, use your judgment."

[uscholdm]

@rjyounes, I suggest we triage this in a group discussion along with #397

[rjyounes]

Should this be discussed in a gist triage meeting or one of our more general ontology discussions? Seems like more the latter to me, which can then be applied to gist.

[uscholdm]

The latter is fine with me.