Inverse relationships and labels should be discoverable

[DavidJohnHoney]

OSLC specifications commonly define pairs of links, one of which is regarded as the primary or forward link, the other as the secondary or inverse link. For example, in IBM Rational ELM, a test case may have an oslc_qm:validatesRequirement link that references a requirement that the test case validates. There is also an oslc_rm:validatedBy link that is the inverse of that link. OSLC allows a requirements management tool to explicitly store such links. In practice, in ELM, such an explicit inverse link is not persisted on requirements.

The problem is that a reporting application may want to query and report on the relationship between test cases and requirements. It may not be able to assume that only primary/forward links are persisted. So it needs to know that oslc_qm:validatesRequirement has an inverse oslc_rm:validatedBy relationship, and query for a UNION of data from both predicates. Currently, that is not discoverable through resource shapes.

Even if an application knows that inverse relationships are not explictly persisted, it might need to know what would be an appropriate name for a virtual relationship representing the other direction. A resource shape might include an OSLC property for oslc_qm:validatesRequirement that specifies a title such as "Validates" or "Validates requirement". However, if a tool wants to represent the incoming reverse link, it needs to know what the inverse label of that relationship is. In this example, it might be "Validated by". Currently, there is no OSLC vocabulary for defining such inverse labels. IBM Rational ELM uses a jazz.net namespace vocabulary term jrs:inverseLabel for this.