Re: Link profiles
Always trying to create both forward and back links seems like the wrong thing to do, even in opt-out mode. Servers are free to either silently ignore RDF properties it doesn’t support, or to fail the whole PUT if it contains an unsupported property. That could give rise to unpredictable behaviour.
An OSLC client may be able to discover which direction(s) are to be used. Consider a user wanting to create a validates requirement link between a test case and a requirement. There are two potential links (as defined by OSLC specs):
- oslc_qm:validatesRequirement stored on the test case
- oslc_rm:validatedBy stored on the requirement
A caller can GET the test case, look for its
oslc:instanceShape, get that shape, and then look for the presence or absence of an OSLC property for
oslc_qm:validatesRequirement. It can then GET the requirement, look for its
oslc:instanceShape, get that shape, and then look for the presence or absence of an OSLC property for
oslc_rm:validatedBy.
I wonder whether that’s sufficient to do the right thing for ELM and for other applications.
Thinking about the opt-in case….
Say you have requirement R1 version 1 (R1-1), and test case TC1 version 1 (TC1-1).
You update the test case in the context of some ETM stream, creating TC1-2 that has a
oslc_qm:validatesRequirement link to the concept R1. In order to create the back-link, you’d need to update R1-1 in the context of a DNG stream,
to create R1-2. A caller won’t know which stream to use for that backlink, so the only way I can see this working is if this is done in a GC context. It also has the side-effect of creating a new version of both the source and the target. If someone looked
at R1 in a GC context that resolved to R1-1, and resolved TC1 to TC1-2, you end up with an inconsistency. The
oslc_rm:validatedBy link didn’t exist on R1-1, but the forward link to that requirement exists on TC1-2. I think these were the reasons why
ELM decided for opt-in, there would be no backlinks.
David.
Sent: 26 May 2022 18:46
To: Andrii Berezovskyi <andriib@...>; Eran Gery <eran.gery@...>; David Honey2 <david.honey@...>; e.gentry@...
Cc: oslc-op@...
Subject: Re: [EXTERNAL] Link profiles
This is a good start, but we should understand how it supports the use cases and common practice.
On the issues we’ve been discussing on links: the OSLC specifications define vocabularies and shapes that specify links that would be reasonably considered inverses. Requirement validatedBy TestCase and TestCase validatesRquirement Requirement is one such example. However, OSLC does not specify which one is the property, which would be considered the inverse property, which or “owed by” any particular server that supports RM and/or QM domains. Rather this is a server implementation decision, often driven by use cases/scenarios that support a particular work-flow – i.e., requirements vs. test driven develop in this case.
Fundamentally OSLC ResourceShape constraints have no way of indicating what a server expects to store vs. expects another server involved in a link relationship expects/can/has to store. So, implementations do what works for them and what is stored where must be documented outside OSLC discovery.
Added to that, OSLC delegated dialogs don’t establish a clear distinction between the requester and provider of the delegated dialog and who’s supposed to “own” the link – that is, which link property the pair of tools considers the actual source and target of the link, and whether the source or target resource will be the subject of the link property triple.
Jazz.net tools attempt to make this transparent, so the user doesn’t have to know which server is storing the link, or how the incoming links are stored or calculated. This is purely a usability issue. However, the participating servers do have to know because even through the creation of the link can be created from either direction, the servers must know which one stores it and implement the link creation accordingly. Again, there is no way to discover this.
We could expand ResourceShape to define inverse property constraints to provide a discoverable way for clients and servers to interoperate when creating links from either direction. I expect that might be a better approach than defining a number of profile special cases.
From:
Andrii Berezovskyi <andriib@...>
Date: Thursday, May 26, 2022 at 11:49 AM
To: Eran Gery <eran.gery@...>, David Honey2 <david.honey@...>, Jim Amsden <jamsden@...>, "e.gentry@..."
<e.gentry@...>
Cc: "oslc-op@..." <oslc-op@...>
Subject: [EXTERNAL] Link profiles
Hi, I put together a simple table for the possible profiles after the call: https://docs.google.com/spreadsheets/d/1fjjGvHrv2yPru8S_6HNoJ5atn6617cUfFUDRz5xAfKQ/edit?usp=sharing Please look at them and tell me what you think. Thanks to Eran
ZjQcmQRYFpfptBannerStart
|
ZjQcmQRYFpfptBannerEnd
Hi,
I put together a simple table for the possible profiles after the call: https://docs.google.com/spreadsheets/d/1fjjGvHrv2yPru8S_6HNoJ5atn6617cUfFUDRz5xAfKQ/edit?usp=sharing
Please look at them and tell me what you think. Thanks to Eran for taking extra time to explain some things to me.
/A
IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU