For example, for Book and Author classes, I can have authorOf relation, and or hasAuthor relation. For Student and Course classes, I can have courseOf and hasCourse relations between the two.
It seems redundant to always create relations in two directions. Is there any guideline or principle to deal with situation?
I'm not aware of any recommendation to always explicitly provide the inverse property.
There are at least two use cases for inverse properties:
The need to reference the inverse property, let's call it "IP", internally in the ontology.
We may need to state that another property is disjoint with IP. Or that another property is equivalent to IP. Now, we provide IP to allow that statement. Another very trivial example is the desire to keep a comment in the right place. You may define IP just to place a rdfs:comment on it.
The need to externally reference the inverse property.
An example is: Our application assigns translations of natural languages to ObjectProperties. In case of the famous Protege Pizza Ontology, we translate "hasTopping" to strings like "en:has topping". We also want to express "en:is the topping of" in a natural language. (Our application semantics needs it.) That's a reason to create the inverse property "isToppingOf": To have an instance, respective an URI, our translations can refer to.