Link profiles


Andrii Berezovskyi
 

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


Michael Rowe
 

Thanks Andrii

 

-- 

Michael Rowe
STSM & MBA – Technical Strategist, ELM Architecture
IBM Engineering

+1(720)342-2713 Office
michael.rowe@...
@michaelrowe01
ibm.co/elm

Sustainable Software

 

 

 

From: oslc-op@... <oslc-op@...> on behalf of Andrii Berezovskyi <andriib@...>
Date: Thursday, May 26, 2022 at 11:49
To: Eran Gery <eran.gery@...>, David Honey2 <david.honey@...>, Jim Amsden <jamsden@...>, e.gentry@... <e.gentry@...>
Cc: oslc-op@... <oslc-op@...>
Subject: [EXTERNAL] [oslc-op] 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

This Message Is From an External Sender

This message came from outside your organization.

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


Jim Amsden
 

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

This Message Is From an External Sender

This message came from outside your organization.

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


Robert Baillargeon
 

Indeed I agree that this is a good start to the discussion.  But as Jim identifies here we have some variability in the definition of where the link storage and inverse are stored.  If we go on the path that these are implementation-specific this will erode the value of OSLC and consistent integrations and portability for OSLC collaborations.  It needs to be formalized in the vocabularies of the standard or more desirable grow to a discovery method to allow for flexibility in the implementations that can arbitrate behaviors.  

Basically put as we look at the future of OSLC for consistency and scalability we are going to need to support ...
  1. Vocabulary that includes link types, link storage location (local attribute, local & backlink, discovery) , and link inverse discovery mechanisms (trs index, oslc query, etc.)
  2. Domain vocabulary discovery so endpoints can declare, extend, and discover new domains.
I agree that there is a need near-term to better declare a profile that states the basics of a good collaborating OSLC end-point (rather than just an endpoint that consumes some OSLC interfaces).  But we also need to look to the future to better support PLM and other domain tools (rather than overloading AM) and have consistent patterns of interaction and UX experiences.

We are looking forward to collaborating on these.  Let's focus on the current baseline profiles, but we should be also starting to draft where we want to go so that we can recruit other tooling to the OSLC Enterprise.

Robert




Chief Product Officer – Linked Data

418 N. Main Street 2nd Floor/Suite 200, Royal Oak, Michigan 48067, USA
Ph: 716 261 8338 
sodiuswillert.com

 


 

Try out our Jira and Confluence OSLC Tools on the Atlassian Marketplace


From: oslc-op@... <oslc-op@...> on behalf of Jim Amsden via lists.oasis-open-projects.org <jamsden=us.ibm.com@...>
Sent: Thursday, May 26, 2022 1:46 PM
To: Andrii Berezovskyi <andriib@...>; Eran Gery <eran.gery@...>; David Honey2 <david.honey@...>; e.gentry@... <e.gentry@...>
Cc: oslc-op@... <oslc-op@...>
Subject: Re: [oslc-op] 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

This Message Is From an External Sender

This message came from outside your organization.

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


David Honey2
 

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.

 

From: Jim Amsden <jamsden@...>
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

This Message Is From an External Sender

This message came from outside your organization.

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

Unless otherwise stated above:

IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU


Robert Baillargeon
 

I'm always for only storing the forward link.  It has a clear advantage in the ability to better manage the configurations and the composition of configurations.  If I could get rid of backlinks I would. 

When moving entirely to reverse link discovery, I would also note that we will need to have some behaviors in the tools to address when a discovery task fails due to downstream authentication, timeout, or otherwise.  We have seen situations where the inverse link is not visible and user confusion about the cause.

That is an interesting thought that we could discover link ownership by inspecting the shape.  Let me consider that path and see if that is complete with the information we would expect.



The other interesting point is to 

Chief Product Officer – Linked Data

418 N. Main Street 2nd Floor/Suite 200, Royal Oak, Michigan 48067, USA
Ph: 716 261 8338 
sodiuswillert.com

 


 

Try out our Jira and Confluence OSLC Tools on the Atlassian Marketplace


From: oslc-op@... <oslc-op@...> on behalf of David Honey2 via lists.oasis-open-projects.org <david.honey=ibm.com@...>
Sent: Thursday, May 26, 2022 2:59 PM
To: Jim Amsden <jamsden@...>; Andrii Berezovskyi <andriib@...>; Eran Gery <eran.gery@...>; e.gentry@... <e.gentry@...>
Cc: oslc-op@... <oslc-op@...>
Subject: Re: [oslc-op] 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.

 

From: Jim Amsden <jamsden@...>
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

This Message Is From an External Sender

This message came from outside your organization.

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

Unless otherwise stated above:

IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU


Jim Amsden
 

I am specifically not proposing to store backlinks. What I’m suggesting is that which link is the forward link depends on the use case the servers are trying to support. So rather I’m proposing using constraints as a means of discovering and perhaps specifying in a profile, what the links mean in a particular situation.

 

Once discovered where the link is stored, there should be standard way of determining the incoming/inverse link.

 

 

From: Robert Baillargeon <rbaillargeon@...>
Date: Thursday, May 26, 2022 at 3:12 PM
To: Jim Amsden <jamsden@...>, Andrii Berezovskyi <andriib@...>, Eran Gery <eran.gery@...>, "e.gentry@..." <e.gentry@...>, "oslc-op@..." <oslc-op@...>, David Honey2 <david.honey@...>
Subject: [EXTERNAL] Re: [oslc-op] Link profiles

 

I'm always for only storing the forward link. It has a clear advantage in the ability to better manage the configurations and the composition of configurations. If I could get rid of backlinks I would. ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

I'm always for only storing the forward link.  It has a clear advantage in the ability to better manage the configurations and the composition of configurations.  If I could get rid of backlinks I would. 

 

When moving entirely to reverse link discovery, I would also note that we will need to have some behaviors in the tools to address when a discovery task fails due to downstream authentication, timeout, or otherwise.  We have seen situations where the inverse link is not visible and user confusion about the cause.

 

That is an interesting thought that we could discover link ownership by inspecting the shape.  Let me consider that path and see if that is complete with the information we would expect.

 

 

 

The other interesting point is to 

Chief Product Officer – Linked Data

418 N. Main Street 2nd Floor/Suite 200, Royal Oak, Michigan 48067, USA
Ph: 716 261 8338 
sodiuswillert.com

 

 

Try out our Jira and Confluence OSLC Tools on the Atlassian Marketplace


From: oslc-op@... <oslc-op@...> on behalf of David Honey2 via lists.oasis-open-projects.org <david.honey=ibm.com@...>
Sent: Thursday, May 26, 2022 2:59 PM
To: Jim Amsden <jamsden@...>; Andrii Berezovskyi <andriib@...>; Eran Gery <eran.gery@...>; e.gentry@... <e.gentry@...>
Cc: oslc-op@... <oslc-op@...>
Subject: Re: [oslc-op] 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.

 

From: Jim Amsden <jamsden@...>
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

This Message Is From an External Sender

This message came from outside your organization.

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

Unless otherwise stated above:

IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU


Gentry, Edward <e.gentry@...>
 

Sorry I’ve missed the discussion today. It’s a holiday here. 

One thing for me is very clear. If by link we mean a single predicate then we always know where it is stored. Always. It is stored with the subject of the link. Always. 

We don’t store statements about resources we don’t control. And I certainly should not trust a statement made by another about a resource that belongs to me. 

Now if we understand a link more semantically then Jim’s suggestion that the concept “satisfies” could be expressed with two different predicates “satisfies” and “satisfies by” each potentially stored on the corresponding side is something we might consider. But I’d suggest as a second phase since nothing like this exists to my knowledge 


From: Jim Amsden <jamsden@...>
Sent: Thursday, May 26, 2022 9:33:00 PM
To: Robert Baillargeon <rbaillargeon@...>; Andrii Berezovskyi <andriib@...>; Eran Gery <eran.gery@...>; Gentry, Edward <e.gentry@...>; oslc-op@... <oslc-op@...>; David Honey2 <david.honey@...>
Subject: RE: [oslc-op] Link profiles
 

I am specifically not proposing to store backlinks. What I’m suggesting is that which link is the forward link depends on the use case the servers are trying to support. So rather I’m proposing using constraints as a means of discovering and perhaps specifying in a profile, what the links mean in a particular situation.

 

Once discovered where the link is stored, there should be standard way of determining the incoming/inverse link.

 

 

