Remove inverses unless there's a compelling reason

[rjyounes]

As per the decision in #294, we should purge gist of inverse properties that don't have a compelling reason to exist. In general, the guidance is that if there's a tree-like structure, keep the property that goes up rather than down the tree, since cardinality generally will be greater going downward. If there's no tree-like structure, it's dependent on individual context.

This will be a minor change if we deprecate the inverses.

[Added]
From Issue #551
precedesDirectly has inverse followsDirectly, but precedes has no inverse follows. Should be consistent one way or another.

[rjyounes]

We currently define 17 inverses.

We have to decide which ones to keep. @uscholdm and @mdfeickert will take a pass at a proposal and present.

Rebecca: use directionality guidelines in style guide.

Peter: If we don't provide inverses, people will be rolling their own. We should put recommendations in place for when it's appropriate.

Peter: could also have an optional import of the inverses.

Michael: or add an annotation with suggestions of how to name the inverses.

Rebecca: Why do we care what other people name properties in their own namespaces?

Rebecca: We don't need both the annotation and the import. The latter seems better.

Borislav: Remove all inverses from gist and put in a separate file.

Michael: There are some inverses I use all the time that I would like to keep, but I wouldn't want to use the whole file. So each person would have to pick and choose the ones they want. This is inconvenient, and argues for keeping the commonly used ones in gistCore.

Michael: May also propose bringing a few back.

[rjyounes]

Consider in conjunction with #551.

[JonathonGist]

Glad for these decisions--especially that all of them are to be available in an imports file. And I'm glad that the special ones, used often, are being preserved in gistCore.

[rjyounes]

I've come across another compelling reason to remove all inverses from gistCore: when running inferencing on data with a heavy use of predicates with inverses, memory can be overloaded. Therefore keeping "special" ones - whatever that might mean - is still problematic.

This isn't incompatible with adding the inverses to a separate file, but I'd like to ask what the motivation would be. People can use inverse paths in SPARQL and SHACL. You can use owl:inverseOf to state restrictions. I don't see the need for any inverses in any file.

[JonathonGist]

It seems that with the availability of inverse paths in SPARQL and SHACL, there is limited or no need for adding inverse predicates to an ontology. My argument for keeping them in a separate file has evaporated.