All links (i.e. RDF properties) in OSLC are directional, e.g., Requirement validatedBy TestCase. In many cases the and additional property is defined, e.g., TestCase validatesRequirement Requirement. This was intended to provide OSLC servers the flexibility to decide which statement would be asserted, and where the assertion would be persisted.
But this flexibility comes at a cost for integration and interoperability because it is not possible to know which server should actually store the like with a PUT operation when say using a selection dialog to create links.
It may be necessary to extend ResourceShapes to be able to specify primary and inverse constraints on link type properties in order to specify where the property is stored and which (incoming) link types need to be queried. It is important that this is discoverable somehow so that the implementations are properly guided and can be tested.
All links (i.e. RDF properties) in OSLC are directional, e.g., Requirement validatedBy TestCase. In many cases the and additional property is defined, e.g., TestCase validatesRequirement Requirement. This was intended to provide OSLC servers the flexibility to decide which statement would be asserted, and where the assertion would be persisted.
But this flexibility comes at a cost for integration and interoperability because it is not possible to know which server should actually store the like with a PUT operation when say using a selection dialog to create links.
It may be necessary to extend ResourceShapes to be able to specify primary and inverse constraints on link type properties in order to specify where the property is stored and which (incoming) link types need to be queried. It is important that this is discoverable somehow so that the implementations are properly guided and can be tested.