From: Robert Baillargeon <rbaillargeon@...>
Date: Thursday, May 26, 2022 at 3:12 PM
To: Jim Amsden <jamsden@...>, Andrii Berezovskyi <andriib@...>, Eran Gery <eran.gery@...>, "e.gentry@..." <e.gentry@...>, "oslc-op@..." <oslc-op@...>, David Honey2 <david.honey@...>
Subject: [EXTERNAL] Re: [oslc-op] Link profiles

 

I'm always for only storing the forward link. It has a clear advantage in the ability to better manage the configurations and the composition of configurations. If I could get rid of backlinks I would. ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

I'm always for only storing the forward link.  It has a clear advantage in the ability to better manage the configurations and the composition of configurations.  If I could get rid of backlinks I would. 

 

When moving entirely to reverse link discovery, I would also note that we will need to have some behaviors in the tools to address when a discovery task fails due to downstream authentication, timeout, or otherwise.  We have seen situations where the inverse link is not visible and user confusion about the cause.

 

That is an interesting thought that we could discover link ownership by inspecting the shape.  Let me consider that path and see if that is complete with the information we would expect.

 

 

 

The other interesting point is to 

Chief Product Officer – Linked Data

418 N. Main Street 2nd Floor/Suite 200, Royal Oak, Michigan 48067, USA
Ph: 716 261 8338 
sodiuswillert.com

 

 

Try out our Jira and Confluence OSLC Tools on the Atlassian Marketplace


From: oslc-op@... <oslc-op@...> on behalf of David Honey2 via lists.oasis-open-projects.org <david.honey=ibm.com@...>
Sent: Thursday, May 26, 2022 2:59 PM
To: Jim Amsden <jamsden@...>; Andrii Berezovskyi <andriib@...>; Eran Gery <eran.gery@...>; e.gentry@... <e.gentry@...>
Cc: oslc-op@... <oslc-op@...>
Subject: Re: [oslc-op] 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.

 

From: Jim Amsden <jamsden@...>
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

This Message Is From an External Sender

This message came from outside your organization.

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

Unless otherwise stated above:

IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU


"Eran Gery"
 

Hi David, all,

 

Again, pulling back towards the pragmatic principle “let’s define a profile that at least guarantees ELM (jazz) cross linking”.

Let’s push to the background for now discussions around “good architectural specification”. Profiles here are all about (ugly) pragmatics.

 

Note: there are some ELM anomalies we may not include in a profile, only document. Obviously we need ELM to fix that. Some examples:

  • ELM currently does not support AM/AM linking (RMM). Obviously we cannot enforce this in a profile. We are pushing hard to fix it this year.
  • While in opt-in mode incoming link discovery is done via LDX, RM expects AM to support OSLC query for that. This means that LDX support is not enough for an AM provider, and it needs to support both LDX feed and OSLC query. Again we can document it but recommend LDX usage across all opt-in incoming link discoveries.
  • In OptOut mode (no config) ELM assumes backlinking. So for example if a Jira connector creates a link to a requirement, it also needs to create a backlink on the requirement. Ouch.

 

So for that purpose a question about “opt out” mode: how does ELM behave here, between using a single link with incoming implemented with OSLC query, vs. using backlinks. As far as I recall, all CCM links are using backlinking, and other (RM:QM, RM:AM, AM:QM) use a query. Is that correct?

 

As for shapes based discovery: I think we also need to specify the storage policy, as creating apps based on discovery requires a higher level of sophistication and preparing for variability. Between two providers, if both have shapes that claim ownership, one need to concede. So to simplify we need to provide ownership map. Also another related question: do the shapes change between opt-out and opt-in mode? For example. RM in opt-out would keep a backlink to CCM. In opt-in not. Does it maintain two shapes?

 

Also for Anrew’s request attached is a spreadsheet  I created at the time for opt-in mode. We also need to create on for opt-out.  @David Honey2

Can you please confirm its accuracy?

Hope this makes sense…

Regards,

Eran

 

 

From: David Honey2 <david.honey@...>
Sent: Thursday, 26 May 2022 21:59
To: Jim Amsden <jamsden@...>; Andrii Berezovskyi <andriib@...>; Eran Gery <eran.gery@...>; e.gentry@...
Cc: oslc-op@...
Subject: RE: [EXTERNAL] 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.

 

From: Jim Amsden <jamsden@...>
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

This Message Is From an External Sender

This message came from outside your organization.

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


"Eran Gery"
 

Ed,

 

Thanks for coming back to version 0…. Indeed this is what we should focus on and we rather call it version 1.

As I mentioned in my other note, IMO for Opt-out we should not recommend link index as this is too far from how Jazz behaves. I think we should recommend OSLC query. That also reduces the requirement to support TRS in that case. And again, there is the CCM anomaly that still relies on backlinking.

 

Regards,

eran

 

From: Gentry, Edward <e.gentry@...>
Sent: Friday, 27 May 2022 10:00
To: Jim Amsden <jamsden@...>; Robert Baillargeon <rbaillargeon@...>; Andrii Berezovskyi <andriib@...>; Eran Gery <eran.gery@...>; oslc-op@...; David Honey2 <david.honey@...>
Subject: [EXTERNAL] RE: [oslc-op] Link profiles

 

A few ideas and observations and a concrete proposal: A helpful idea was proposed by our French Sodius Colleague whose name escapes me. He suggested in a conversation after our last call – and he’ll correct me if I don’t represent him well

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

A few ideas and observations and a concrete proposal:

 

  • A helpful idea was proposed by our French Sodius Colleague whose name escapes me.  He suggested in a conversation after our last call – and he’ll correct me if I don’t represent him well - that resource shapes should be extended so that tools could indicate which links they index.

 

  • @Jim Amsden’s  suggestion is also interesting (again he’ll correct me if I don’ represent him well) Each “link” might be represented as a pair of reciprocal predicates. For example: Let  (P and P’) be a pair of reciprocal predicates.  Then semantically, the triple (S0, P, O0), would have the same meaning the triple (O0, P’, S0).

 

  • Also I’d observe that “links” already have the concept of a reciprocal-names. Let N be the name for the P in triple (S0, P, O0) when viewed from the perceptive of S0. Then N’, the reciprocal-name is the title of P, is the title of P when it is viewed from the perspective of O2. Naturally if we had reciprocal predicates then the name of P’ (above) would be N’.

 

Besides discussing these more in detail, I’d like to make the following suggestion: We should reify the concept of link beyond just a single predicate – indeed above are examples of where we are already doing this. We should formalize what we mean by links, want kind of characteristics they may have: titles, reciprocal-links, reciprocal-labels, etc.

 

However has  @Eran Gery has emphasized all of this is beyond the scope of the first version of Link Profiles.

 

For me the link profile work would look something like this:

 

Version 0: Describe linking as it exists in ELM today keeping modifications to a minimum. Given the importance of GC’s for real life applications – and changing my position a bit here – this should include both opt in and opt out cases (with and out GCS), even though that means waving our hands a bit and just assuming the indexing for back links.  

 

Version 1: We reify links and include the concepts above and more.

 

 

From: Gentry, Edward <e.gentry@...>
Sent: Donnerstag, 26. Mai 2022 22:48
To: Jim Amsden <jamsden@...>; Robert Baillargeon <rbaillargeon@...>; Andrii Berezovskyi <andriib@...>; Eran Gery <eran.gery@...>; oslc-op@...; David Honey2 <david.honey@...>
Subject: Re: [oslc-op] Link profiles

 

Sorry I’ve missed the discussion today. It’s a holiday here. 

 

One thing for me is very clear. If by link we mean a single predicate then we always know where it is stored. Always. It is stored with the subject of the link. Always. 

 

We don’t store statements about resources we don’t control. And I certainly should not trust a statement made by another about a resource that belongs to me. 

 

Now if we understand a link more semantically then Jim’s suggestion that the concept “satisfies” could be expressed with two different predicates “satisfies” and “satisfies by” each potentially stored on the corresponding side is something we might consider. But I’d suggest as a second phase since nothing like this exists to my knowledge 


From: Jim Amsden <jamsden@...>
Sent: Thursday, May 26, 2022 9:33:00 PM
To: Robert Baillargeon <
rbaillargeon@...>; Andrii Berezovskyi <andriib@...>; Eran Gery <eran.gery@...>; Gentry, Edward <e.gentry@...>; oslc-op@... <oslc-op@...>; David Honey2 <david.honey@...>
Subject: RE: [oslc-op] Link profiles

 

I am specifically not proposing to store backlinks. What I’m suggesting is that which link is the forward link depends on the use case the servers are trying to support. So rather I’m proposing using constraints as a means of discovering and perhaps specifying in a profile, what the links mean in a particular situation.

 

Once discovered where the link is stored, there should be standard way of determining the incoming/inverse link.

 

 

From: Robert Baillargeon <rbaillargeon@...>
Date: Thursday, May 26, 2022 at 3:12 PM
To: Jim Amsden <
jamsden@...>, Andrii Berezovskyi <andriib@...>, Eran Gery <eran.gery@...>, "e.gentry@..." <e.gentry@...>, "oslc-op@..." <oslc-op@...>, David Honey2 <david.honey@...>
Subject: [EXTERNAL] Re: [oslc-op] Link profiles

 

I'm always for only storing the forward link. It has a clear advantage in the ability to better manage the configurations and the composition of configurations. If I could get rid of backlinks I would. ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

I'm always for only storing the forward link.  It has a clear advantage in the ability to better manage the configurations and the composition of configurations.  If I could get rid of backlinks I would. 

 

When moving entirely to reverse link discovery, I would also note that we will need to have some behaviors in the tools to address when a discovery task fails due to downstream authentication, timeout, or otherwise.  We have seen situations where the inverse link is not visible and user confusion about the cause.

 

That is an interesting thought that we could discover link ownership by inspecting the shape.  Let me consider that path and see if that is complete with the information we would expect.

 

 

 

The other interesting point is to 

Chief Product Officer – Linked Data

418 N. Main Street 2nd Floor/Suite 200, Royal Oak, Michigan 48067, USA
Ph: 716 261 8338 
sodiuswillert.com

 

 

Try out our Jira and Confluence OSLC Tools on the Atlassian Marketplace


From: oslc-op@... <oslc-op@...> on behalf of David Honey2 via lists.oasis-open-projects.org <david.honey=ibm.com@...>
Sent: Thursday, May 26, 2022 2:59 PM
To: Jim Amsden <
jamsden@...>; Andrii Berezovskyi <andriib@...>; Eran Gery <eran.gery@...>; e.gentry@... <e.gentry@...>
Cc:
oslc-op@... <oslc-op@...>
Subject: Re: [oslc-op] 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.

 

From: Jim Amsden <jamsden@...>
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

This Message Is From an External Sender

This message came from outside your organization.

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

Unless otherwise stated above:

IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU


David Honey2
 

As you suggest Jim, we could add a new property of an oslc:Property to indicate the reverse predicate for a link. This is not without its problems. Say we added a oslc:inversePropertyDefinition property. Consider the following use case (with imprecise Turtle):

 

Resource shape 1:

<prop1>
      a oslc:Property ;
      oslc:properyDefinition <forwardPredicate1> ;
     oslc:inversePropertyDefinition <reversePredicate1> ;
     ...

<prop2>
      a oslc:Property ;
      oslc:properyDefinition <forwardPredicate2> ;
     oslc:inversePropertyDefinition <reversePredicate1> ;

 

Resource shape 2:

<prop3>
      a oslc:Property ;
      oslc:properyDefinition <reversePredicate1> ;
     oslc:inversePropertyDefinition <forwardPredicate1> ;
     ...

 

Resource shape 3:

<prop4>
      a oslc:Property ;
      oslc:properyDefinition <reversePredicate1> ;
     oslc:inversePropertyDefinition <forwardPredicate2> ;
     ...

 


Now when you ask the question what is the inverse predicate for
<reversePredicate1> across resource shapes, you get two solutions <forwardPredicate1> and <forwardPredicate2>. For reporting solutions that query for type system models in LQE (such as Report Builder) this doesn’t work.

This is a common pattern. You might use some predicate P1 for all link to some resource of type T1 regardless of the type of the subject resource. So there might be multiple resource types T2, T3, T4 that all use that predicate P1 to resources of type T1. However, the reverse predicate from type T2 to T1 is almost always different from type T3 to T1, and from type T4 to T1.

If you look at any single resource shape, it’s unambiguous.

 

I think we need to consider such a proposal carefully.

 

David.

 

From: Jim Amsden <jamsden@...>
Sent: 26 May 2022 20:33
To: Robert Baillargeon <rbaillargeon@...>; Andrii Berezovskyi <andriib@...>; Eran Gery <eran.gery@...>; e.gentry@...; oslc-op@...; David Honey2 <david.honey@...>
Subject: Re: [EXTERNAL] Re: [oslc-op] Link profiles

 

I am specifically not proposing to store backlinks. What I’m suggesting is that which link is the forward link depends on the use case the servers are trying to support. So rather I’m proposing using constraints as a means of discovering and perhaps specifying in a profile, what the links mean in a particular situation.

 

Once discovered where the link is stored, there should be standard way of determining the incoming/inverse link.

 

 

From: Robert Baillargeon <rbaillargeon@...>
Date: Thursday, May 26, 2022 at 3:12 PM
To: Jim Amsden <jamsden@...>, Andrii Berezovskyi <andriib@...>, Eran Gery <eran.gery@...>, "e.gentry@..." <e.gentry@...>, "oslc-op@..." <oslc-op@...>, David Honey2 <david.honey@...>
Subject: [EXTERNAL] Re: [oslc-op] Link profiles

 

I'm always for only storing the forward link. It has a clear advantage in the ability to better manage the configurations and the composition of configurations. If I could get rid of backlinks I would. ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

I'm always for only storing the forward link.  It has a clear advantage in the ability to better manage the configurations and the composition of configurations.  If I could get rid of backlinks I would. 

 

When moving entirely to reverse link discovery, I would also note that we will need to have some behaviors in the tools to address when a discovery task fails due to downstream authentication, timeout, or otherwise.  We have seen situations where the inverse link is not visible and user confusion about the cause.

 

That is an interesting thought that we could discover link ownership by inspecting the shape.  Let me consider that path and see if that is complete with the information we would expect.

 

 

 

The other interesting point is to 

Chief Product Officer – Linked Data

418 N. Main Street 2nd Floor/Suite 200, Royal Oak, Michigan 48067, USA
Ph: 716 261 8338 
sodiuswillert.com

 

 

Try out our Jira and Confluence OSLC Tools on the Atlassian Marketplace


From: oslc-op@... <oslc-op@...> on behalf of David Honey2 via lists.oasis-open-projects.org <david.honey=ibm.com@...>
Sent: Thursday, May 26, 2022 2:59 PM
To: Jim Amsden <jamsden@...>; Andrii Berezovskyi <andriib@...>; Eran Gery <eran.gery@...>; e.gentry@... <e.gentry@...>
Cc: oslc-op@... <oslc-op@...>
Subject: Re: [oslc-op] 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.

 

From: Jim Amsden <jamsden@...>
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

This Message Is From an External Sender

This message came from outside your organization.

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

Unless otherwise stated above:

IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU

Unless otherwise stated above:

IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU


David Honey2
 

Re: We should reify the concept of link beyond just a single predicate

OSLC avoids and discourages the use of reification. It can make querying problematic, especially for OSLC query. I don’t think we should set a precedent just for this use case.

 

From: Gentry, Edward <e.gentry@...>
Sent: 27 May 2022 08:00
To: Jim Amsden <jamsden@...>; Robert Baillargeon <rbaillargeon@...>; Andrii Berezovskyi <andriib@...>; Eran Gery <eran.gery@...>; oslc-op@...; David Honey2 <david.honey@...>
Subject: [EXTERNAL] RE: [oslc-op] Link profiles

 

A few ideas and observations and a concrete proposal: A helpful idea was proposed by our French Sodius Colleague whose name escapes me. He suggested in a conversation after our last call – and he’ll correct me if I don’t represent him well

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

A few ideas and observations and a concrete proposal:

 

  • A helpful idea was proposed by our French Sodius Colleague whose name escapes me.  He suggested in a conversation after our last call – and he’ll correct me if I don’t represent him well - that resource shapes should be extended so that tools could indicate which links they index.

 

  • @Jim Amsden’s  suggestion is also interesting (again he’ll correct me if I don’ represent him well) Each “link” might be represented as a pair of reciprocal predicates. For example: Let  (P and P’) be a pair of reciprocal predicates.  Then semantically, the triple (S0, P, O0), would have the same meaning the triple (O0, P’, S0).

 

  • Also I’d observe that “links” already have the concept of a reciprocal-names. Let N be the name for the P in triple (S0, P, O0) when viewed from the perceptive of S0. Then N’, the reciprocal-name is the title of P, is the title of P when it is viewed from the perspective of O2. Naturally if we had reciprocal predicates then the name of P’ (above) would be N’.

 

