Backward and Forward links in RDF just as important
"Two types that had far better leave to their betters
the civilized art of exchanging letters
are those who disdain to make any response,
and those who infallibly answer at once!"
The regularity of this blog fails on both counts.
One meme of RDF ethos is that the direction one choses for a given property is arbitrary: it doesn't matter whether one defines "parent" or "child"; "employee" or "employer". This philosophy (from the Enquire design of 1980) is that one should not favor one way over another. One day, you may be interested in following the link one way, another day, or somene else, the other way.
On the other hand, also one should not encourage people having to declare both a property and its inverse, which would simply double the number of definitions out there, and give one more axis of arbitrary variation in the way information is expressed. Therefore, the design of the tabulator was is to make the system treat forward and backward links equivalently.
The design of N3 also was influenced by this. The ability to write
:Joe is f:parent of :Fred.
makes it easier to write (or generate) N3 without having to use f:child. This in turn reduces the pressure to define both.
The only loss in not having both is that there is no label for the reverse link. (In same cases I have defined an unnamed predicate which is delcared as the inverse and has a label.)