Besides discussing these more in detail, I’d like to make the following suggestion: We should reify the concept of link beyond just a single predicate – indeed above are examples of where we are already doing this. We should formalize what we mean by links, want kind of characteristics they may have: titles, reciprocal-links, reciprocal-labels, etc.

 

However has  @Eran Gery has emphasized all of this is beyond the scope of the first version of Link Profiles.

 

For me the link profile work would look something like this:

 

Version 0: Describe linking as it exists in ELM today keeping modifications to a minimum. Given the importance of GC’s for real life applications – and changing my position a bit here – this should include both opt in and opt out cases (with and out GCS), even though that means waving our hands a bit and just assuming the indexing for back links.  

 

Version 1: We reify links and include the concepts above and more.

 

 

From: Gentry, Edward <e.gentry@...>
Sent: Donnerstag, 26. Mai 2022 22:48
To: Jim Amsden <jamsden@...>; Robert Baillargeon <rbaillargeon@...>; Andrii Berezovskyi <andriib@...>; Eran Gery <eran.gery@...>; oslc-op@...; David Honey2 <david.honey@...>
Subject: Re: [oslc-op] Link profiles

 

Sorry I’ve missed the discussion today. It’s a holiday here. 

 

One thing for me is very clear. If by link we mean a single predicate then we always know where it is stored. Always. It is stored with the subject of the link. Always. 

 

We don’t store statements about resources we don’t control. And I certainly should not trust a statement made by another about a resource that belongs to me. 

 

Now if we understand a link more semantically then Jim’s suggestion that the concept “satisfies” could be expressed with two different predicates “satisfies” and “satisfies by” each potentially stored on the corresponding side is something we might consider. But I’d suggest as a second phase since nothing like this exists to my knowledge 


From: Jim Amsden <jamsden@...>
Sent: Thursday, May 26, 2022 9:33:00 PM
To: Robert Baillargeon <
rbaillargeon@...>; Andrii Berezovskyi <andriib@...>; Eran Gery <eran.gery@...>; Gentry, Edward <e.gentry@...>; oslc-op@... <oslc-op@...>; David Honey2 <david.honey@...>
Subject: RE: [oslc-op] Link profiles

 

I am specifically not proposing to store backlinks. What I’m suggesting is that which link is the forward link depends on the use case the servers are trying to support. So rather I’m proposing using constraints as a means of discovering and perhaps specifying in a profile, what the links mean in a particular situation.

 

Once discovered where the link is stored, there should be standard way of determining the incoming/inverse link.

 

 

From: Robert Baillargeon <rbaillargeon@...>
Date: Thursday, May 26, 2022 at 3:12 PM
To: Jim Amsden <
jamsden@...>, Andrii Berezovskyi <andriib@...>, Eran Gery <eran.gery@...>, "e.gentry@..." <e.gentry@...>, "oslc-op@..." <oslc-op@...>, David Honey2 <david.honey@...>
Subject: [EXTERNAL] Re: [oslc-op] Link profiles

 

I'm always for only storing the forward link. It has a clear advantage in the ability to better manage the configurations and the composition of configurations. If I could get rid of backlinks I would. ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

I'm always for only storing the forward link.  It has a clear advantage in the ability to better manage the configurations and the composition of configurations.  If I could get rid of backlinks I would. 

 

When moving entirely to reverse link discovery, I would also note that we will need to have some behaviors in the tools to address when a discovery task fails due to downstream authentication, timeout, or otherwise.  We have seen situations where the inverse link is not visible and user confusion about the cause.

 

That is an interesting thought that we could discover link ownership by inspecting the shape.  Let me consider that path and see if that is complete with the information we would expect.

 

 

 

The other interesting point is to 

Chief Product Officer – Linked Data

418 N. Main Street 2nd Floor/Suite 200, Royal Oak, Michigan 48067, USA
Ph: 716 261 8338 
sodiuswillert.com

 

 

Try out our Jira and Confluence OSLC Tools on the Atlassian Marketplace


From: oslc-op@... <oslc-op@...> on behalf of David Honey2 via lists.oasis-open-projects.org <david.honey=ibm.com@...>
Sent: Thursday, May 26, 2022 2:59 PM
To: Jim Amsden <
jamsden@...>; Andrii Berezovskyi <andriib@...>; Eran Gery <eran.gery@...>; e.gentry@... <e.gentry@...>
Cc:
oslc-op@... <oslc-op@...>
Subject: Re: [oslc-op] 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.

 

From: Jim Amsden <jamsden@...>
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

This Message Is From an External Sender

This message came from outside your organization.

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

Unless otherwise stated above:

IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU

Unless otherwise stated above:

IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU


Gentry, Edward <e.gentry@...>
 

I do have one concern about Jim’s inverse link suggestion (though I generally think it’s a good idea).

 

Implementing inverse links is more significant implementation work for IBM ELM.

 

  • All ELM tools need to understand that a “link” has inverse-labels and may also have inverse-links
  • Tools will need to allow the creation of and query for both (filtering in the GC as appropriate

 

IBM ELM is still the 1000 ton gorilla in the OSLC space. Any new feature, as good as it might be, until implemented in IBM ELM is irrelevant in the real world.

 

This is why I much prefer the approach (which is compatible with above) that was suggested by the sodius team.  Tools should indicate in resource shapes for which links they query. In contrast to above, this is a very small step for IBM ELM – its just modified meta-data. It sets us up nicely for some of David’s suggestions below about further extensions to resource shapes.

 

 

From: David Honey2 <david.honey@...>
Sent: Freitag, 27. Mai 2022 11:23
To: Gentry, Edward <e.gentry@...>; Jim Amsden <jamsden@...>; Robert Baillargeon <rbaillargeon@...>; Andrii Berezovskyi <andriib@...>; Eran Gery <eran.gery@...>; oslc-op@...
Subject: RE: [oslc-op] Link profiles

 

Re: We should reify the concept of link beyond just a single predicate

OSLC avoids and discourages the use of reification. It can make querying problematic, especially for OSLC query. I don’t think we should set a precedent just for this use case.

 

From: Gentry, Edward <e.gentry@...>
Sent: 27 May 2022 08:00
To: Jim Amsden <jamsden@...>; Robert Baillargeon <rbaillargeon@...>; Andrii Berezovskyi <andriib@...>; Eran Gery <eran.gery@...>; oslc-op@...; David Honey2 <david.honey@...>
Subject: [EXTERNAL] RE: [oslc-op] Link profiles

 

A few ideas and observations and a concrete proposal: A helpful idea was proposed by our French Sodius Colleague whose name escapes me. He suggested in a conversation after our last call – and he’ll correct me if I don’t represent him well

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

A few ideas and observations and a concrete proposal:

 

  • A helpful idea was proposed by our French Sodius Colleague whose name escapes me.  He suggested in a conversation after our last call – and he’ll correct me if I don’t represent him well - that resource shapes should be extended so that tools could indicate which links they index.

 

  • @Jim Amsden’s  suggestion is also interesting (again he’ll correct me if I don’ represent him well) Each “link” might be represented as a pair of reciprocal predicates. For example: Let  (P and P’) be a pair of reciprocal predicates.  Then semantically, the triple (S0, P, O0), would have the same meaning the triple (O0, P’, S0).

 

  • Also I’d observe that “links” already have the concept of a reciprocal-names. Let N be the name for the P in triple (S0, P, O0) when viewed from the perceptive of S0. Then N’, the reciprocal-name is the title of P, is the title of P when it is viewed from the perspective of O2. Naturally if we had reciprocal predicates then the name of P’ (above) would be N’.

 

Besides discussing these more in detail, I’d like to make the following suggestion: We should reify the concept of link beyond just a single predicate – indeed above are examples of where we are already doing this. We should formalize what we mean by links, want kind of characteristics they may have: titles, reciprocal-links, reciprocal-labels, etc.

 

However has  @Eran Gery has emphasized all of this is beyond the scope of the first version of Link Profiles.

 

For me the link profile work would look something like this:

 

Version 0: Describe linking as it exists in ELM today keeping modifications to a minimum. Given the importance of GC’s for real life applications – and changing my position a bit here – this should include both opt in and opt out cases (with and out GCS), even though that means waving our hands a bit and just assuming the indexing for back links.  

 

Version 1: We reify links and include the concepts above and more.

 

 

From: Gentry, Edward <e.gentry@...>
Sent: Donnerstag, 26. Mai 2022 22:48
To: Jim Amsden <jamsden@...>; Robert Baillargeon <rbaillargeon@...>; Andrii Berezovskyi <andriib@...>; Eran Gery <eran.gery@...>; oslc-op@...; David Honey2 <david.honey@...>
Subject: Re: [oslc-op] Link profiles

 

Sorry I’ve missed the discussion today. It’s a holiday here. 

 

One thing for me is very clear. If by link we mean a single predicate then we always know where it is stored. Always. It is stored with the subject of the link. Always. 

 

We don’t store statements about resources we don’t control. And I certainly should not trust a statement made by another about a resource that belongs to me. 

 

Now if we understand a link more semantically then Jim’s suggestion that the concept “satisfies” could be expressed with two different predicates “satisfies” and “satisfies by” each potentially stored on the corresponding side is something we might consider. But I’d suggest as a second phase since nothing like this exists to my knowledge 


From: Jim Amsden <jamsden@...>
Sent: Thursday, May 26, 2022 9:33:00 PM
To: Robert Baillargeon <
rbaillargeon@...>; Andrii Berezovskyi <andriib@...>; Eran Gery <eran.gery@...>; Gentry, Edward <e.gentry@...>; oslc-op@... <oslc-op@...>; David Honey2 <david.honey@...>
Subject: RE: [oslc-op] Link profiles

 

I am specifically not proposing to store backlinks. What I’m suggesting is that which link is the forward link depends on the use case the servers are trying to support. So rather I’m proposing using constraints as a means of discovering and perhaps specifying in a profile, what the links mean in a particular situation.

 

Once discovered where the link is stored, there should be standard way of determining the incoming/inverse link.

 

 

From: Robert Baillargeon <rbaillargeon@...>
Date: Thursday, May 26, 2022 at 3:12 PM
To: Jim Amsden <
jamsden@...>, Andrii Berezovskyi <andriib@...>, Eran Gery <eran.gery@...>, "e.gentry@..." <e.gentry@...>, "oslc-op@..." <oslc-op@...>, David Honey2 <david.honey@...>
Subject: [EXTERNAL] Re: [oslc-op] Link profiles

 

I'm always for only storing the forward link. It has a clear advantage in the ability to better manage the configurations and the composition of configurations. If I could get rid of backlinks I would. ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

I'm always for only storing the forward link.  It has a clear advantage in the ability to better manage the configurations and the composition of configurations.  If I could get rid of backlinks I would. 

 

When moving entirely to reverse link discovery, I would also note that we will need to have some behaviors in the tools to address when a discovery task fails due to downstream authentication, timeout, or otherwise.  We have seen situations where the inverse link is not visible and user confusion about the cause.

 

That is an interesting thought that we could discover link ownership by inspecting the shape.  Let me consider that path and see if that is complete with the information we would expect.

 

 

 

The other interesting point is to 

Chief Product Officer – Linked Data

418 N. Main Street 2nd Floor/Suite 200, Royal Oak, Michigan 48067, USA
Ph: 716 261 8338 
sodiuswillert.com

 

 

Try out our Jira and Confluence OSLC Tools on the Atlassian Marketplace


From: oslc-op@... <oslc-op@...> on behalf of David Honey2 via lists.oasis-open-projects.org <david.honey=ibm.com@...>
Sent: Thursday, May 26, 2022 2:59 PM
To: Jim Amsden <
jamsden@...>; Andrii Berezovskyi <andriib@...>; Eran Gery <eran.gery@...>; e.gentry@... <e.gentry@...>
Cc:
oslc-op@... <oslc-op@...>
Subject: Re: [oslc-op] 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.

 

From: Jim Amsden <jamsden@...>
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

This Message Is From an External Sender

This message came from outside your organization.

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

Unless otherwise stated above:

IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU

Unless otherwise stated above:

IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU


Gentry, Edward <e.gentry@...>
 

A few ideas and observations and a concrete proposal:

 

  • A helpful idea was proposed by our French Sodius Colleague whose name escapes me.  He suggested in a conversation after our last call – and he’ll correct me if I don’t represent him well - that resource shapes should be extended so that tools could indicate which links they index.

 

  • @Jim Amsden’s  suggestion is also interesting (again he’ll correct me if I don’ represent him well) Each “link” might be represented as a pair of reciprocal predicates. For example: Let  (P and P’) be a pair of reciprocal predicates.  Then semantically, the triple (S0, P, O0), would have the same meaning the triple (O0, P’, S0).

 

  • Also I’d observe that “links” already have the concept of a reciprocal-names. Let N be the name for the P in triple (S0, P, O0) when viewed from the perceptive of S0. Then N’, the reciprocal-name is the title of P, is the title of P when it is viewed from the perspective of O2. Naturally if we had reciprocal predicates then the name of P’ (above) would be N’.

 

Besides discussing these more in detail, I’d like to make the following suggestion: We should reify the concept of link beyond just a single predicate – indeed above are examples of where we are already doing this. We should formalize what we mean by links, want kind of characteristics they may have: titles, reciprocal-links, reciprocal-labels, etc.

 

However has  @Eran Gery has emphasized all of this is beyond the scope of the first version of Link Profiles.

 

For me the link profile work would look something like this:

 

Version 0: Describe linking as it exists in ELM today keeping modifications to a minimum. Given the importance of GC’s for real life applications – and changing my position a bit here – this should include both opt in and opt out cases (with and out GCS), even though that means waving our hands a bit and just assuming the indexing for back links.  

 

Version 1: We reify links and include the concepts above and more.

 

 

From: Gentry, Edward <e.gentry@...>
Sent: Donnerstag, 26. Mai 2022 22:48
To: Jim Amsden <jamsden@...>; Robert Baillargeon <rbaillargeon@...>; Andrii Berezovskyi <andriib@...>; Eran Gery <eran.gery@...>; oslc-op@...; David Honey2 <david.honey@...>
Subject: Re: [oslc-op] Link profiles

 

Sorry I’ve missed the discussion today. It’s a holiday here. 

 

One thing for me is very clear. If by link we mean a single predicate then we always know where it is stored. Always. It is stored with the subject of the link. Always. 

 

We don’t store statements about resources we don’t control. And I certainly should not trust a statement made by another about a resource that belongs to me. 

 

Now if we understand a link more semantically then Jim’s suggestion that the concept “satisfies” could be expressed with two different predicates “satisfies” and “satisfies by” each potentially stored on the corresponding side is something we might consider. But I’d suggest as a second phase since nothing like this exists to my knowledge 


From: Jim Amsden <jamsden@...>
Sent: Thursday, May 26, 2022 9:33:00 PM
To: Robert Baillargeon <
rbaillargeon@...>; Andrii Berezovskyi <andriib@...>; Eran Gery <eran.gery@...>; Gentry, Edward <e.gentry@...>; oslc-op@... <oslc-op@...>; David Honey2 <david.honey@...>
Subject: RE: [oslc-op] Link profiles

 

I am specifically not proposing to store backlinks. What I’m suggesting is that which link is the forward link depends on the use case the servers are trying to support. So rather I’m proposing using constraints as a means of discovering and perhaps specifying in a profile, what the links mean in a particular situation.

 

Once discovered where the link is stored, there should be standard way of determining the incoming/inverse link.

 

 

From: Robert Baillargeon <rbaillargeon@...>
Date: Thursday, May 26, 2022 at 3:12 PM
To: Jim Amsden <
jamsden@...>, Andrii Berezovskyi <andriib@...>, Eran Gery <eran.gery@...>, "e.gentry@..." <e.gentry@...>, "oslc-op@..." <oslc-op@...>, David Honey2 <david.honey@...>
Subject: [EXTERNAL] Re: [oslc-op] Link profiles

 

I'm always for only storing the forward link. It has a clear advantage in the ability to better manage the configurations and the composition of configurations. If I could get rid of backlinks I would. ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

I'm always for only storing the forward link.  It has a clear advantage in the ability to better manage the configurations and the composition of configurations.  If I could get rid of backlinks I would. 

 

When moving entirely to reverse link discovery, I would also note that we will need to have some behaviors in the tools to address when a discovery task fails due to downstream authentication, timeout, or otherwise.  We have seen situations where the inverse link is not visible and user confusion about the cause.

 

That is an interesting thought that we could discover link ownership by inspecting the shape.  Let me consider that path and see if that is complete with the information we would expect.

 

 

 

The other interesting point is to 

Chief Product Officer – Linked Data

418 N. Main Street 2nd Floor/Suite 200, Royal Oak, Michigan 48067, USA
Ph: 716 261 8338 
sodiuswillert.com

 

 

Try out our Jira and Confluence OSLC Tools on the Atlassian Marketplace


From: oslc-op@... <oslc-op@...> on behalf of David Honey2 via lists.oasis-open-projects.org <david.honey=ibm.com@...>
Sent: Thursday, May 26, 2022 2:59 PM
To: Jim Amsden <
jamsden@...>; Andrii Berezovskyi <andriib@...>; Eran Gery <eran.gery@...>; e.gentry@... <e.gentry@...>
Cc:
oslc-op@... <oslc-op@...>
Subject: Re: [oslc-op] 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.

 

From: Jim Amsden <jamsden@...>
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

This Message Is From an External Sender

This message came from outside your organization.

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

Unless otherwise stated above:

IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU


Gentry, Edward <e.gentry@...>
 

Hi Eran,

 

Yes OSLC query for opt out makes sense, and it’s straight forward. we should discuss.

 

From: Eran Gery <eran.gery@...>
Sent: Freitag, 27. Mai 2022 10:30
To: Gentry, Edward <e.gentry@...>; Jim Amsden <jamsden@...>; Robert Baillargeon <rbaillargeon@...>; Andrii Berezovskyi <andriib@...>; oslc-op@...; David Honey2 <david.honey@...>
Subject: RE: [oslc-op] Link profiles

 

Ed,

 

Thanks for coming back to version 0…. Indeed this is what we should focus on and we rather call it version 1.

As I mentioned in my other note, IMO for Opt-out we should not recommend link index as this is too far from how Jazz behaves. I think we should recommend OSLC query. That also reduces the requirement to support TRS in that case. And again, there is the CCM anomaly that still relies on backlinking.

 

Regards,

eran

 

From: Gentry, Edward <e.gentry@...>
Sent: Friday, 27 May 2022 10:00
To: Jim Amsden <jamsden@...>; Robert Baillargeon <rbaillargeon@...>; Andrii Berezovskyi <andriib@...>; Eran Gery <eran.gery@...>; oslc-op@...; David Honey2 <david.honey@...>
Subject: [EXTERNAL] RE: [oslc-op] Link profiles

 

A few ideas and observations and a concrete proposal: A helpful idea was proposed by our French Sodius Colleague whose name escapes me. He suggested in a conversation after our last call – and he’ll correct me if I don’t represent him well

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

A few ideas and observations and a concrete proposal:

 

  • A helpful idea was proposed by our French Sodius Colleague whose name escapes me.  He suggested in a conversation after our last call – and he’ll correct me if I don’t represent him well - that resource shapes should be extended so that tools could indicate which links they index.

 

  • @Jim Amsden’s  suggestion is also interesting (again he’ll correct me if I don’ represent him well) Each “link” might be represented as a pair of reciprocal predicates. For example: Let  (P and P’) be a pair of reciprocal predicates.  Then semantically, the triple (S0, P, O0), would have the same meaning the triple (O0, P’, S0).

 

  • Also I’d observe that “links” already have the concept of a reciprocal-names. Let N be the name for the P in triple (S0, P, O0) when viewed from the perceptive of S0. Then N’, the reciprocal-name is the title of P, is the title of P when it is viewed from the perspective of O2. Naturally if we had reciprocal predicates then the name of P’ (above) would be N’.

 

Besides discussing these more in detail, I’d like to make the following suggestion: We should reify the concept of link beyond just a single predicate – indeed above are examples of where we are already doing this. We should formalize what we mean by links, want kind of characteristics they may have: titles, reciprocal-links, reciprocal-labels, etc.

 

However has  @Eran Gery has emphasized all of this is beyond the scope of the first version of Link Profiles.

 

For me the link profile work would look something like this:

 

Version 0: Describe linking as it exists in ELM today keeping modifications to a minimum. Given the importance of GC’s for real life applications – and changing my position a bit here – this should include both opt in and opt out cases (with and out GCS), even though that means waving our hands a bit and just assuming the indexing for back links.  

 

Version 1: We reify links and include the concepts above and more.

 

 

From: Gentry, Edward <e.gentry@...>
Sent: Donnerstag, 26. Mai 2022 22:48
To: Jim Amsden <jamsden@...>; Robert Baillargeon <rbaillargeon@...>; Andrii Berezovskyi <andriib@...>; Eran Gery <eran.gery@...>; oslc-op@...; David Honey2 <david.honey@...>
Subject: Re: [oslc-op] Link profiles

 

Sorry I’ve missed the discussion today. It’s a holiday here. 

 

One thing for me is very clear. If by link we mean a single predicate then we always know where it is stored. Always. It is stored with the subject of the link. Always. 

 

We don’t store statements about resources we don’t control. And I certainly should not trust a statement made by another about a resource that belongs to me. 

 

Now if we understand a link more semantically then Jim’s suggestion that the concept “satisfies” could be expressed with two different predicates “satisfies” and “satisfies by” each potentially stored on the corresponding side is something we might consider. But I’d suggest as a second phase since nothing like this exists to my knowledge 


From: Jim Amsden <jamsden@...>
Sent: Thursday, May 26, 2022 9:33:00 PM
To: Robert Baillargeon <
rbaillargeon@...>; Andrii Berezovskyi <andriib@...>; Eran Gery <eran.gery@...>; Gentry, Edward <e.gentry@...>; oslc-op@... <oslc-op@...>; David Honey2 <david.honey@...>
Subject: RE: [oslc-op] Link profiles

 

I am specifically not proposing to store backlinks. What I’m suggesting is that which link is the forward link depends on the use case the servers are trying to support. So rather I’m proposing using constraints as a means of discovering and perhaps specifying in a profile, what the links mean in a particular situation.

 

Once discovered where the link is stored, there should be standard way of determining the incoming/inverse link.

 

 

From: Robert Baillargeon <rbaillargeon@...>
Date: Thursday, May 26, 2022 at 3:12 PM
To: Jim Amsden <
jamsden@...>, Andrii Berezovskyi <andriib@...>, Eran Gery <eran.gery@...>, "e.gentry@..." <e.gentry@...>, "oslc-op@..." <oslc-op@...>, David Honey2 <david.honey@...>
Subject: [EXTERNAL] Re: [oslc-op] Link profiles

 

I'm always for only storing the forward link. It has a clear advantage in the ability to better manage the configurations and the composition of configurations. If I could get rid of backlinks I would. ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

I'm always for only storing the forward link.  It has a clear advantage in the ability to better manage the configurations and the composition of configurations.  If I could get rid of backlinks I would. 

 

When moving entirely to reverse link discovery, I would also note that we will need to have some behaviors in the tools to address when a discovery task fails due to downstream authentication, timeout, or otherwise.  We have seen situations where the inverse link is not visible and user confusion about the cause.

 

That is an interesting thought that we could discover link ownership by inspecting the shape.  Let me consider that path and see if that is complete with the information we would expect.

 

 

 

The other interesting point is to 

Chief Product Officer – Linked Data

418 N. Main Street 2nd Floor/Suite 200, Royal Oak, Michigan 48067, USA
Ph: 716 261 8338 
sodiuswillert.com

 

 

Try out our Jira and Confluence OSLC Tools on the Atlassian Marketplace


From: oslc-op@... <oslc-op@...> on behalf of David Honey2 via lists.oasis-open-projects.org <david.honey=ibm.com@...>
Sent: Thursday, May 26, 2022 2:59 PM
To: Jim Amsden <
jamsden@...>; Andrii Berezovskyi <andriib@...>; Eran Gery <eran.gery@...>; e.gentry@... <e.gentry@...>
Cc:
oslc-op@... <oslc-op@...>
Subject: Re: [oslc-op] 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.

 

From: Jim Amsden <jamsden@...>
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

This Message Is From an External Sender

This message came from outside your organization.

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

Unless otherwise stated above:

IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU


Gentry, Edward <e.gentry@...>
 

Sorry I should have been more careful with my vocabulary. I meant reify in generic sense not in an RDF sense.

 

I meant to formalize what we mean by and expect from links – and indeed we already doing this.

 

 

From: David Honey2 <david.honey@...>
Sent: Freitag, 27. Mai 2022 11:23
To: Gentry, Edward <e.gentry@...>; Jim Amsden <jamsden@...>; Robert Baillargeon <rbaillargeon@...>; Andrii Berezovskyi <andriib@...>; Eran Gery <eran.gery@...>; oslc-op@...
Subject: RE: [oslc-op] Link profiles

 

Re: We should reify the concept of link beyond just a single predicate

OSLC avoids and discourages the use of reification. It can make querying problematic, especially for OSLC query. I don’t think we should set a precedent just for this use case.

 

From: Gentry, Edward <e.gentry@...>
Sent: 27 May 2022 08:00
To: Jim Amsden <jamsden@...>; Robert Baillargeon <rbaillargeon@...>; Andrii Berezovskyi <andriib@...>; Eran Gery <eran.gery@...>; oslc-op@...; David Honey2 <david.honey@...>
Subject: [EXTERNAL] RE: [oslc-op] Link profiles

 

A few ideas and observations and a concrete proposal: A helpful idea was proposed by our French Sodius Colleague whose name escapes me. He suggested in a conversation after our last call – and he’ll correct me if I don’t represent him well

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

A few ideas and observations and a concrete proposal:

 

  • A helpful idea was proposed by our French Sodius Colleague whose name escapes me.  He suggested in a conversation after our last call – and he’ll correct me if I don’t represent him well - that resource shapes should be extended so that tools could indicate which links they index.

 

  • @Jim Amsden’s  suggestion is also interesting (again he’ll correct me if I don’ represent him well) Each “link” might be represented as a pair of reciprocal predicates. For example: Let  (P and P’) be a pair of reciprocal predicates.  Then semantically, the triple (S0, P, O0), would have the same meaning the triple (O0, P’, S0).

 

  • Also I’d observe that “links” already have the concept of a reciprocal-names. Let N be the name for the P in triple (S0, P, O0) when viewed from the perceptive of S0. Then N’, the reciprocal-name is the title of P, is the title of P when it is viewed from the perspective of O2. Naturally if we had reciprocal predicates then the name of P’ (above) would be N’.

 

Besides discussing these more in detail, I’d like to make the following suggestion: We should reify the concept of link beyond just a single predicate – indeed above are examples of where we are already doing this. We should formalize what we mean by links, want kind of characteristics they may have: titles, reciprocal-links, reciprocal-labels, etc.

 

However has  @Eran Gery has emphasized all of this is beyond the scope of the first version of Link Profiles.

 

For me the link profile work would look something like this:

 

Version 0: Describe linking as it exists in ELM today keeping modifications to a minimum. Given the importance of GC’s for real life applications – and changing my position a bit here – this should include both opt in and opt out cases (with and out GCS), even though that means waving our hands a bit and just assuming the indexing for back links.  

 

Version 1: We reify links and include the concepts above and more.

 

 

From: Gentry, Edward <e.gentry@...>
Sent: Donnerstag, 26. Mai 2022 22:48
To: Jim Amsden <jamsden@...>; Robert Baillargeon <rbaillargeon@...>; Andrii Berezovskyi <andriib@...>; Eran Gery <eran.gery@...>; oslc-op@...; David Honey2 <david.honey@...>
Subject: Re: [oslc-op] Link profiles

 

Sorry I’ve missed the discussion today. It’s a holiday here. 

 

One thing for me is very clear. If by link we mean a single predicate then we always know where it is stored. Always. It is stored with the subject of the link. Always. 

 

We don’t store statements about resources we don’t control. And I certainly should not trust a statement made by another about a resource that belongs to me. 

 

Now if we understand a link more semantically then Jim’s suggestion that the concept “satisfies” could be expressed with two different predicates “satisfies” and “satisfies by” each potentially stored on the corresponding side is something we might consider. But I’d suggest as a second phase since nothing like this exists to my knowledge 


From: Jim Amsden <jamsden@...>
Sent: Thursday, May 26, 2022 9:33:00 PM
To: Robert Baillargeon <
rbaillargeon@...>; Andrii Berezovskyi <andriib@...>; Eran Gery <eran.gery@...>; Gentry, Edward <e.gentry@...>; oslc-op@... <oslc-op@...>; David Honey2 <david.honey@...>
Subject: RE: [oslc-op] Link profiles

 

I am specifically not proposing to store backlinks. What I’m suggesting is that which link is the forward link depends on the use case the servers are trying to support. So rather I’m proposing using constraints as a means of discovering and perhaps specifying in a profile, what the links mean in a particular situation.

 

Once discovered where the link is stored, there should be standard way of determining the incoming/inverse link.

 

 

From: Robert Baillargeon <rbaillargeon@...>
Date: Thursday, May 26, 2022 at 3:12 PM
To: Jim Amsden <
jamsden@...>, Andrii Berezovskyi <andriib@...>, Eran Gery <eran.gery@...>, "e.gentry@..." <e.gentry@...>, "oslc-op@..." <oslc-op@...>, David Honey2 <david.honey@...>
Subject: [EXTERNAL] Re: [oslc-op] Link profiles

 

I'm always for only storing the forward link. It has a clear advantage in the ability to better manage the configurations and the composition of configurations. If I could get rid of backlinks I would. ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

I'm always for only storing the forward link.  It has a clear advantage in the ability to better manage the configurations and the composition of configurations.  If I could get rid of backlinks I would. 

 

When moving entirely to reverse link discovery, I would also note that we will need to have some behaviors in the tools to address when a discovery task fails due to downstream authentication, timeout, or otherwise.  We have seen situations where the inverse link is not visible and user confusion about the cause.

 

That is an interesting thought that we could discover link ownership by inspecting the shape.  Let me consider that path and see if that is complete with the information we would expect.

 

 

 

The other interesting point is to 

Chief Product Officer – Linked Data

418 N. Main Street 2nd Floor/Suite 200, Royal Oak, Michigan 48067, USA
Ph: 716 261 8338 
sodiuswillert.com

 

 

Try out our Jira and Confluence OSLC Tools on the Atlassian Marketplace


From: oslc-op@... <oslc-op@...> on behalf of David Honey2 via lists.oasis-open-projects.org <david.honey=ibm.com@...>
Sent: Thursday, May 26, 2022 2:59 PM
To: Jim Amsden <
jamsden@...>; Andrii Berezovskyi <andriib@...>; Eran Gery <eran.gery@...>; e.gentry@... <e.gentry@...>
Cc:
oslc-op@... <oslc-op@...>
Subject: Re: [oslc-op] 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.

 

From: Jim Amsden <jamsden@...>
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

This Message Is From an External Sender

This message came from outside your organization.

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

Unless otherwise stated above:

IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU

Unless otherwise stated above:

IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU


"Eran Gery"
 

David

 

Can you please look up the link storage/discovery tables I sent and confirm? These tables are a practical basis to discuss the linking profile.

Would be great if you can do before tomorrow’s meeting… shouldn’t take you more than 5 minutes.

 

(See XL attachment to the original message)

 

Thanks

Eran

 

From: Eran Gery
Sent: Friday, 27 May 2022 11:24
To: David Honey2 <david.honey@...>; Jim Amsden <jamsden@...>; Andrii Berezovskyi <andriib@...>; e.gentry@...; Michael Rowe <michael.rowe@...>
Cc: oslc-op@...
Subject: RE: [EXTERNAL] Link profiles

 

Hi David, all,

 

Again, pulling back towards the pragmatic principle “let’s define a profile that at least guarantees ELM (jazz) cross linking”.

Let’s push to the background for now discussions around “good architectural specification”. Profiles here are all about (ugly) pragmatics.

 

Note: there are some ELM anomalies we may not include in a profile, only document. Obviously we need ELM to fix that. Some examples:

  • ELM currently does not support AM/AM linking (RMM). Obviously we cannot enforce this in a profile. We are pushing hard to fix it this year.
  • While in opt-in mode incoming link discovery is done via LDX, RM expects AM to support OSLC query for that. This means that LDX support is not enough for an AM provider, and it needs to support both LDX feed and OSLC query. Again we can document it but recommend LDX usage across all opt-in incoming link discoveries.
  • In OptOut mode (no config) ELM assumes backlinking. So for example if a Jira connector creates a link to a requirement, it also needs to create a backlink on the requirement. Ouch.

 

So for that purpose a question about “opt out” mode: how does ELM behave here, between using a single link with incoming implemented with OSLC query, vs. using backlinks. As far as I recall, all CCM links are using backlinking, and other (RM:QM, RM:AM, AM:QM) use a query. Is that correct?

 

As for shapes based discovery: I think we also need to specify the storage policy, as creating apps based on discovery requires a higher level of sophistication and preparing for variability. Between two providers, if both have shapes that claim ownership, one need to concede. So to simplify we need to provide ownership map. Also another related question: do the shapes change between opt-out and opt-in mode? For example. RM in opt-out would keep a backlink to CCM. In opt-in not. Does it maintain two shapes?

 

Also for Anrew’s request attached is a spreadsheet  I created at the time for opt-in mode. We also need to create on for opt-out.  @David Honey2

Can you please confirm its accuracy?

Hope this makes sense…

Regards,

Eran

 

 

From: David Honey2 <david.honey@...>
Sent: Thursday, 26 May 2022 21:59
To: Jim Amsden <
jamsden@...>; Andrii Berezovskyi <andriib@...>; Eran Gery <eran.gery@...>; e.gentry@...
Cc:
oslc-op@...
Subject: RE: [EXTERNAL] 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.

 

From: Jim Amsden <jamsden@...>
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

This Message Is From an External Sender

This message came from outside your organization.

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


David Honey2
 

Thu 2nd June is a UK public holiday, so I won’t be attending the OSLC OP meeting.

I will look at this next week.

 

From: Eran Gery <eran.gery@...>
Sent: 01 June 2022 10:14
To: David Honey2 <david.honey@...>
Cc: oslc-op@...; Jim Amsden <jamsden@...>; Andrii Berezovskyi <andriib@...>; Michael Rowe <michael.rowe@...>; e.gentry@...
Subject: RE: [EXTERNAL] Link profiles

 

David

 

Can you please look up the link storage/discovery tables I sent and confirm? These tables are a practical basis to discuss the linking profile.

Would be great if you can do before tomorrow’s meeting… shouldn’t take you more than 5 minutes.

 

(See XL attachment to the original message)

 

Thanks

Eran

 

From: Eran Gery
Sent: Friday, 27 May 2022 11:24
To: David Honey2 <david.honey@...>; Jim Amsden <jamsden@...>; Andrii Berezovskyi <andriib@...>; e.gentry@...; Michael Rowe <michael.rowe@...>
Cc: oslc-op@...
Subject: RE: [EXTERNAL] Link profiles

 

Hi David, all,

 

Again, pulling back towards the pragmatic principle “let’s define a profile that at least guarantees ELM (jazz) cross linking”.

Let’s push to the background for now discussions around “good architectural specification”. Profiles here are all about (ugly) pragmatics.

 

Note: there are some ELM anomalies we may not include in a profile, only document. Obviously we need ELM to fix that. Some examples:

  • ELM currently does not support AM/AM linking (RMM). Obviously we cannot enforce this in a profile. We are pushing hard to fix it this year.
  • While in opt-in mode incoming link discovery is done via LDX, RM expects AM to support OSLC query for that. This means that LDX support is not enough for an AM provider, and it needs to support both LDX feed and OSLC query. Again we can document it but recommend LDX usage across all opt-in incoming link discoveries.
  • In OptOut mode (no config) ELM assumes backlinking. So for example if a Jira connector creates a link to a requirement, it also needs to create a backlink on the requirement. Ouch.

 

So for that purpose a question about “opt out” mode: how does ELM behave here, between using a single link with incoming implemented with OSLC query, vs. using backlinks. As far as I recall, all CCM links are using backlinking, and other (RM:QM, RM:AM, AM:QM) use a query. Is that correct?

 

As for shapes based discovery: I think we also need to specify the storage policy, as creating apps based on discovery requires a higher level of sophistication and preparing for variability. Between two providers, if both have shapes that claim ownership, one need to concede. So to simplify we need to provide ownership map. Also another related question: do the shapes change between opt-out and opt-in mode? For example. RM in opt-out would keep a backlink to CCM. In opt-in not. Does it maintain two shapes?

 

Also for Anrew’s request attached is a spreadsheet  I created at the time for opt-in mode. We also need to create on for opt-out.  @David Honey2

Can you please confirm its accuracy?

Hope this makes sense…

Regards,

Eran

 

 

From: David Honey2 <david.honey@...>
Sent: Thursday, 26 May 2022 21:59
To: Jim Amsden <
jamsden@...>; Andrii Berezovskyi <andriib@...>; Eran Gery <eran.gery@...>; e.gentry@...
Cc:
oslc-op@...
Subject: RE: [EXTERNAL] 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.

 

From: Jim Amsden <jamsden@...>
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

This Message Is From an External Sender

This message came from outside your organization.

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

Unless otherwise stated above:

IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU


Andrii Berezovskyi
 

Following the discussion today, please find attached the spreadsheet with the updates made during the call. The profiles in the second sheet are described in https://docs.google.com/spreadsheets/d/1fjjGvHrv2yPru8S_6HNoJ5atn6617cUfFUDRz5xAfKQ/edit#gid=0

 

Cell F22 in the second sheet is an “anomalous anomaly”, which requires TRS but not configuration management, I simply marked it with the Bidi profile + an ad-hoc TRS support requirement.

 

The idea of the table is too keep the product names in the row 8 and 19 as it and replace the product names in the column D with OSLC domain names to indicate in the future which profiles 3rd-party tools need to support to integrate with the corresponding Jazz products.

 

Looking forward to your feedback.

 

/Andrew

 

From: David Honey2 <david.honey@...>
Date: Wednesday, 1 June 2022, W22 at 11:41
To: Eran Gery <eran.gery@...>
Cc: "oslc-op@..." <oslc-op@...>, Jim Amsden <jamsden@...>, Andrii Berezovskyi <andriib@...>, Michael Rowe <michael.rowe@...>, "e.gentry@..." <e.gentry@...>
Subject: RE: Link profiles

 

Thu 2nd June is a UK public holiday, so I won’t be attending the OSLC OP meeting.

I will look at this next week.

 

From: Eran Gery <eran.gery@...>
Sent: 01 June 2022 10:14
To: David Honey2 <david.honey@...>
Cc: oslc-op@...; Jim Amsden <jamsden@...>; Andrii Berezovskyi <andriib@...>; Michael Rowe <michael.rowe@...>; e.gentry@...
Subject: RE: [EXTERNAL] Link profiles

 

David

 

Can you please look up the link storage/discovery tables I sent and confirm? These tables are a practical basis to discuss the linking profile.

Would be great if you can do before tomorrow’s meeting… shouldn’t take you more than 5 minutes.

 

(See XL attachment to the original message)

 

Thanks

Eran

 

From: Eran Gery
Sent: Friday, 27 May 2022 11:24
To: David Honey2 <david.honey@...>; Jim Amsden <jamsden@...>; Andrii Berezovskyi <andriib@...>; e.gentry@...; Michael Rowe <michael.rowe@...>
Cc: oslc-op@...
Subject: RE: [EXTERNAL] Link profiles

 

Hi David, all,

 

Again, pulling back towards the pragmatic principle “let’s define a profile that at least guarantees ELM (jazz) cross linking”.

Let’s push to the background for now discussions around “good architectural specification”. Profiles here are all about (ugly) pragmatics.

 

Note: there are some ELM anomalies we may not include in a profile, only document. Obviously we need ELM to fix that. Some examples:

-          ELM currently does not support AM/AM linking (RMM). Obviously we cannot enforce this in a profile. We are pushing hard to fix it this year.

-          While in opt-in mode incoming link discovery is done via LDX, RM expects AM to support OSLC query for that. This means that LDX support is not enough for an AM provider, and it needs to support both LDX feed and OSLC query. Again we can document it but recommend LDX usage across all opt-in incoming link discoveries.

-          In OptOut mode (no config) ELM assumes backlinking. So for example if a Jira connector creates a link to a requirement, it also needs to create a backlink on the requirement. Ouch.

 

So for that purpose a question about “opt out” mode: how does ELM behave here, between using a single link with incoming implemented with OSLC query, vs. using backlinks. As far as I recall, all CCM links are using backlinking, and other (RM:QM, RM:AM, AM:QM) use a query. Is that correct?

 

As for shapes based discovery: I think we also need to specify the storage policy, as creating apps based on discovery requires a higher level of sophistication and preparing for variability. Between two providers, if both have shapes that claim ownership, one need to concede. So to simplify we need to provide ownership map. Also another related question: do the shapes change between opt-out and opt-in mode? For example. RM in opt-out would keep a backlink to CCM. In opt-in not. Does it maintain two shapes?

 

Also for Anrew’s request attached is a spreadsheet  I created at the time for opt-in mode. We also need to create on for opt-out.  @David Honey2

Can you please confirm its accuracy?

Hope this makes sense…

Regards,

Eran

 

 

From: David Honey2 <david.honey@...>
Sent: Thursday, 26 May 2022 21:59
To: Jim Amsden <
jamsden@...>; Andrii Berezovskyi <andriib@...>; Eran Gery <eran.gery@...>; e.gentry@...
Cc:
oslc-op@...
Subject: RE: [EXTERNAL] 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.

 

From: Jim Amsden <jamsden@...>
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

This Message Is From an External Sender

This message came from outside your organization.

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

Unless otherwise stated above:

IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU