22.9 oslc-op Weekly Contributors Meeting


Gentry, Edward
 

Hi All,

 

I’m traveling today and so will miss our meeting this afternoon.

 

@David Honey2, could you please arrange a meeting with John Vasta for me regarding the authentication in the link Profile? We should be able to keep it to 30 minutes. Find something that works for him in the morning and I’ll make it work.

 

Cheers,

 

Ed


"Eran Gery"
 

Ed

 

Please review the link ownership text

 

Link ownership

 

In bi-derctional linking scenarios both OSLC participants are aware of links across their owned resources and enable link visibility and navigation at each side. Nevertheless, storing a link at both sides is considered an ill-practice as it is essentially replication of data. This may result in inconsistencies as links are updated or deleted, since maintaining consistency requires synchronization across the providers on any update. Therefore, the recommended practice is to store links on one of the participants, and use link discovery by the other participant. Therefore, there needs to be an agreed convention on which side should store the link. OSLC links have an incoming and outgoing sides, determined by the role of the link. Usually one side will have an active predicate name, for example "implements" and the other side will have a passive predicate name, in this example it would be "implemented by". The active side is also considered the outgoing side, and the passive the incoming side. The convention is that the link is stored with the resource on the outgoing side, i.e. the resource with the active predicate. The incoming side would discover the links with one of the discovery methods discussed in the following sections. Note the creation of the link may be initiated by both providers. In case that the link is initiated by the incoming side provider, it needs to store it with the resource on the outgoing side provider. This is discussed in the put on resources section.

 

Thanks

eran

 

From: Gentry, Edward <e.gentry@...>
Sent: Thursday, 22 September 2022 15:16
To: oslc-op@...; james_e_gammon@...; Eran Gery <eran.gery@...>; Jim Amsden <jamsden@...>; David Honey2 <david.honey@...>
Subject: [EXTERNAL] 22.9 oslc-op Weekly Contributors Meeting

 

Hi All, I’m traveling today and so will miss our meeting this afternoon. @David Honey2, could you please arrange a meeting with John Vasta for me regarding the authentication in the link Profile? We should be able to keep it to 30 minutes. 

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Hi All,

 

I’m traveling today and so will miss our meeting this afternoon.

 

@David Honey2, could you please arrange a meeting with John Vasta for me regarding the authentication in the link Profile? We should be able to keep it to 30 minutes. Find something that works for him in the morning and I’ll make it work.

 

Cheers,

 

Ed


"Eran Gery"
 

Ed,

 

Jim did not accept the text as he is not sure that the “store on outgoing side” is respected by ELM.

Can you comment on that.

One comment I have is that it is enough that it is the 90% case as a principle. We can document exceptions.

There are clearly exceptions in opt-out mode that there are still backlinks with CCM. We can document that as an exception.

Jim suggested that we may have to use OSLC shapes to determine the owner, IMO it is a no go for the reason that the maturity level of the bi-diretional profile is far from mandating OSLC shapes. Actually, none of the linking profile require support for shapes.

So the only options I see

  1. Specify “owned by outgoing end” is a rule with some exceptions related to ELM.
  2. Have a detailed per link type (predicate) specification based on all existing OSLC domain links.
  3. A combination of both.

 

Please speak up…

 

Eran

 

From: oslc-op@... <oslc-op@...> On Behalf Of "Eran Gery"
Sent: Thursday, 22 September 2022 15:59
To: Gentry, Edward <e.gentry@...>
Cc: oslc-op@...
Subject: [EXTERNAL] Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

Ed Please review the link ownership text Link ownership In bi-derctional linking scenarios both OSLC participants are aware of links across their owned resources and enable link visibility and navigation at each side. Nevertheless ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Ed

 

Please review the link ownership text

 

Link ownership

 

In bi-derctional linking scenarios both OSLC participants are aware of links across their owned resources and enable link visibility and navigation at each side. Nevertheless, storing a link at both sides is considered an ill-practice as it is essentially replication of data. This may result in inconsistencies as links are updated or deleted, since maintaining consistency requires synchronization across the providers on any update. Therefore, the recommended practice is to store links on one of the participants, and use link discovery by the other participant. Therefore, there needs to be an agreed convention on which side should store the link. OSLC links have an incoming and outgoing sides, determined by the role of the link. Usually one side will have an active predicate name, for example "implements" and the other side will have a passive predicate name, in this example it would be "implemented by". The active side is also considered the outgoing side, and the passive the incoming side. The convention is that the link is stored with the resource on the outgoing side, i.e. the resource with the active predicate. The incoming side would discover the links with one of the discovery methods discussed in the following sections. Note the creation of the link may be initiated by both providers. In case that the link is initiated by the incoming side provider, it needs to store it with the resource on the outgoing side provider. This is discussed in the put on resources section.

 

Thanks

eran

 

From: Gentry, Edward <e.gentry@...>
Sent: Thursday, 22 September 2022 15:16
To: oslc-op@...; james_e_gammon@...; Eran Gery <eran.gery@...>; Jim Amsden <jamsden@...>; David Honey2 <david.honey@...>
Subject: [EXTERNAL] 22.9 oslc-op Weekly Contributors Meeting

 

Hi All, I’m traveling today and so will miss our meeting this afternoon. @David Honey2, could you please arrange a meeting with John Vasta for me regarding the authentication in the link Profile? We should be able to keep it to 30 minutes. 

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Hi All,

 

I’m traveling today and so will miss our meeting this afternoon.

 

@David Honey2, could you please arrange a meeting with John Vasta for me regarding the authentication in the link Profile? We should be able to keep it to 30 minutes. Find something that works for him in the morning and I’ll make it work.

 

Cheers,

 

Ed


Jim Amsden
 

You could just use a normative table of outgoing and incoming link types (i.e., property and inverse properties). However, it would be nice if this was machine readable, and an extension to ResourceShapes would do that.

 

We could also decide to declare property and inverse properties in the OSLC vocabularies. That wouldn’t require any extensions. Since OSLC does not rely on RDF inferencing, this shouldn’t create any problems.

 

 

 

 

 

From: <oslc-op@...> on behalf of Eran Gery <eran.gery@...>
Reply-To: "oslc-op@..." <oslc-op@...>, Eran Gery <eran.gery@...>
Date: Friday, September 23, 2022 at 10:24 AM
To: Eran Gery <eran.gery@...>, "Gentry, Edward" <e.gentry@...>
Cc: "oslc-op@..." <oslc-op@...>
Subject: [EXTERNAL] Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

Ed, Jim did not accept the text as he is not sure that the “store on outgoing side” is respected by ELM. Can you comment on that. One comment I have is that it is enough that it is the 90% case as a principle. We can document exceptions. ‍ ‍

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Ed,

 

Jim did not accept the text as he is not sure that the “store on outgoing side” is respected by ELM.

Can you comment on that.

One comment I have is that it is enough that it is the 90% case as a principle. We can document exceptions.

There are clearly exceptions in opt-out mode that there are still backlinks with CCM. We can document that as an exception.

Jim suggested that we may have to use OSLC shapes to determine the owner, IMO it is a no go for the reason that the maturity level of the bi-diretional profile is far from mandating OSLC shapes. Actually, none of the linking profile require support for shapes.

So the only options I see

  1. Specify “owned by outgoing end” is a rule with some exceptions related to ELM.
  2. Have a detailed per link type (predicate) specification based on all existing OSLC domain links.
  3. A combination of both.

 

Please speak up…

 

Eran

 

From: oslc-op@... <oslc-op@...> On Behalf Of "Eran Gery"
Sent: Thursday, 22 September 2022 15:59
To: Gentry, Edward <e.gentry@...>
Cc: oslc-op@...
Subject: [EXTERNAL] Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

Ed Please review the link ownership text Link ownership In bi-derctional linking scenarios both OSLC participants are aware of links across their owned resources and enable link visibility and navigation at each side. Nevertheless ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Ed

 

Please review the link ownership text

 

Link ownership

 

In bi-derctional linking scenarios both OSLC participants are aware of links across their owned resources and enable link visibility and navigation at each side. Nevertheless, storing a link at both sides is considered an ill-practice as it is essentially replication of data. This may result in inconsistencies as links are updated or deleted, since maintaining consistency requires synchronization across the providers on any update. Therefore, the recommended practice is to store links on one of the participants, and use link discovery by the other participant. Therefore, there needs to be an agreed convention on which side should store the link. OSLC links have an incoming and outgoing sides, determined by the role of the link. Usually one side will have an active predicate name, for example "implements" and the other side will have a passive predicate name, in this example it would be "implemented by". The active side is also considered the outgoing side, and the passive the incoming side. The convention is that the link is stored with the resource on the outgoing side, i.e. the resource with the active predicate. The incoming side would discover the links with one of the discovery methods discussed in the following sections. Note the creation of the link may be initiated by both providers. In case that the link is initiated by the incoming side provider, it needs to store it with the resource on the outgoing side provider. This is discussed in the put on resources section.

 

Thanks

eran

 

From: Gentry, Edward <e.gentry@...>
Sent: Thursday, 22 September 2022 15:16
To: oslc-op@...; james_e_gammon@...; Eran Gery <eran.gery@...>; Jim Amsden <jamsden@...>; David Honey2 <david.honey@...>
Subject: [EXTERNAL] 22.9 oslc-op Weekly Contributors Meeting

 

Hi All, I’m traveling today and so will miss our meeting this afternoon. @David Honey2, could you please arrange a meeting with John Vasta for me regarding the authentication in the link Profile? We should be able to keep it to 30 minutes. 

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Hi All,

 

I’m traveling today and so will miss our meeting this afternoon.

 

@David Honey2, could you please arrange a meeting with John Vasta for me regarding the authentication in the link Profile? We should be able to keep it to 30 minutes. Find something that works for him in the morning and I’ll make it work.

 

Cheers,

 

Ed


Gentry, Edward
 

 

Agree: ResourceShape and the list. But this is not nearly enough for a link profile.

 

For our link profile I would suggest two sections:

 

  1. non-GC aware: In this case we store triples on both sides (with its inverse property), according to the domains in the table
  2. GC aware:  We store only one link, and the current IBM-ELM convention is that these links are always stored on the dependent side as Eran describes. Links from the others side can be queried via OSLC Query or some more general purpose index if available (e.g. LDX or MID’s gLinx, etc. ).

 

As I’ve argued before since the goal of the link profile is interoperability, and since IBM-ELM is still has the largest install base of OSLC providers, some level of the link profile must insure that interoperability with IBM-ELM works out-of-the-box. I have no love or loyalty more for IBM-ELM; I’m thinking pragmatically about the customer value of a  link profile specification with which does not insure interoperability with IBM-ELM.

 

On a related note: last week, I had an interesting conversation with a product manager from PTC/Codebeamer. He indicated intention to increase their support for OSLC. Perhaps as more tools join the party force IBM-ELM to fix the many places where it is not even OCLS 2.0 compliant (or has defects), and perhaps move in the 3.0+ world.

 

From: oslc-op@... <oslc-op@...> On Behalf Of Jim Amsden via lists.oasis-open-projects.org
Sent: Freitag, 23. September 2022 20:21
To: oslc-op@...
Subject: Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

You could just use a normative table of outgoing and incoming link types (i.e., property and inverse properties). However, it would be nice if this was machine readable, and an extension to ResourceShapes would do that.

 

We could also decide to declare property and inverse properties in the OSLC vocabularies. That wouldn’t require any extensions. Since OSLC does not rely on RDF inferencing, this shouldn’t create any problems.

 

 

 

 

 

From: <oslc-op@...> on behalf of Eran Gery <eran.gery@...>
Reply-To: "oslc-op@..." <oslc-op@...>, Eran Gery <eran.gery@...>
Date: Friday, September 23, 2022 at 10:24 AM
To: Eran Gery <eran.gery@...>, "Gentry, Edward" <e.gentry@...>
Cc: "oslc-op@..." <oslc-op@...>
Subject: [EXTERNAL] Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

Ed, Jim did not accept the text as he is not sure that the “store on outgoing side” is respected by ELM. Can you comment on that. One comment I have is that it is enough that it is the 90% case as a principle. We can document exceptions. ‍ ‍

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Ed,

 

Jim did not accept the text as he is not sure that the “store on outgoing side” is respected by ELM.

Can you comment on that.

One comment I have is that it is enough that it is the 90% case as a principle. We can document exceptions.

There are clearly exceptions in opt-out mode that there are still backlinks with CCM. We can document that as an exception.

Jim suggested that we may have to use OSLC shapes to determine the owner, IMO it is a no go for the reason that the maturity level of the bi-diretional profile is far from mandating OSLC shapes. Actually, none of the linking profile require support for shapes.

So the only options I see

  1. Specify “owned by outgoing end” is a rule with some exceptions related to ELM.
  2. Have a detailed per link type (predicate) specification based on all existing OSLC domain links.
  3. A combination of both.

 

Please speak up…

 

Eran

 

From: oslc-op@... <oslc-op@...> On Behalf Of "Eran Gery"
Sent: Thursday, 22 September 2022 15:59
To: Gentry, Edward <e.gentry@...>
Cc: oslc-op@...
Subject: [EXTERNAL] Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

Ed Please review the link ownership text Link ownership In bi-derctional linking scenarios both OSLC participants are aware of links across their owned resources and enable link visibility and navigation at each side. Nevertheless ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Ed

 

Please review the link ownership text

 

Link ownership

 

In bi-derctional linking scenarios both OSLC participants are aware of links across their owned resources and enable link visibility and navigation at each side. Nevertheless, storing a link at both sides is considered an ill-practice as it is essentially replication of data. This may result in inconsistencies as links are updated or deleted, since maintaining consistency requires synchronization across the providers on any update. Therefore, the recommended practice is to store links on one of the participants, and use link discovery by the other participant. Therefore, there needs to be an agreed convention on which side should store the link. OSLC links have an incoming and outgoing sides, determined by the role of the link. Usually one side will have an active predicate name, for example "implements" and the other side will have a passive predicate name, in this example it would be "implemented by". The active side is also considered the outgoing side, and the passive the incoming side. The convention is that the link is stored with the resource on the outgoing side, i.e. the resource with the active predicate. The incoming side would discover the links with one of the discovery methods discussed in the following sections. Note the creation of the link may be initiated by both providers. In case that the link is initiated by the incoming side provider, it needs to store it with the resource on the outgoing side provider. This is discussed in the put on resources section.

 

Thanks

eran

 

From: Gentry, Edward <e.gentry@...>
Sent: Thursday, 22 September 2022 15:16
To: oslc-op@...; james_e_gammon@...; Eran Gery <eran.gery@...>; Jim Amsden <jamsden@...>; David Honey2 <david.honey@...>
Subject: [EXTERNAL] 22.9 oslc-op Weekly Contributors Meeting

 

Hi All, I’m traveling today and so will miss our meeting this afternoon. @David Honey2, could you please arrange a meeting with John Vasta for me regarding the authentication in the link Profile? We should be able to keep it to 30 minutes. 

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Hi All,

 

I’m traveling today and so will miss our meeting this afternoon.

 

@David Honey2, could you please arrange a meeting with John Vasta for me regarding the authentication in the link Profile? We should be able to keep it to 30 minutes. Find something that works for him in the morning and I’ll make it work.

 

Cheers,

 

Ed


Ollerton, Patrick
 

Hi Ed,

 

I’m a Product Manager for PTC – specifically for Windchill Modeler our MBSE tool. Me and Tanu Jolly (PM for Windchill PLM) are now more engaged in this community and hoping to contribute. PTC have implemented OSLC in several of our tools already – Windchill Modeler, Windchill RV&S (formerly Integrity) and also Windchill PLM. (Demos here: https://www.youtube.com/watch?v=FceIwmq25hw ) We’re planning to add Codebeamer to that list very soon.

 

I would be cautious using term like “GC aware” as I don’t think a standard should be tied to a particular software vendor’s capabilities or terminology. One of the criticisms I hear of OSLC is that it’s designed to work for IBM tools, not generalized for the majority. I don’t think that is totally accurate, but IBM tools are the main frame of reference, as you state.

 

PTC have implemented a level of bi-directional capabilities in our tools using queries - we call it reverse lookup. Crucially, we don’t have the situation where there may be a huge number of providers in our tools though, so we are able to easily discover providers to query (or have it pre-defined) and for it to scale by running queries on multiple providers simultaneously. Although this might not work in cases where there numerous providers involved, it can be made to work if OSLC is implemented in a certain way.

 

Regards,

Patrick

 

 

From: oslc-op@... <oslc-op@...> On Behalf Of Gentry, Edward via lists.oasis-open-projects.org
Sent: Monday, September 26, 2022 3:07 PM
To: oslc-op@...; jamsden@...
Subject: Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

 

Agree: ResourceShape and the list. But this is not nearly enough for a link profile.

 

For our link profile I would suggest two sections:

 

  1. non-GC aware: In this case we store triples on both sides (with its inverse property), according to the domains in the table
  2. GC aware:  We store only one link, and the current IBM-ELM convention is that these links are always stored on the dependent side as Eran describes. Links from the others side can be queried via OSLC Query or some more general purpose index if available (e.g. LDX or MID’s gLinx, etc. ).

 

As I’ve argued before since the goal of the link profile is interoperability, and since IBM-ELM is still has the largest install base of OSLC providers, some level of the link profile must insure that interoperability with IBM-ELM works out-of-the-box. I have no love or loyalty more for IBM-ELM; I’m thinking pragmatically about the customer value of a  link profile specification with which does not insure interoperability with IBM-ELM.

 

On a related note: last week, I had an interesting conversation with a product manager from PTC/Codebeamer. He indicated intention to increase their support for OSLC. Perhaps as more tools join the party force IBM-ELM to fix the many places where it is not even OCLS 2.0 compliant (or has defects), and perhaps move in the 3.0+ world.

 

From: oslc-op@... <oslc-op@...> On Behalf Of Jim Amsden via lists.oasis-open-projects.org
Sent: Freitag, 23. September 2022 20:21
To: oslc-op@...
Subject: Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

You could just use a normative table of outgoing and incoming link types (i.e., property and inverse properties). However, it would be nice if this was machine readable, and an extension to ResourceShapes would do that.

 

We could also decide to declare property and inverse properties in the OSLC vocabularies. That wouldn’t require any extensions. Since OSLC does not rely on RDF inferencing, this shouldn’t create any problems.

 

 

 

 

 

From: <oslc-op@...> on behalf of Eran Gery <eran.gery@...>
Reply-To: "oslc-op@..." <oslc-op@...>, Eran Gery <eran.gery@...>
Date: Friday, September 23, 2022 at 10:24 AM
To: Eran Gery <eran.gery@...>, "Gentry, Edward" <e.gentry@...>
Cc: "oslc-op@..." <oslc-op@...>
Subject: [EXTERNAL] Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

Ed, Jim did not accept the text as he is not sure that the “store on outgoing side” is respected by ELM. Can you comment on that. One comment I have is that it is enough that it is the 90% case as a principle. We can document exceptions. ‍ ‍

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Ed,

 

Jim did not accept the text as he is not sure that the “store on outgoing side” is respected by ELM.

Can you comment on that.

One comment I have is that it is enough that it is the 90% case as a principle. We can document exceptions.

There are clearly exceptions in opt-out mode that there are still backlinks with CCM. We can document that as an exception.

Jim suggested that we may have to use OSLC shapes to determine the owner, IMO it is a no go for the reason that the maturity level of the bi-diretional profile is far from mandating OSLC shapes. Actually, none of the linking profile require support for shapes.

So the only options I see

  1. Specify “owned by outgoing end” is a rule with some exceptions related to ELM.
  2. Have a detailed per link type (predicate) specification based on all existing OSLC domain links.
  3. A combination of both.

 

Please speak up…

 

Eran

 

From: oslc-op@... <oslc-op@...> On Behalf Of "Eran Gery"
Sent: Thursday, 22 September 2022 15:59
To: Gentry, Edward <e.gentry@...>
Cc: oslc-op@...
Subject: [EXTERNAL] Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

Ed Please review the link ownership text Link ownership In bi-derctional linking scenarios both OSLC participants are aware of links across their owned resources and enable link visibility and navigation at each side. Nevertheless ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Ed

 

Please review the link ownership text

 

Link ownership

 

In bi-derctional linking scenarios both OSLC participants are aware of links across their owned resources and enable link visibility and navigation at each side. Nevertheless, storing a link at both sides is considered an ill-practice as it is essentially replication of data. This may result in inconsistencies as links are updated or deleted, since maintaining consistency requires synchronization across the providers on any update. Therefore, the recommended practice is to store links on one of the participants, and use link discovery by the other participant. Therefore, there needs to be an agreed convention on which side should store the link. OSLC links have an incoming and outgoing sides, determined by the role of the link. Usually one side will have an active predicate name, for example "implements" and the other side will have a passive predicate name, in this example it would be "implemented by". The active side is also considered the outgoing side, and the passive the incoming side. The convention is that the link is stored with the resource on the outgoing side, i.e. the resource with the active predicate. The incoming side would discover the links with one of the discovery methods discussed in the following sections. Note the creation of the link may be initiated by both providers. In case that the link is initiated by the incoming side provider, it needs to store it with the resource on the outgoing side provider. This is discussed in the put on resources section.

 

Thanks

eran

 

From: Gentry, Edward <e.gentry@...>
Sent: Thursday, 22 September 2022 15:16
To: oslc-op@...; james_e_gammon@...; Eran Gery <eran.gery@...>; Jim Amsden <jamsden@...>; David Honey2 <david.honey@...>
Subject: [EXTERNAL] 22.9 oslc-op Weekly Contributors Meeting

 

Hi All, I’m traveling today and so will miss our meeting this afternoon. @David Honey2, could you please arrange a meeting with John Vasta for me regarding the authentication in the link Profile? We should be able to keep it to 30 minutes. 

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Hi All,

 

I’m traveling today and so will miss our meeting this afternoon.

 

@David Honey2, could you please arrange a meeting with John Vasta for me regarding the authentication in the link Profile? We should be able to keep it to 30 minutes. Find something that works for him in the morning and I’ll make it work.

 

Cheers,

 

Ed


"Eran Gery"
 

Patrick
So what is your policy for link storage?
Which side stores the link?

Thanks
Eran



On 26 Sep 2022, at 17:29, Ollerton, Patrick <pollerton@...> wrote:


Hi Ed, I’m a Product Manager for PTC – specifically for Windchill Modeler our MBSE tool. Me and Tanu Jolly (PM for Windchill PLM) are now more engaged in this community and hoping to contribute. PTC have implemented OSLC in several of our tools
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
 
ZjQcmQRYFpfptBannerEnd

Hi Ed,

 

I’m a Product Manager for PTC – specifically for Windchill Modeler our MBSE tool. Me and Tanu Jolly (PM for Windchill PLM) are now more engaged in this community and hoping to contribute. PTC have implemented OSLC in several of our tools already – Windchill Modeler, Windchill RV&S (formerly Integrity) and also Windchill PLM. (Demos here: https://www.youtube.com/watch?v=FceIwmq25hw ) We’re planning to add Codebeamer to that list very soon.

 

I would be cautious using term like “GC aware” as I don’t think a standard should be tied to a particular software vendor’s capabilities or terminology. One of the criticisms I hear of OSLC is that it’s designed to work for IBM tools, not generalized for the majority. I don’t think that is totally accurate, but IBM tools are the main frame of reference, as you state.

 

PTC have implemented a level of bi-directional capabilities in our tools using queries - we call it reverse lookup. Crucially, we don’t have the situation where there may be a huge number of providers in our tools though, so we are able to easily discover providers to query (or have it pre-defined) and for it to scale by running queries on multiple providers simultaneously. Although this might not work in cases where there numerous providers involved, it can be made to work if OSLC is implemented in a certain way.

 

Regards,

Patrick

 

 

From: oslc-op@... <oslc-op@...> On Behalf Of Gentry, Edward via lists.oasis-open-projects.org
Sent: Monday, September 26, 2022 3:07 PM
To: oslc-op@...; jamsden@...
Subject: Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

 

Agree: ResourceShape and the list. But this is not nearly enough for a link profile.

 

For our link profile I would suggest two sections:

 

  1. non-GC aware: In this case we store triples on both sides (with its inverse property), according to the domains in the table
  2. GC aware:  We store only one link, and the current IBM-ELM convention is that these links are always stored on the dependent side as Eran describes. Links from the others side can be queried via OSLC Query or some more general purpose index if available (e.g. LDX or MID’s gLinx, etc. ).

 

As I’ve argued before since the goal of the link profile is interoperability, and since IBM-ELM is still has the largest install base of OSLC providers, some level of the link profile must insure that interoperability with IBM-ELM works out-of-the-box. I have no love or loyalty more for IBM-ELM; I’m thinking pragmatically about the customer value of a  link profile specification with which does not insure interoperability with IBM-ELM.

 

On a related note: last week, I had an interesting conversation with a product manager from PTC/Codebeamer. He indicated intention to increase their support for OSLC. Perhaps as more tools join the party force IBM-ELM to fix the many places where it is not even OCLS 2.0 compliant (or has defects), and perhaps move in the 3.0+ world.

 

From: oslc-op@... <oslc-op@...> On Behalf Of Jim Amsden via lists.oasis-open-projects.org
Sent: Freitag, 23. September 2022 20:21
To: oslc-op@...
Subject: Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

You could just use a normative table of outgoing and incoming link types (i.e., property and inverse properties). However, it would be nice if this was machine readable, and an extension to ResourceShapes would do that.

 

We could also decide to declare property and inverse properties in the OSLC vocabularies. That wouldn’t require any extensions. Since OSLC does not rely on RDF inferencing, this shouldn’t create any problems.

 

 

 

 

 

From: <oslc-op@...> on behalf of Eran Gery <eran.gery@...>
Reply-To: "oslc-op@..." <oslc-op@...>, Eran Gery <eran.gery@...>
Date: Friday, September 23, 2022 at 10:24 AM
To: Eran Gery <eran.gery@...>, "Gentry, Edward" <e.gentry@...>
Cc: "oslc-op@..." <oslc-op@...>
Subject: [EXTERNAL] Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

Ed, Jim did not accept the text as he is not sure that the “store on outgoing side” is respected by ELM. Can you comment on that. One comment I have is that it is enough that it is the 90% case as a principle. We can document exceptions. ‍ ‍

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Ed,

 

Jim did not accept the text as he is not sure that the “store on outgoing side” is respected by ELM.

Can you comment on that.

One comment I have is that it is enough that it is the 90% case as a principle. We can document exceptions.

There are clearly exceptions in opt-out mode that there are still backlinks with CCM. We can document that as an exception.

Jim suggested that we may have to use OSLC shapes to determine the owner, IMO it is a no go for the reason that the maturity level of the bi-diretional profile is far from mandating OSLC shapes. Actually, none of the linking profile require support for shapes.

So the only options I see

  1. Specify “owned by outgoing end” is a rule with some exceptions related to ELM.
  2. Have a detailed per link type (predicate) specification based on all existing OSLC domain links.
  3. A combination of both.

 

Please speak up…

 

Eran

 

From: oslc-op@... <oslc-op@...> On Behalf Of "Eran Gery"
Sent: Thursday, 22 September 2022 15:59
To: Gentry, Edward <e.gentry@...>
Cc: oslc-op@...
Subject: [EXTERNAL] Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

Ed Please review the link ownership text Link ownership In bi-derctional linking scenarios both OSLC participants are aware of links across their owned resources and enable link visibility and navigation at each side. Nevertheless ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Ed

 

Please review the link ownership text

 

Link ownership

 

In bi-derctional linking scenarios both OSLC participants are aware of links across their owned resources and enable link visibility and navigation at each side. Nevertheless, storing a link at both sides is considered an ill-practice as it is essentially replication of data. This may result in inconsistencies as links are updated or deleted, since maintaining consistency requires synchronization across the providers on any update. Therefore, the recommended practice is to store links on one of the participants, and use link discovery by the other participant. Therefore, there needs to be an agreed convention on which side should store the link. OSLC links have an incoming and outgoing sides, determined by the role of the link. Usually one side will have an active predicate name, for example "implements" and the other side will have a passive predicate name, in this example it would be "implemented by". The active side is also considered the outgoing side, and the passive the incoming side. The convention is that the link is stored with the resource on the outgoing side, i.e. the resource with the active predicate. The incoming side would discover the links with one of the discovery methods discussed in the following sections. Note the creation of the link may be initiated by both providers. In case that the link is initiated by the incoming side provider, it needs to store it with the resource on the outgoing side provider. This is discussed in the put on resources section.

 

Thanks

eran

 

From: Gentry, Edward <e.gentry@...>
Sent: Thursday, 22 September 2022 15:16
To: oslc-op@...; james_e_gammon@...; Eran Gery <eran.gery@...>; Jim Amsden <jamsden@...>; David Honey2 <david.honey@...>
Subject: [EXTERNAL] 22.9 oslc-op Weekly Contributors Meeting

 

Hi All, I’m traveling today and so will miss our meeting this afternoon. @David Honey2, could you please arrange a meeting with John Vasta for me regarding the authentication in the link Profile? We should be able to keep it to 30 minutes. 

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Hi All,

 

I’m traveling today and so will miss our meeting this afternoon.

 

@David Honey2, could you please arrange a meeting with John Vasta for me regarding the authentication in the link Profile? We should be able to keep it to 30 minutes. Find something that works for him in the morning and I’ll make it work.

 

Cheers,

 

Ed


Gentry, Edward
 

Hi Patrick,

 

As I said I’m really glad to see other vendors joining the conversation.

 

How we make links really does depend on whether we are in a global configuration aware environment or not. In a global configuration aware environment we don’t need to make back  link, and indeed should make them because the system becomes very brittle and reuse becomes difficult.

 

Applications should not be forced to create backlinks just because some other applications may not understand or support global configurations. (Recall that global configurations are also an OSLC specification).

 

I really don’t see any other solution than to have two modes.

 

Cheers,

 

Ed

 

 

From: Ollerton, Patrick <pollerton@...>
Sent: Montag, 26. September 2022 16:29
To: oslc-op@...; Gentry, Edward <e.gentry@...>; jamsden@...
Subject: RE: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

Sie erhalten nicht oft eine E-Mail von pollerton@.... Erfahren Sie, warum dies wichtig ist

Hi Ed,

 

I’m a Product Manager for PTC – specifically for Windchill Modeler our MBSE tool. Me and Tanu Jolly (PM for Windchill PLM) are now more engaged in this community and hoping to contribute. PTC have implemented OSLC in several of our tools already – Windchill Modeler, Windchill RV&S (formerly Integrity) and also Windchill PLM. (Demos here: https://www.youtube.com/watch?v=FceIwmq25hw ) We’re planning to add Codebeamer to that list very soon.

 

I would be cautious using term like “GC aware” as I don’t think a standard should be tied to a particular software vendor’s capabilities or terminology. One of the criticisms I hear of OSLC is that it’s designed to work for IBM tools, not generalized for the majority. I don’t think that is totally accurate, but IBM tools are the main frame of reference, as you state.

 

PTC have implemented a level of bi-directional capabilities in our tools using queries - we call it reverse lookup. Crucially, we don’t have the situation where there may be a huge number of providers in our tools though, so we are able to easily discover providers to query (or have it pre-defined) and for it to scale by running queries on multiple providers simultaneously. Although this might not work in cases where there numerous providers involved, it can be made to work if OSLC is implemented in a certain way.

 

Regards,

Patrick

 

 

From: oslc-op@... <oslc-op@...> On Behalf Of Gentry, Edward via lists.oasis-open-projects.org
Sent: Monday, September 26, 2022 3:07 PM
To: oslc-op@...; jamsden@...
Subject: Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

 

Agree: ResourceShape and the list. But this is not nearly enough for a link profile.

 

For our link profile I would suggest two sections:

 

  1. non-GC aware: In this case we store triples on both sides (with its inverse property), according to the domains in the table
  2. GC aware:  We store only one link, and the current IBM-ELM convention is that these links are always stored on the dependent side as Eran describes. Links from the others side can be queried via OSLC Query or some more general purpose index if available (e.g. LDX or MID’s gLinx, etc. ).

 

As I’ve argued before since the goal of the link profile is interoperability, and since IBM-ELM is still has the largest install base of OSLC providers, some level of the link profile must insure that interoperability with IBM-ELM works out-of-the-box. I have no love or loyalty more for IBM-ELM; I’m thinking pragmatically about the customer value of a  link profile specification with which does not insure interoperability with IBM-ELM.

 

On a related note: last week, I had an interesting conversation with a product manager from PTC/Codebeamer. He indicated intention to increase their support for OSLC. Perhaps as more tools join the party force IBM-ELM to fix the many places where it is not even OCLS 2.0 compliant (or has defects), and perhaps move in the 3.0+ world.

 

From: oslc-op@... <oslc-op@...> On Behalf Of Jim Amsden via lists.oasis-open-projects.org
Sent: Freitag, 23. September 2022 20:21
To: oslc-op@...
Subject: Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

You could just use a normative table of outgoing and incoming link types (i.e., property and inverse properties). However, it would be nice if this was machine readable, and an extension to ResourceShapes would do that.

 

We could also decide to declare property and inverse properties in the OSLC vocabularies. That wouldn’t require any extensions. Since OSLC does not rely on RDF inferencing, this shouldn’t create any problems.

 

 

 

 

 

From: <oslc-op@...> on behalf of Eran Gery <eran.gery@...>
Reply-To: "oslc-op@..." <oslc-op@...>, Eran Gery <eran.gery@...>
Date: Friday, September 23, 2022 at 10:24 AM
To: Eran Gery <eran.gery@...>, "Gentry, Edward" <e.gentry@...>
Cc: "oslc-op@..." <oslc-op@...>
Subject: [EXTERNAL] Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

Ed, Jim did not accept the text as he is not sure that the “store on outgoing side” is respected by ELM. Can you comment on that. One comment I have is that it is enough that it is the 90% case as a principle. We can document exceptions. ‍ ‍

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Ed,

 

Jim did not accept the text as he is not sure that the “store on outgoing side” is respected by ELM.

Can you comment on that.

One comment I have is that it is enough that it is the 90% case as a principle. We can document exceptions.

There are clearly exceptions in opt-out mode that there are still backlinks with CCM. We can document that as an exception.

Jim suggested that we may have to use OSLC shapes to determine the owner, IMO it is a no go for the reason that the maturity level of the bi-diretional profile is far from mandating OSLC shapes. Actually, none of the linking profile require support for shapes.

So the only options I see

  1. Specify “owned by outgoing end” is a rule with some exceptions related to ELM.
  2. Have a detailed per link type (predicate) specification based on all existing OSLC domain links.
  3. A combination of both.

 

Please speak up…

 

Eran

 

From: oslc-op@... <oslc-op@...> On Behalf Of "Eran Gery"
Sent: Thursday, 22 September 2022 15:59
To: Gentry, Edward <e.gentry@...>
Cc: oslc-op@...
Subject: [EXTERNAL] Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

Ed Please review the link ownership text Link ownership In bi-derctional linking scenarios both OSLC participants are aware of links across their owned resources and enable link visibility and navigation at each side. Nevertheless ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Ed

 

Please review the link ownership text

 

Link ownership

 

In bi-derctional linking scenarios both OSLC participants are aware of links across their owned resources and enable link visibility and navigation at each side. Nevertheless, storing a link at both sides is considered an ill-practice as it is essentially replication of data. This may result in inconsistencies as links are updated or deleted, since maintaining consistency requires synchronization across the providers on any update. Therefore, the recommended practice is to store links on one of the participants, and use link discovery by the other participant. Therefore, there needs to be an agreed convention on which side should store the link. OSLC links have an incoming and outgoing sides, determined by the role of the link. Usually one side will have an active predicate name, for example "implements" and the other side will have a passive predicate name, in this example it would be "implemented by". The active side is also considered the outgoing side, and the passive the incoming side. The convention is that the link is stored with the resource on the outgoing side, i.e. the resource with the active predicate. The incoming side would discover the links with one of the discovery methods discussed in the following sections. Note the creation of the link may be initiated by both providers. In case that the link is initiated by the incoming side provider, it needs to store it with the resource on the outgoing side provider. This is discussed in the put on resources section.

 

Thanks

eran

 

From: Gentry, Edward <e.gentry@...>
Sent: Thursday, 22 September 2022 15:16
To: oslc-op@...; james_e_gammon@...; Eran Gery <eran.gery@...>; Jim Amsden <jamsden@...>; David Honey2 <david.honey@...>
Subject: [EXTERNAL] 22.9 oslc-op Weekly Contributors Meeting

 

Hi All, I’m traveling today and so will miss our meeting this afternoon. @David Honey2, could you please arrange a meeting with John Vasta for me regarding the authentication in the link Profile? We should be able to keep it to 30 minutes. 

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Hi All,

 

I’m traveling today and so will miss our meeting this afternoon.

 

@David Honey2, could you please arrange a meeting with John Vasta for me regarding the authentication in the link Profile? We should be able to keep it to 30 minutes. Find something that works for him in the morning and I’ll make it work.

 

Cheers,

 

Ed


Gentry, Edward
 

If I understand Patrick correctly we should always store links on both sides, just because some vendors haven’t implemented global configurations yet. This seems profoundly limiting.

 

Why should we give-up all the power and flexibly of global configurations.

 

The only way forward it to know which environment we are in and either make links on one side – with GCs – or on both sides – without.

 

 

From: Eran Gery <eran.gery@...>
Sent: Montag, 26. September 2022 16:42
To: oslc-op@...; pollerton@...
Cc: Gentry, Edward <e.gentry@...>; Jim Amsden <jamsden@...>
Subject: RE: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

Patrick

So what is your policy for link storage?

Which side stores the link?

 

Thanks

Eran

 



On 26 Sep 2022, at 17:29, Ollerton, Patrick <pollerton@...> wrote:



Hi Ed, I’m a Product Manager for PTC – specifically for Windchill Modeler our MBSE tool. Me and Tanu Jolly (PM for Windchill PLM) are now more engaged in this community and hoping to contribute. PTC have implemented OSLC in several of our tools

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Hi Ed,

 

I’m a Product Manager for PTC – specifically for Windchill Modeler our MBSE tool. Me and Tanu Jolly (PM for Windchill PLM) are now more engaged in this community and hoping to contribute. PTC have implemented OSLC in several of our tools already – Windchill Modeler, Windchill RV&S (formerly Integrity) and also Windchill PLM. (Demos here: https://www.youtube.com/watch?v=FceIwmq25hw ) We’re planning to add Codebeamer to that list very soon.

 

I would be cautious using term like “GC aware” as I don’t think a standard should be tied to a particular software vendor’s capabilities or terminology. One of the criticisms I hear of OSLC is that it’s designed to work for IBM tools, not generalized for the majority. I don’t think that is totally accurate, but IBM tools are the main frame of reference, as you state.

 

PTC have implemented a level of bi-directional capabilities in our tools using queries - we call it reverse lookup. Crucially, we don’t have the situation where there may be a huge number of providers in our tools though, so we are able to easily discover providers to query (or have it pre-defined) and for it to scale by running queries on multiple providers simultaneously. Although this might not work in cases where there numerous providers involved, it can be made to work if OSLC is implemented in a certain way.

 

Regards,

Patrick

 

 

From: oslc-op@... <oslc-op@...> On Behalf Of Gentry, Edward via lists.oasis-open-projects.org
Sent: Monday, September 26, 2022 3:07 PM
To: oslc-op@...; jamsden@...
Subject: Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

 

Agree: ResourceShape and the list. But this is not nearly enough for a link profile.

 

For our link profile I would suggest two sections:

 

  1. non-GC aware: In this case we store triples on both sides (with its inverse property), according to the domains in the table
  2. GC aware:  We store only one link, and the current IBM-ELM convention is that these links are always stored on the dependent side as Eran describes. Links from the others side can be queried via OSLC Query or some more general purpose index if available (e.g. LDX or MID’s gLinx, etc. ).

 

As I’ve argued before since the goal of the link profile is interoperability, and since IBM-ELM is still has the largest install base of OSLC providers, some level of the link profile must insure that interoperability with IBM-ELM works out-of-the-box. I have no love or loyalty more for IBM-ELM; I’m thinking pragmatically about the customer value of a  link profile specification with which does not insure interoperability with IBM-ELM.

 

On a related note: last week, I had an interesting conversation with a product manager from PTC/Codebeamer. He indicated intention to increase their support for OSLC. Perhaps as more tools join the party force IBM-ELM to fix the many places where it is not even OCLS 2.0 compliant (or has defects), and perhaps move in the 3.0+ world.

 

From: oslc-op@... <oslc-op@...> On Behalf Of Jim Amsden via lists.oasis-open-projects.org
Sent: Freitag, 23. September 2022 20:21
To: oslc-op@...
Subject: Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

You could just use a normative table of outgoing and incoming link types (i.e., property and inverse properties). However, it would be nice if this was machine readable, and an extension to ResourceShapes would do that.

 

We could also decide to declare property and inverse properties in the OSLC vocabularies. That wouldn’t require any extensions. Since OSLC does not rely on RDF inferencing, this shouldn’t create any problems.

 

 

 

 

 

From: <oslc-op@...> on behalf of Eran Gery <eran.gery@...>
Reply-To: "oslc-op@..." <oslc-op@...>, Eran Gery <eran.gery@...>
Date: Friday, September 23, 2022 at 10:24 AM
To: Eran Gery <eran.gery@...>, "Gentry, Edward" <e.gentry@...>
Cc: "oslc-op@..." <oslc-op@...>
Subject: [EXTERNAL] Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

Ed, Jim did not accept the text as he is not sure that the “store on outgoing side” is respected by ELM. Can you comment on that. One comment I have is that it is enough that it is the 90% case as a principle. We can document exceptions. ‍ ‍

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Ed,

 

Jim did not accept the text as he is not sure that the “store on outgoing side” is respected by ELM.

Can you comment on that.

One comment I have is that it is enough that it is the 90% case as a principle. We can document exceptions.

There are clearly exceptions in opt-out mode that there are still backlinks with CCM. We can document that as an exception.

Jim suggested that we may have to use OSLC shapes to determine the owner, IMO it is a no go for the reason that the maturity level of the bi-diretional profile is far from mandating OSLC shapes. Actually, none of the linking profile require support for shapes.

So the only options I see

  1. Specify “owned by outgoing end” is a rule with some exceptions related to ELM.
  2. Have a detailed per link type (predicate) specification based on all existing OSLC domain links.
  3. A combination of both.

 

Please speak up…

 

Eran

 

From: oslc-op@... <oslc-op@...> On Behalf Of "Eran Gery"
Sent: Thursday, 22 September 2022 15:59
To: Gentry, Edward <e.gentry@...>
Cc: oslc-op@...
Subject: [EXTERNAL] Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

Ed Please review the link ownership text Link ownership In bi-derctional linking scenarios both OSLC participants are aware of links across their owned resources and enable link visibility and navigation at each side. Nevertheless ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Ed

 

Please review the link ownership text

 

Link ownership

 

In bi-derctional linking scenarios both OSLC participants are aware of links across their owned resources and enable link visibility and navigation at each side. Nevertheless, storing a link at both sides is considered an ill-practice as it is essentially replication of data. This may result in inconsistencies as links are updated or deleted, since maintaining consistency requires synchronization across the providers on any update. Therefore, the recommended practice is to store links on one of the participants, and use link discovery by the other participant. Therefore, there needs to be an agreed convention on which side should store the link. OSLC links have an incoming and outgoing sides, determined by the role of the link. Usually one side will have an active predicate name, for example "implements" and the other side will have a passive predicate name, in this example it would be "implemented by". The active side is also considered the outgoing side, and the passive the incoming side. The convention is that the link is stored with the resource on the outgoing side, i.e. the resource with the active predicate. The incoming side would discover the links with one of the discovery methods discussed in the following sections. Note the creation of the link may be initiated by both providers. In case that the link is initiated by the incoming side provider, it needs to store it with the resource on the outgoing side provider. This is discussed in the put on resources section.

 

Thanks

eran

 

From: Gentry, Edward <e.gentry@...>
Sent: Thursday, 22 September 2022 15:16
To: oslc-op@...; james_e_gammon@...; Eran Gery <eran.gery@...>; Jim Amsden <jamsden@...>; David Honey2 <david.honey@...>
Subject: [EXTERNAL] 22.9 oslc-op Weekly Contributors Meeting

 

Hi All, I’m traveling today and so will miss our meeting this afternoon. @David Honey2, could you please arrange a meeting with John Vasta for me regarding the authentication in the link Profile? We should be able to keep it to 30 minutes. 

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Hi All,

 

I’m traveling today and so will miss our meeting this afternoon.

 

@David Honey2, could you please arrange a meeting with John Vasta for me regarding the authentication in the link Profile? We should be able to keep it to 30 minutes. Find something that works for him in the morning and I’ll make it work.

 

Cheers,

 

Ed


Ollerton, Patrick
 

Hi Ed,

 

Apologies if I’ve got the names wrong here, but isn’t the OSLC spec called Config Mgmt? And the IBM software capability is called Global Configurations?

Not meaning to be a pedant, just important to be clear I think.

 

I guess I’ve also not been clear on some other points – please see response to Eran below.

 

 

Patrick

So what is your policy for link storage?

Which side stores the link?

 

Thanks

Eran

 

 

With PTC, always the tool that is used to create the link – the client – stores the link, and only that tool. We have considered creating “backlinks” – i.e. a link on both sides, but have concerns on how these would be maintained over time. (For example when a linked object get deleted, or say a package full of linked objects are deleted in one operation. It would require the backlinks to also be deleted in the external tool(s) – which probably wouldn’t scale)

 

Personally I feel having a “centralized link repository” that all lifecycle tools can connect to, where all links are stored and can be accessed, makes a lot of sense architecturally. But practically speaking it would be challenging to implement, especially if connecting tools are from different vendors.

 

Regards,

Patrick

 

 

From: oslc-op@... <oslc-op@...> On Behalf Of Gentry, Edward via lists.oasis-open-projects.org
Sent: Monday, September 26, 2022 3:54 PM
To: Ollerton, Patrick <pollerton@...>; oslc-op@...; jamsden@...
Subject: Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

Hi Patrick,

 

As I said I’m really glad to see other vendors joining the conversation.

 

How we make links really does depend on whether we are in a global configuration aware environment or not. In a global configuration aware environment we don’t need to make back  link, and indeed should make them because the system becomes very brittle and reuse becomes difficult.

 

Applications should not be forced to create backlinks just because some other applications may not understand or support global configurations. (Recall that global configurations are also an OSLC specification).

 

I really don’t see any other solution than to have two modes.

 

Cheers,

 

Ed

 

 

From: Ollerton, Patrick <pollerton@...>
Sent: Montag, 26. September 2022 16:29
To: oslc-op@...; Gentry, Edward <e.gentry@...>; jamsden@...
Subject: RE: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

Sie erhalten nicht oft eine E-Mail von pollerton@.... Erfahren Sie, warum dies wichtig ist

Hi Ed,

 

I’m a Product Manager for PTC – specifically for Windchill Modeler our MBSE tool. Me and Tanu Jolly (PM for Windchill PLM) are now more engaged in this community and hoping to contribute. PTC have implemented OSLC in several of our tools already – Windchill Modeler, Windchill RV&S (formerly Integrity) and also Windchill PLM. (Demos here: https://www.youtube.com/watch?v=FceIwmq25hw ) We’re planning to add Codebeamer to that list very soon.

 

I would be cautious using term like “GC aware” as I don’t think a standard should be tied to a particular software vendor’s capabilities or terminology. One of the criticisms I hear of OSLC is that it’s designed to work for IBM tools, not generalized for the majority. I don’t think that is totally accurate, but IBM tools are the main frame of reference, as you state.

 

PTC have implemented a level of bi-directional capabilities in our tools using queries - we call it reverse lookup. Crucially, we don’t have the situation where there may be a huge number of providers in our tools though, so we are able to easily discover providers to query (or have it pre-defined) and for it to scale by running queries on multiple providers simultaneously. Although this might not work in cases where there numerous providers involved, it can be made to work if OSLC is implemented in a certain way.

 

Regards,

Patrick

 

 

From: oslc-op@... <oslc-op@...> On Behalf Of Gentry, Edward via lists.oasis-open-projects.org
Sent: Monday, September 26, 2022 3:07 PM
To: oslc-op@...; jamsden@...
Subject: Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

 

Agree: ResourceShape and the list. But this is not nearly enough for a link profile.

 

For our link profile I would suggest two sections:

 

  1. non-GC aware: In this case we store triples on both sides (with its inverse property), according to the domains in the table
  2. GC aware:  We store only one link, and the current IBM-ELM convention is that these links are always stored on the dependent side as Eran describes. Links from the others side can be queried via OSLC Query or some more general purpose index if available (e.g. LDX or MID’s gLinx, etc. ).

 

As I’ve argued before since the goal of the link profile is interoperability, and since IBM-ELM is still has the largest install base of OSLC providers, some level of the link profile must insure that interoperability with IBM-ELM works out-of-the-box. I have no love or loyalty more for IBM-ELM; I’m thinking pragmatically about the customer value of a  link profile specification with which does not insure interoperability with IBM-ELM.

 

On a related note: last week, I had an interesting conversation with a product manager from PTC/Codebeamer. He indicated intention to increase their support for OSLC. Perhaps as more tools join the party force IBM-ELM to fix the many places where it is not even OCLS 2.0 compliant (or has defects), and perhaps move in the 3.0+ world.

 

From: oslc-op@... <oslc-op@...> On Behalf Of Jim Amsden via lists.oasis-open-projects.org
Sent: Freitag, 23. September 2022 20:21
To: oslc-op@...
Subject: Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

You could just use a normative table of outgoing and incoming link types (i.e., property and inverse properties). However, it would be nice if this was machine readable, and an extension to ResourceShapes would do that.

 

We could also decide to declare property and inverse properties in the OSLC vocabularies. That wouldn’t require any extensions. Since OSLC does not rely on RDF inferencing, this shouldn’t create any problems.

 

 

 

 

 

From: <oslc-op@...> on behalf of Eran Gery <eran.gery@...>
Reply-To: "oslc-op@..." <oslc-op@...>, Eran Gery <eran.gery@...>
Date: Friday, September 23, 2022 at 10:24 AM
To: Eran Gery <eran.gery@...>, "Gentry, Edward" <e.gentry@...>
Cc: "oslc-op@..." <oslc-op@...>
Subject: [EXTERNAL] Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

Ed, Jim did not accept the text as he is not sure that the “store on outgoing side” is respected by ELM. Can you comment on that. One comment I have is that it is enough that it is the 90% case as a principle. We can document exceptions. ‍ ‍

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Ed,

 

Jim did not accept the text as he is not sure that the “store on outgoing side” is respected by ELM.

Can you comment on that.

One comment I have is that it is enough that it is the 90% case as a principle. We can document exceptions.

There are clearly exceptions in opt-out mode that there are still backlinks with CCM. We can document that as an exception.

Jim suggested that we may have to use OSLC shapes to determine the owner, IMO it is a no go for the reason that the maturity level of the bi-diretional profile is far from mandating OSLC shapes. Actually, none of the linking profile require support for shapes.

So the only options I see

  1. Specify “owned by outgoing end” is a rule with some exceptions related to ELM.
  2. Have a detailed per link type (predicate) specification based on all existing OSLC domain links.
  3. A combination of both.

 

Please speak up…

 

Eran

 

From: oslc-op@... <oslc-op@...> On Behalf Of "Eran Gery"
Sent: Thursday, 22 September 2022 15:59
To: Gentry, Edward <e.gentry@...>
Cc: oslc-op@...
Subject: [EXTERNAL] Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

Ed Please review the link ownership text Link ownership In bi-derctional linking scenarios both OSLC participants are aware of links across their owned resources and enable link visibility and navigation at each side. Nevertheless ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Ed

 

Please review the link ownership text

 

Link ownership

 

In bi-derctional linking scenarios both OSLC participants are aware of links across their owned resources and enable link visibility and navigation at each side. Nevertheless, storing a link at both sides is considered an ill-practice as it is essentially replication of data. This may result in inconsistencies as links are updated or deleted, since maintaining consistency requires synchronization across the providers on any update. Therefore, the recommended practice is to store links on one of the participants, and use link discovery by the other participant. Therefore, there needs to be an agreed convention on which side should store the link. OSLC links have an incoming and outgoing sides, determined by the role of the link. Usually one side will have an active predicate name, for example "implements" and the other side will have a passive predicate name, in this example it would be "implemented by". The active side is also considered the outgoing side, and the passive the incoming side. The convention is that the link is stored with the resource on the outgoing side, i.e. the resource with the active predicate. The incoming side would discover the links with one of the discovery methods discussed in the following sections. Note the creation of the link may be initiated by both providers. In case that the link is initiated by the incoming side provider, it needs to store it with the resource on the outgoing side provider. This is discussed in the put on resources section.

 

Thanks

eran

 

From: Gentry, Edward <e.gentry@...>
Sent: Thursday, 22 September 2022 15:16
To: oslc-op@...; james_e_gammon@...; Eran Gery <eran.gery@...>; Jim Amsden <jamsden@...>; David Honey2 <david.honey@...>
Subject: [EXTERNAL] 22.9 oslc-op Weekly Contributors Meeting

 

Hi All, I’m traveling today and so will miss our meeting this afternoon. @David Honey2, could you please arrange a meeting with John Vasta for me regarding the authentication in the link Profile? We should be able to keep it to 30 minutes. 

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Hi All,

 

I’m traveling today and so will miss our meeting this afternoon.

 

@David Honey2, could you please arrange a meeting with John Vasta for me regarding the authentication in the link Profile? We should be able to keep it to 30 minutes. Find something that works for him in the morning and I’ll make it work.

 

Cheers,

 

Ed


Gentry, Edward
 

Yes fair enough I certainly meant the OSLC Config Management

 

From: Ollerton, Patrick <pollerton@...>
Sent: Montag, 26. September 2022 17:02
To: oslc-op@...; Gentry, Edward <e.gentry@...>; jamsden@...
Subject: RE: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

Hi Ed,

 

Apologies if I’ve got the names wrong here, but isn’t the OSLC spec called Config Mgmt? And the IBM software capability is called Global Configurations?

Not meaning to be a pedant, just important to be clear I think.

 

I guess I’ve also not been clear on some other points – please see response to Eran below.

 

 

Patrick

So what is your policy for link storage?

Which side stores the link?

 

Thanks

Eran

 

 

With PTC, always the tool that is used to create the link – the client – stores the link, and only that tool. We have considered creating “backlinks” – i.e. a link on both sides, but have concerns on how these would be maintained over time. (For example when a linked object get deleted, or say a package full of linked objects are deleted in one operation. It would require the backlinks to also be deleted in the external tool(s) – which probably wouldn’t scale)

 

Personally I feel having a “centralized link repository” that all lifecycle tools can connect to, where all links are stored and can be accessed, makes a lot of sense architecturally. But practically speaking it would be challenging to implement, especially if connecting tools are from different vendors.

 

Regards,

Patrick

 

 

From: oslc-op@... <oslc-op@...> On Behalf Of Gentry, Edward via lists.oasis-open-projects.org
Sent: Monday, September 26, 2022 3:54 PM
To: Ollerton, Patrick <pollerton@...>; oslc-op@...; jamsden@...
Subject: Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

Hi Patrick,

 

As I said I’m really glad to see other vendors joining the conversation.

 

How we make links really does depend on whether we are in a global configuration aware environment or not. In a global configuration aware environment we don’t need to make back  link, and indeed should make them because the system becomes very brittle and reuse becomes difficult.

 

Applications should not be forced to create backlinks just because some other applications may not understand or support global configurations. (Recall that global configurations are also an OSLC specification).

 

I really don’t see any other solution than to have two modes.

 

Cheers,

 

Ed

 

 

From: Ollerton, Patrick <pollerton@...>
Sent: Montag, 26. September 2022 16:29
To: oslc-op@...; Gentry, Edward <e.gentry@...>; jamsden@...
Subject: RE: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

Sie erhalten nicht oft eine E-Mail von pollerton@.... Erfahren Sie, warum dies wichtig ist

Hi Ed,

 

I’m a Product Manager for PTC – specifically for Windchill Modeler our MBSE tool. Me and Tanu Jolly (PM for Windchill PLM) are now more engaged in this community and hoping to contribute. PTC have implemented OSLC in several of our tools already – Windchill Modeler, Windchill RV&S (formerly Integrity) and also Windchill PLM. (Demos here: https://www.youtube.com/watch?v=FceIwmq25hw ) We’re planning to add Codebeamer to that list very soon.

 

I would be cautious using term like “GC aware” as I don’t think a standard should be tied to a particular software vendor’s capabilities or terminology. One of the criticisms I hear of OSLC is that it’s designed to work for IBM tools, not generalized for the majority. I don’t think that is totally accurate, but IBM tools are the main frame of reference, as you state.

 

PTC have implemented a level of bi-directional capabilities in our tools using queries - we call it reverse lookup. Crucially, we don’t have the situation where there may be a huge number of providers in our tools though, so we are able to easily discover providers to query (or have it pre-defined) and for it to scale by running queries on multiple providers simultaneously. Although this might not work in cases where there numerous providers involved, it can be made to work if OSLC is implemented in a certain way.

 

Regards,

Patrick

 

 

From: oslc-op@... <oslc-op@...> On Behalf Of Gentry, Edward via lists.oasis-open-projects.org
Sent: Monday, September 26, 2022 3:07 PM
To: oslc-op@...; jamsden@...
Subject: Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

 

Agree: ResourceShape and the list. But this is not nearly enough for a link profile.

 

For our link profile I would suggest two sections:

 

  1. non-GC aware: In this case we store triples on both sides (with its inverse property), according to the domains in the table
  2. GC aware:  We store only one link, and the current IBM-ELM convention is that these links are always stored on the dependent side as Eran describes. Links from the others side can be queried via OSLC Query or some more general purpose index if available (e.g. LDX or MID’s gLinx, etc. ).

 

As I’ve argued before since the goal of the link profile is interoperability, and since IBM-ELM is still has the largest install base of OSLC providers, some level of the link profile must insure that interoperability with IBM-ELM works out-of-the-box. I have no love or loyalty more for IBM-ELM; I’m thinking pragmatically about the customer value of a  link profile specification with which does not insure interoperability with IBM-ELM.

 

On a related note: last week, I had an interesting conversation with a product manager from PTC/Codebeamer. He indicated intention to increase their support for OSLC. Perhaps as more tools join the party force IBM-ELM to fix the many places where it is not even OCLS 2.0 compliant (or has defects), and perhaps move in the 3.0+ world.

 

From: oslc-op@... <oslc-op@...> On Behalf Of Jim Amsden via lists.oasis-open-projects.org
Sent: Freitag, 23. September 2022 20:21
To: oslc-op@...
Subject: Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

You could just use a normative table of outgoing and incoming link types (i.e., property and inverse properties). However, it would be nice if this was machine readable, and an extension to ResourceShapes would do that.

 

We could also decide to declare property and inverse properties in the OSLC vocabularies. That wouldn’t require any extensions. Since OSLC does not rely on RDF inferencing, this shouldn’t create any problems.

 

 

 

 

 

From: <oslc-op@...> on behalf of Eran Gery <eran.gery@...>
Reply-To: "oslc-op@..." <oslc-op@...>, Eran Gery <eran.gery@...>
Date: Friday, September 23, 2022 at 10:24 AM
To: Eran Gery <eran.gery@...>, "Gentry, Edward" <e.gentry@...>
Cc: "oslc-op@..." <oslc-op@...>
Subject: [EXTERNAL] Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

Ed, Jim did not accept the text as he is not sure that the “store on outgoing side” is respected by ELM. Can you comment on that. One comment I have is that it is enough that it is the 90% case as a principle. We can document exceptions. ‍ ‍

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Ed,

 

Jim did not accept the text as he is not sure that the “store on outgoing side” is respected by ELM.

Can you comment on that.

One comment I have is that it is enough that it is the 90% case as a principle. We can document exceptions.

There are clearly exceptions in opt-out mode that there are still backlinks with CCM. We can document that as an exception.

Jim suggested that we may have to use OSLC shapes to determine the owner, IMO it is a no go for the reason that the maturity level of the bi-diretional profile is far from mandating OSLC shapes. Actually, none of the linking profile require support for shapes.

So the only options I see

  1. Specify “owned by outgoing end” is a rule with some exceptions related to ELM.
  2. Have a detailed per link type (predicate) specification based on all existing OSLC domain links.
  3. A combination of both.

 

Please speak up…

 

Eran

 

From: oslc-op@... <oslc-op@...> On Behalf Of "Eran Gery"
Sent: Thursday, 22 September 2022 15:59
To: Gentry, Edward <e.gentry@...>
Cc: oslc-op@...
Subject: [EXTERNAL] Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

Ed Please review the link ownership text Link ownership In bi-derctional linking scenarios both OSLC participants are aware of links across their owned resources and enable link visibility and navigation at each side. Nevertheless ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Ed

 

Please review the link ownership text

 

Link ownership

 

In bi-derctional linking scenarios both OSLC participants are aware of links across their owned resources and enable link visibility and navigation at each side. Nevertheless, storing a link at both sides is considered an ill-practice as it is essentially replication of data. This may result in inconsistencies as links are updated or deleted, since maintaining consistency requires synchronization across the providers on any update. Therefore, the recommended practice is to store links on one of the participants, and use link discovery by the other participant. Therefore, there needs to be an agreed convention on which side should store the link. OSLC links have an incoming and outgoing sides, determined by the role of the link. Usually one side will have an active predicate name, for example "implements" and the other side will have a passive predicate name, in this example it would be "implemented by". The active side is also considered the outgoing side, and the passive the incoming side. The convention is that the link is stored with the resource on the outgoing side, i.e. the resource with the active predicate. The incoming side would discover the links with one of the discovery methods discussed in the following sections. Note the creation of the link may be initiated by both providers. In case that the link is initiated by the incoming side provider, it needs to store it with the resource on the outgoing side provider. This is discussed in the put on resources section.

 

Thanks

eran

 

From: Gentry, Edward <e.gentry@...>
Sent: Thursday, 22 September 2022 15:16
To: oslc-op@...; james_e_gammon@...; Eran Gery <eran.gery@...>; Jim Amsden <jamsden@...>; David Honey2 <david.honey@...>
Subject: [EXTERNAL] 22.9 oslc-op Weekly Contributors Meeting

 

Hi All, I’m traveling today and so will miss our meeting this afternoon. @David Honey2, could you please arrange a meeting with John Vasta for me regarding the authentication in the link Profile? We should be able to keep it to 30 minutes. 

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Hi All,

 

I’m traveling today and so will miss our meeting this afternoon.

 

@David Honey2, could you please arrange a meeting with John Vasta for me regarding the authentication in the link Profile? We should be able to keep it to 30 minutes. Find something that works for him in the morning and I’ll make it work.

 

Cheers,

 

Ed


Jad El-Khoury
 

Hi

 

I’m going back to an earlier point in the thread to be more specific in my comment (and to not confuse the new direction of the thread).

 

Given that the relationship is an RDF statement, is it even reasonable to store information about the link – but on “outgoing side” (in RDF, I assume this means the Subject).

While we can’t stop it, I struggling to understand how the server of the Object can save such a statement. (unless of course, one opts for bi-directional links. But in that case, we will have to use a new opposite relationship where the Object becomes the Subject of that relationship).

 

regards

______________________________

Jad El-khoury, PhD

KTH Royal Institute of Technology

School of Industrial Engineering and Management, Mechatronics Division

Brinellvägen 83, SE-100 44 Stockholm, Sweden

Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45

jad@..., www.kth.se

 

From: oslc-op@... <oslc-op@...> On Behalf Of Jim Amsden
Sent: Friday, 23 September 2022 20:21
To: oslc-op@...
Subject: Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

You could just use a normative table of outgoing and incoming link types (i.e., property and inverse properties). However, it would be nice if this was machine readable, and an extension to ResourceShapes would do that.

 

We could also decide to declare property and inverse properties in the OSLC vocabularies. That wouldn’t require any extensions. Since OSLC does not rely on RDF inferencing, this shouldn’t create any problems.

 

 

 

 

 

From: <oslc-op@...> on behalf of Eran Gery <eran.gery@...>
Reply-To: "oslc-op@..." <oslc-op@...>, Eran Gery <eran.gery@...>
Date: Friday, September 23, 2022 at 10:24 AM
To: Eran Gery <eran.gery@...>, "Gentry, Edward" <e.gentry@...>
Cc: "oslc-op@..." <oslc-op@...>
Subject: [EXTERNAL] Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

Ed, Jim did not accept the text as he is not sure that the “store on outgoing side” is respected by ELM. Can you comment on that. One comment I have is that it is enough that it is the 90% case as a principle. We can document exceptions. ‍ ‍

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Ed,

 

Jim did not accept the text as he is not sure that the “store on outgoing side” is respected by ELM.

Can you comment on that.

One comment I have is that it is enough that it is the 90% case as a principle. We can document exceptions.

There are clearly exceptions in opt-out mode that there are still backlinks with CCM. We can document that as an exception.

Jim suggested that we may have to use OSLC shapes to determine the owner, IMO it is a no go for the reason that the maturity level of the bi-diretional profile is far from mandating OSLC shapes. Actually, none of the linking profile require support for shapes.

So the only options I see

  1. Specify “owned by outgoing end” is a rule with some exceptions related to ELM.
  2. Have a detailed per link type (predicate) specification based on all existing OSLC domain links.
  3. A combination of both.

 

Please speak up…

 

Eran

 

From: oslc-op@... <oslc-op@...> On Behalf Of "Eran Gery"
Sent: Thursday, 22 September 2022 15:59
To: Gentry, Edward <e.gentry@...>
Cc: oslc-op@...
Subject: [EXTERNAL] Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

Ed Please review the link ownership text Link ownership In bi-derctional linking scenarios both OSLC participants are aware of links across their owned resources and enable link visibility and navigation at each side. Nevertheless ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Ed

 

Please review the link ownership text

 

Link ownership

 

In bi-derctional linking scenarios both OSLC participants are aware of links across their owned resources and enable link visibility and navigation at each side. Nevertheless, storing a link at both sides is considered an ill-practice as it is essentially replication of data. This may result in inconsistencies as links are updated or deleted, since maintaining consistency requires synchronization across the providers on any update. Therefore, the recommended practice is to store links on one of the participants, and use link discovery by the other participant. Therefore, there needs to be an agreed convention on which side should store the link. OSLC links have an incoming and outgoing sides, determined by the role of the link. Usually one side will have an active predicate name, for example "implements" and the other side will have a passive predicate name, in this example it would be "implemented by". The active side is also considered the outgoing side, and the passive the incoming side. The convention is that the link is stored with the resource on the outgoing side, i.e. the resource with the active predicate. The incoming side would discover the links with one of the discovery methods discussed in the following sections. Note the creation of the link may be initiated by both providers. In case that the link is initiated by the incoming side provider, it needs to store it with the resource on the outgoing side provider. This is discussed in the put on resources section.

 

Thanks

eran

 

From: Gentry, Edward <e.gentry@...>
Sent: Thursday, 22 September 2022 15:16
To: oslc-op@...; james_e_gammon@...; Eran Gery <eran.gery@...>; Jim Amsden <jamsden@...>; David Honey2 <david.honey@...>
Subject: [EXTERNAL] 22.9 oslc-op Weekly Contributors Meeting

 

Hi All, I’m traveling today and so will miss our meeting this afternoon. @David Honey2, could you please arrange a meeting with John Vasta for me regarding the authentication in the link Profile? We should be able to keep it to 30 minutes. 

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Hi All,

 

I’m traveling today and so will miss our meeting this afternoon.

 

@David Honey2, could you please arrange a meeting with John Vasta for me regarding the authentication in the link Profile? We should be able to keep it to 30 minutes. Find something that works for him in the morning and I’ll make it work.

 

Cheers,

 

Ed


David Honey2
 

ELM already uses a http://jazz.net/ns/jrs#inversePropertyDefinition in resource shapes to tie together forward and backward links. Report Builder uses that to query for the union of the forward and backward link. However, that doesn’t provide any indication of which end should be considered the primary vs secondary persistence.

 

Best regards,

David

 

From: oslc-op@... <oslc-op@...> On Behalf Of Jad El-Khoury
Sent: 29 September 2022 09:44
To: oslc-op@...; Jim Amsden <jamsden@...>
Subject: [EXTERNAL] Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

Hi I’m going back to an earlier point in the thread to be more specific in my comment (and to not confuse the new direction of the thread). Given that the relationship is an RDF statement, is it even reasonable to store information about the

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Hi

 

I’m going back to an earlier point in the thread to be more specific in my comment (and to not confuse the new direction of the thread).

 

Given that the relationship is an RDF statement, is it even reasonable to store information about the link – but on “outgoing side” (in RDF, I assume this means the Subject).

While we can’t stop it, I struggling to understand how the server of the Object can save such a statement. (unless of course, one opts for bi-directional links. But in that case, we will have to use a new opposite relationship where the Object becomes the Subject of that relationship).

 

regards

______________________________

Jad El-khoury, PhD

KTH Royal Institute of Technology

School of Industrial Engineering and Management, Mechatronics Division

Brinellvägen 83, SE-100 44 Stockholm, Sweden

Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45

jad@..., www.kth.se

 

From: oslc-op@... <oslc-op@...> On Behalf Of Jim Amsden
Sent: Friday, 23 September 2022 20:21
To: oslc-op@...
Subject: Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

You could just use a normative table of outgoing and incoming link types (i.e., property and inverse properties). However, it would be nice if this was machine readable, and an extension to ResourceShapes would do that.

 

We could also decide to declare property and inverse properties in the OSLC vocabularies. That wouldn’t require any extensions. Since OSLC does not rely on RDF inferencing, this shouldn’t create any problems.

 

 

 

 

 

From: <oslc-op@...> on behalf of Eran Gery <eran.gery@...>
Reply-To: "oslc-op@..." <oslc-op@...>, Eran Gery <eran.gery@...>
Date: Friday, September 23, 2022 at 10:24 AM
To: Eran Gery <eran.gery@...>, "Gentry, Edward" <e.gentry@...>
Cc: "oslc-op@..." <oslc-op@...>
Subject: [EXTERNAL] Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

Ed, Jim did not accept the text as he is not sure that the “store on outgoing side” is respected by ELM. Can you comment on that. One comment I have is that it is enough that it is the 90% case as a principle. We can document exceptions. ‍ ‍

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Ed,

 

Jim did not accept the text as he is not sure that the “store on outgoing side” is respected by ELM.

Can you comment on that.

One comment I have is that it is enough that it is the 90% case as a principle. We can document exceptions.

There are clearly exceptions in opt-out mode that there are still backlinks with CCM. We can document that as an exception.

Jim suggested that we may have to use OSLC shapes to determine the owner, IMO it is a no go for the reason that the maturity level of the bi-diretional profile is far from mandating OSLC shapes. Actually, none of the linking profile require support for shapes.

So the only options I see

  1. Specify “owned by outgoing end” is a rule with some exceptions related to ELM.
  2. Have a detailed per link type (predicate) specification based on all existing OSLC domain links.
  3. A combination of both.

 

Please speak up…

 

Eran

 

From: oslc-op@... <oslc-op@...> On Behalf Of "Eran Gery"
Sent: Thursday, 22 September 2022 15:59
To: Gentry, Edward <e.gentry@...>
Cc: oslc-op@...
Subject: [EXTERNAL] Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

Ed Please review the link ownership text Link ownership In bi-derctional linking scenarios both OSLC participants are aware of links across their owned resources and enable link visibility and navigation at each side. Nevertheless ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Ed

 

Please review the link ownership text

 

Link ownership

 

In bi-derctional linking scenarios both OSLC participants are aware of links across their owned resources and enable link visibility and navigation at each side. Nevertheless, storing a link at both sides is considered an ill-practice as it is essentially replication of data. This may result in inconsistencies as links are updated or deleted, since maintaining consistency requires synchronization across the providers on any update. Therefore, the recommended practice is to store links on one of the participants, and use link discovery by the other participant. Therefore, there needs to be an agreed convention on which side should store the link. OSLC links have an incoming and outgoing sides, determined by the role of the link. Usually one side will have an active predicate name, for example "implements" and the other side will have a passive predicate name, in this example it would be "implemented by". The active side is also considered the outgoing side, and the passive the incoming side. The convention is that the link is stored with the resource on the outgoing side, i.e. the resource with the active predicate. The incoming side would discover the links with one of the discovery methods discussed in the following sections. Note the creation of the link may be initiated by both providers. In case that the link is initiated by the incoming side provider, it needs to store it with the resource on the outgoing side provider. This is discussed in the put on resources section.

 

Thanks

eran

 

From: Gentry, Edward <e.gentry@...>
Sent: Thursday, 22 September 2022 15:16
To: oslc-op@...; james_e_gammon@...; Eran Gery <eran.gery@...>; Jim Amsden <jamsden@...>; David Honey2 <david.honey@...>
Subject: [EXTERNAL] 22.9 oslc-op Weekly Contributors Meeting

 

Hi All, I’m traveling today and so will miss our meeting this afternoon. @David Honey2, could you please arrange a meeting with John Vasta for me regarding the authentication in the link Profile? We should be able to keep it to 30 minutes. 

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Hi All,

 

I’m traveling today and so will miss our meeting this afternoon.

 

@David Honey2, could you please arrange a meeting with John Vasta for me regarding the authentication in the link Profile? We should be able to keep it to 30 minutes. Find something that works for him in the morning and I’ll make it work.

 

Cheers,

 

Ed

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


Jad El-Khoury
 

Now you’ve introduced a new discussion: primary vs secondary persistence”.

 

Putting that aside, and focusing on one-directional links to start with, what’s the problem with suggesting that links are stored on the “outgoing side” (in RDF terms, the Subject)?

 

Even for bi-directional links, this statement can hold - in each direction, given that we will use 2 different properties for each direction.

 

______________________________

Jad El-khoury, PhD

KTH Royal Institute of Technology

School of Industrial Engineering and Management, Mechatronics Division

Brinellvägen 83, SE-100 44 Stockholm, Sweden

Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45

jad@..., www.kth.se

 

From: David Honey2 <david.honey@...>
Sent: Thursday, 29 September 2022 11:04
To: oslc-op@...; Jad El-Khoury <jad@...>; Jim Amsden <jamsden@...>
Subject: RE: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

ELM already uses a http://jazz.net/ns/jrs#inversePropertyDefinition in resource shapes to tie together forward and backward links. Report Builder uses that to query for the union of the forward and backward link. However, that doesn’t provide any indication of which end should be considered the primary vs secondary persistence.

 

Best regards,

David

 

From: oslc-op@... <oslc-op@...> On Behalf Of Jad El-Khoury
Sent: 29 September 2022 09:44
To: oslc-op@...; Jim Amsden <jamsden@...>
Subject: [EXTERNAL] Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

Hi I’m going back to an earlier point in the thread to be more specific in my comment (and to not confuse the new direction of the thread). Given that the relationship is an RDF statement, is it even reasonable to store information about the

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Hi

 

I’m going back to an earlier point in the thread to be more specific in my comment (and to not confuse the new direction of the thread).

 

Given that the relationship is an RDF statement, is it even reasonable to store information about the link – but on “outgoing side” (in RDF, I assume this means the Subject).

While we can’t stop it, I struggling to understand how the server of the Object can save such a statement. (unless of course, one opts for bi-directional links. But in that case, we will have to use a new opposite relationship where the Object becomes the Subject of that relationship).

 

regards

______________________________

Jad El-khoury, PhD

KTH Royal Institute of Technology

School of Industrial Engineering and Management, Mechatronics Division

Brinellvägen 83, SE-100 44 Stockholm, Sweden

Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45

jad@..., www.kth.se

 

From: oslc-op@... <oslc-op@...> On Behalf Of Jim Amsden
Sent: Friday, 23 September 2022 20:21
To: oslc-op@...
Subject: Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

You could just use a normative table of outgoing and incoming link types (i.e., property and inverse properties). However, it would be nice if this was machine readable, and an extension to ResourceShapes would do that.

 

We could also decide to declare property and inverse properties in the OSLC vocabularies. That wouldn’t require any extensions. Since OSLC does not rely on RDF inferencing, this shouldn’t create any problems.

 

 

 

 

 

From: <oslc-op@...> on behalf of Eran Gery <eran.gery@...>
Reply-To: "oslc-op@..." <oslc-op@...>, Eran Gery <eran.gery@...>
Date: Friday, September 23, 2022 at 10:24 AM
To: Eran Gery <eran.gery@...>, "Gentry, Edward" <e.gentry@...>
Cc: "oslc-op@..." <oslc-op@...>
Subject: [EXTERNAL] Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

Ed, Jim did not accept the text as he is not sure that the “store on outgoing side” is respected by ELM. Can you comment on that. One comment I have is that it is enough that it is the 90% case as a principle. We can document exceptions. ‍ ‍

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Ed,

 

Jim did not accept the text as he is not sure that the “store on outgoing side” is respected by ELM.

Can you comment on that.

One comment I have is that it is enough that it is the 90% case as a principle. We can document exceptions.

There are clearly exceptions in opt-out mode that there are still backlinks with CCM. We can document that as an exception.

Jim suggested that we may have to use OSLC shapes to determine the owner, IMO it is a no go for the reason that the maturity level of the bi-diretional profile is far from mandating OSLC shapes. Actually, none of the linking profile require support for shapes.

So the only options I see

  1. Specify “owned by outgoing end” is a rule with some exceptions related to ELM.
  2. Have a detailed per link type (predicate) specification based on all existing OSLC domain links.
  3. A combination of both.

 

Please speak up…

 

Eran

 

From: oslc-op@... <oslc-op@...> On Behalf Of "Eran Gery"
Sent: Thursday, 22 September 2022 15:59
To: Gentry, Edward <e.gentry@...>
Cc: oslc-op@...
Subject: [EXTERNAL] Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

Ed Please review the link ownership text Link ownership In bi-derctional linking scenarios both OSLC participants are aware of links across their owned resources and enable link visibility and navigation at each side. Nevertheless ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Ed

 

Please review the link ownership text

 

Link ownership

 

In bi-derctional linking scenarios both OSLC participants are aware of links across their owned resources and enable link visibility and navigation at each side. Nevertheless, storing a link at both sides is considered an ill-practice as it is essentially replication of data. This may result in inconsistencies as links are updated or deleted, since maintaining consistency requires synchronization across the providers on any update. Therefore, the recommended practice is to store links on one of the participants, and use link discovery by the other participant. Therefore, there needs to be an agreed convention on which side should store the link. OSLC links have an incoming and outgoing sides, determined by the role of the link. Usually one side will have an active predicate name, for example "implements" and the other side will have a passive predicate name, in this example it would be "implemented by". The active side is also considered the outgoing side, and the passive the incoming side. The convention is that the link is stored with the resource on the outgoing side, i.e. the resource with the active predicate. The incoming side would discover the links with one of the discovery methods discussed in the following sections. Note the creation of the link may be initiated by both providers. In case that the link is initiated by the incoming side provider, it needs to store it with the resource on the outgoing side provider. This is discussed in the put on resources section.

 

Thanks

eran

 

From: Gentry, Edward <e.gentry@...>
Sent: Thursday, 22 September 2022 15:16
To: oslc-op@...; james_e_gammon@...; Eran Gery <eran.gery@...>; Jim Amsden <jamsden@...>; David Honey2 <david.honey@...>
Subject: [EXTERNAL] 22.9 oslc-op Weekly Contributors Meeting

 

Hi All, I’m traveling today and so will miss our meeting this afternoon. @David Honey2, could you please arrange a meeting with John Vasta for me regarding the authentication in the link Profile? We should be able to keep it to 30 minutes. 

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Hi All,

 

I’m traveling today and so will miss our meeting this afternoon.

 

@David Honey2, could you please arrange a meeting with John Vasta for me regarding the authentication in the link Profile? We should be able to keep it to 30 minutes. Find something that works for him in the morning and I’ll make it work.

 

Cheers,

 

Ed

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
 

There seems to be general agreement we can store a “link” on either side given that the “link” has two predicates (one for the subject and then an inverse-link). Also there seems to be some agreement that the inverse-link information would be listed in ResourceShapes, so that a tool might even know what links to query for.

 

The only point is that IBM-ELM doesn’t currently do it this way. In OPT-IN mode links are stored only on the dependent side. In OPT-OUT they are usually (but not always) stored on both side with the inverseLink.

 

Link profile work is trying to be inclusive, to define what is required to get as much as possible to integrate with as little effort as required (therefore I softened my position on oauth1.0a)

 

 

 

 

 

From: oslc-op@... <oslc-op@...> On Behalf Of Jad El-Khoury via lists.oasis-open-projects.org
Sent: Donnerstag, 29. September 2022 11:27
To: David Honey2 <david.honey@...>; oslc-op@...; Jim Amsden <jamsden@...>
Subject: Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

Now you’ve introduced a new discussion: “primary vs secondary persistence”.

 

Putting that aside, and focusing on one-directional links to start with, what’s the problem with suggesting that links are stored on the “outgoing side” (in RDF terms, the Subject)?

 

Even for bi-directional links, this statement can hold - in each direction, given that we will use 2 different properties for each direction.

 

______________________________

Jad El-khoury, PhD

KTH Royal Institute of Technology

School of Industrial Engineering and Management, Mechatronics Division

Brinellvägen 83, SE-100 44 Stockholm, Sweden

Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45

jad@..., www.kth.se

 

From: David Honey2 <david.honey@...>
Sent: Thursday, 29 September 2022 11:04
To: oslc-op@...; Jad El-Khoury <jad@...>; Jim Amsden <jamsden@...>
Subject: RE: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

ELM already uses a http://jazz.net/ns/jrs#inversePropertyDefinition in resource shapes to tie together forward and backward links. Report Builder uses that to query for the union of the forward and backward link. However, that doesn’t provide any indication of which end should be considered the primary vs secondary persistence.

 

Best regards,

David

 

From: oslc-op@... <oslc-op@...> On Behalf Of Jad El-Khoury
Sent: 29 September 2022 09:44
To: oslc-op@...; Jim Amsden <jamsden@...>
Subject: [EXTERNAL] Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

Hi I’m going back to an earlier point in the thread to be more specific in my comment (and to not confuse the new direction of the thread). Given that the relationship is an RDF statement, is it even reasonable to store information about the

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Hi

 

I’m going back to an earlier point in the thread to be more specific in my comment (and to not confuse the new direction of the thread).

 

Given that the relationship is an RDF statement, is it even reasonable to store information about the link – but on “outgoing side” (in RDF, I assume this means the Subject).

While we can’t stop it, I struggling to understand how the server of the Object can save such a statement. (unless of course, one opts for bi-directional links. But in that case, we will have to use a new opposite relationship where the Object becomes the Subject of that relationship).

 

regards

______________________________

Jad El-khoury, PhD

KTH Royal Institute of Technology

School of Industrial Engineering and Management, Mechatronics Division

Brinellvägen 83, SE-100 44 Stockholm, Sweden

Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45

jad@..., www.kth.se

 

From: oslc-op@... <oslc-op@...> On Behalf Of Jim Amsden
Sent: Friday, 23 September 2022 20:21
To: oslc-op@...
Subject: Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

You could just use a normative table of outgoing and incoming link types (i.e., property and inverse properties). However, it would be nice if this was machine readable, and an extension to ResourceShapes would do that.

 

We could also decide to declare property and inverse properties in the OSLC vocabularies. That wouldn’t require any extensions. Since OSLC does not rely on RDF inferencing, this shouldn’t create any problems.

 

 

 

 

 

From: <oslc-op@...> on behalf of Eran Gery <eran.gery@...>
Reply-To: "oslc-op@..." <oslc-op@...>, Eran Gery <eran.gery@...>
Date: Friday, September 23, 2022 at 10:24 AM
To: Eran Gery <eran.gery@...>, "Gentry, Edward" <e.gentry@...>
Cc: "oslc-op@..." <oslc-op@...>
Subject: [EXTERNAL] Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

Ed, Jim did not accept the text as he is not sure that the “store on outgoing side” is respected by ELM. Can you comment on that. One comment I have is that it is enough that it is the 90% case as a principle. We can document exceptions. ‍ ‍

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Ed,

 

Jim did not accept the text as he is not sure that the “store on outgoing side” is respected by ELM.

Can you comment on that.

One comment I have is that it is enough that it is the 90% case as a principle. We can document exceptions.

There are clearly exceptions in opt-out mode that there are still backlinks with CCM. We can document that as an exception.

Jim suggested that we may have to use OSLC shapes to determine the owner, IMO it is a no go for the reason that the maturity level of the bi-diretional profile is far from mandating OSLC shapes. Actually, none of the linking profile require support for shapes.

So the only options I see

  1. Specify “owned by outgoing end” is a rule with some exceptions related to ELM.
  2. Have a detailed per link type (predicate) specification based on all existing OSLC domain links.
  3. A combination of both.

 

Please speak up…

 

Eran

 

From: oslc-op@... <oslc-op@...> On Behalf Of "Eran Gery"
Sent: Thursday, 22 September 2022 15:59
To: Gentry, Edward <e.gentry@...>
Cc: oslc-op@...
Subject: [EXTERNAL] Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

Ed Please review the link ownership text Link ownership In bi-derctional linking scenarios both OSLC participants are aware of links across their owned resources and enable link visibility and navigation at each side. Nevertheless ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Ed

 

Please review the link ownership text

 

Link ownership

 

In bi-derctional linking scenarios both OSLC participants are aware of links across their owned resources and enable link visibility and navigation at each side. Nevertheless, storing a link at both sides is considered an ill-practice as it is essentially replication of data. This may result in inconsistencies as links are updated or deleted, since maintaining consistency requires synchronization across the providers on any update. Therefore, the recommended practice is to store links on one of the participants, and use link discovery by the other participant. Therefore, there needs to be an agreed convention on which side should store the link. OSLC links have an incoming and outgoing sides, determined by the role of the link. Usually one side will have an active predicate name, for example "implements" and the other side will have a passive predicate name, in this example it would be "implemented by". The active side is also considered the outgoing side, and the passive the incoming side. The convention is that the link is stored with the resource on the outgoing side, i.e. the resource with the active predicate. The incoming side would discover the links with one of the discovery methods discussed in the following sections. Note the creation of the link may be initiated by both providers. In case that the link is initiated by the incoming side provider, it needs to store it with the resource on the outgoing side provider. This is discussed in the put on resources section.

 

Thanks

eran

 

From: Gentry, Edward <e.gentry@...>
Sent: Thursday, 22 September 2022 15:16
To: oslc-op@...; james_e_gammon@...; Eran Gery <eran.gery@...>; Jim Amsden <jamsden@...>; David Honey2 <david.honey@...>
Subject: [EXTERNAL] 22.9 oslc-op Weekly Contributors Meeting

 

Hi All, I’m traveling today and so will miss our meeting this afternoon. @David Honey2, could you please arrange a meeting with John Vasta for me regarding the authentication in the link Profile? We should be able to keep it to 30 minutes. 

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Hi All,

 

I’m traveling today and so will miss our meeting this afternoon.

 

@David Honey2, could you please arrange a meeting with John Vasta for me regarding the authentication in the link Profile? We should be able to keep it to 30 minutes. Find something that works for him in the morning and I’ll make it work.

 

Cheers,

 

Ed

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
 

It’s not a new topic. The issue being discussed is knowing which side of the link should store the link. Knowing, for example, that validatesRequirement stored on a test case has an inverse validatedBy that might be stored on a requirement tells you nothing about which is the forward link or whether the data should be stored on the test case or the requirement.

 

From: Jad El-Khoury <jad@...>
Sent: 29 September 2022 10:27
To: David Honey2 <david.honey@...>; oslc-op@...; Jim Amsden <jamsden@...>
Subject: [EXTERNAL] RE: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

Now you’ve introduced a new discussion: “primary vs secondary persistence”. Putting that aside, and focusing on one-directional links to start with, what’s the problem with suggesting that links are stored on the ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Now you’ve introduced a new discussion: “primary vs secondary persistence”.

 

Putting that aside, and focusing on one-directional links to start with, what’s the problem with suggesting that links are stored on the “outgoing side” (in RDF terms, the Subject)?

 

Even for bi-directional links, this statement can hold - in each direction, given that we will use 2 different properties for each direction.

 

______________________________

Jad El-khoury, PhD

KTH Royal Institute of Technology

School of Industrial Engineering and Management, Mechatronics Division

Brinellvägen 83, SE-100 44 Stockholm, Sweden

Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45

jad@..., www.kth.se

 

From: David Honey2 <david.honey@...>
Sent: Thursday, 29 September 2022 11:04
To: oslc-op@...; Jad El-Khoury <jad@...>; Jim Amsden <jamsden@...>
Subject: RE: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

ELM already uses a http://jazz.net/ns/jrs#inversePropertyDefinition in resource shapes to tie together forward and backward links. Report Builder uses that to query for the union of the forward and backward link. However, that doesn’t provide any indication of which end should be considered the primary vs secondary persistence.

 

Best regards,

David

 

From: oslc-op@... <oslc-op@...> On Behalf Of Jad El-Khoury
Sent: 29 September 2022 09:44
To: oslc-op@...; Jim Amsden <jamsden@...>
Subject: [EXTERNAL] Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

Hi I’m going back to an earlier point in the thread to be more specific in my comment (and to not confuse the new direction of the thread). Given that the relationship is an RDF statement, is it even reasonable to store information about the

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Hi

 

I’m going back to an earlier point in the thread to be more specific in my comment (and to not confuse the new direction of the thread).

 

Given that the relationship is an RDF statement, is it even reasonable to store information about the link – but on “outgoing side” (in RDF, I assume this means the Subject).

While we can’t stop it, I struggling to understand how the server of the Object can save such a statement. (unless of course, one opts for bi-directional links. But in that case, we will have to use a new opposite relationship where the Object becomes the Subject of that relationship).

 

regards

______________________________

Jad El-khoury, PhD

KTH Royal Institute of Technology

School of Industrial Engineering and Management, Mechatronics Division

Brinellvägen 83, SE-100 44 Stockholm, Sweden

Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45

jad@..., www.kth.se

 

From: oslc-op@... <oslc-op@...> On Behalf Of Jim Amsden
Sent: Friday, 23 September 2022 20:21
To: oslc-op@...
Subject: Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

You could just use a normative table of outgoing and incoming link types (i.e., property and inverse properties). However, it would be nice if this was machine readable, and an extension to ResourceShapes would do that.

 

We could also decide to declare property and inverse properties in the OSLC vocabularies. That wouldn’t require any extensions. Since OSLC does not rely on RDF inferencing, this shouldn’t create any problems.

 

 

 

 

 

From: <oslc-op@...> on behalf of Eran Gery <eran.gery@...>
Reply-To: "oslc-op@..." <oslc-op@...>, Eran Gery <eran.gery@...>
Date: Friday, September 23, 2022 at 10:24 AM
To: Eran Gery <eran.gery@...>, "Gentry, Edward" <e.gentry@...>
Cc: "oslc-op@..." <oslc-op@...>
Subject: [EXTERNAL] Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

Ed, Jim did not accept the text as he is not sure that the “store on outgoing side” is respected by ELM. Can you comment on that. One comment I have is that it is enough that it is the 90% case as a principle. We can document exceptions. ‍ ‍

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Ed,

 

Jim did not accept the text as he is not sure that the “store on outgoing side” is respected by ELM.

Can you comment on that.

One comment I have is that it is enough that it is the 90% case as a principle. We can document exceptions.

There are clearly exceptions in opt-out mode that there are still backlinks with CCM. We can document that as an exception.

Jim suggested that we may have to use OSLC shapes to determine the owner, IMO it is a no go for the reason that the maturity level of the bi-diretional profile is far from mandating OSLC shapes. Actually, none of the linking profile require support for shapes.

So the only options I see

  1. Specify “owned by outgoing end” is a rule with some exceptions related to ELM.
  2. Have a detailed per link type (predicate) specification based on all existing OSLC domain links.
  3. A combination of both.

 

Please speak up…

 

Eran

 

From: oslc-op@... <oslc-op@...> On Behalf Of "Eran Gery"
Sent: Thursday, 22 September 2022 15:59
To: Gentry, Edward <e.gentry@...>
Cc: oslc-op@...
Subject: [EXTERNAL] Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

Ed Please review the link ownership text Link ownership In bi-derctional linking scenarios both OSLC participants are aware of links across their owned resources and enable link visibility and navigation at each side. Nevertheless ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Ed

 

Please review the link ownership text

 

Link ownership

 

In bi-derctional linking scenarios both OSLC participants are aware of links across their owned resources and enable link visibility and navigation at each side. Nevertheless, storing a link at both sides is considered an ill-practice as it is essentially replication of data. This may result in inconsistencies as links are updated or deleted, since maintaining consistency requires synchronization across the providers on any update. Therefore, the recommended practice is to store links on one of the participants, and use link discovery by the other participant. Therefore, there needs to be an agreed convention on which side should store the link. OSLC links have an incoming and outgoing sides, determined by the role of the link. Usually one side will have an active predicate name, for example "implements" and the other side will have a passive predicate name, in this example it would be "implemented by". The active side is also considered the outgoing side, and the passive the incoming side. The convention is that the link is stored with the resource on the outgoing side, i.e. the resource with the active predicate. The incoming side would discover the links with one of the discovery methods discussed in the following sections. Note the creation of the link may be initiated by both providers. In case that the link is initiated by the incoming side provider, it needs to store it with the resource on the outgoing side provider. This is discussed in the put on resources section.

 

Thanks

eran

 

From: Gentry, Edward <e.gentry@...>
Sent: Thursday, 22 September 2022 15:16
To: oslc-op@...; james_e_gammon@...; Eran Gery <eran.gery@...>; Jim Amsden <jamsden@...>; David Honey2 <david.honey@...>
Subject: [EXTERNAL] 22.9 oslc-op Weekly Contributors Meeting

 

Hi All, I’m traveling today and so will miss our meeting this afternoon. @David Honey2, could you please arrange a meeting with John Vasta for me regarding the authentication in the link Profile? We should be able to keep it to 30 minutes. 

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Hi All,

 

I’m traveling today and so will miss our meeting this afternoon.

 

@David Honey2, could you please arrange a meeting with John Vasta for me regarding the authentication in the link Profile? We should be able to keep it to 30 minutes. Find something that works for him in the morning and I’ll make it work.

 

Cheers,

 

Ed

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
 

David,

 

I don’t understand “tells you nothing about which is the forward link or whether the data should be stored on the test case or the requirement.”

 

What do you mean by “forward link”, and yes I think we do know where we store links when have inverse-links e.g. validatesRequirement is stored on the test case, and validatedBy on the Requirement. You said this yourself.  

 

From: oslc-op@... <oslc-op@...> On Behalf Of David Honey2 via lists.oasis-open-projects.org
Sent: Donnerstag, 29. September 2022 11:36
To: Jad El-Khoury <jad@...>; oslc-op@...; Jim Amsden <jamsden@...>
Subject: Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

It’s not a new topic. The issue being discussed is knowing which side of the link should store the link. Knowing, for example, that validatesRequirement stored on a test case has an inverse validatedBy that might be stored on a requirement tells you nothing about which is the forward link or whether the data should be stored on the test case or the requirement.

 

From: Jad El-Khoury <jad@...>
Sent: 29 September 2022 10:27
To: David Honey2 <david.honey@...>; oslc-op@...; Jim Amsden <jamsden@...>
Subject: [EXTERNAL] RE: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

Now you’ve introduced a new discussion: “primary vs secondary persistence”. Putting that aside, and focusing on one-directional links to start with, what’s the problem with suggesting that links are stored on the ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Now you’ve introduced a new discussion: “primary vs secondary persistence”.

 

Putting that aside, and focusing on one-directional links to start with, what’s the problem with suggesting that links are stored on the “outgoing side” (in RDF terms, the Subject)?

 

Even for bi-directional links, this statement can hold - in each direction, given that we will use 2 different properties for each direction.

 

______________________________

Jad El-khoury, PhD

KTH Royal Institute of Technology

School of Industrial Engineering and Management, Mechatronics Division

Brinellvägen 83, SE-100 44 Stockholm, Sweden

Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45

jad@..., www.kth.se

 

From: David Honey2 <david.honey@...>
Sent: Thursday, 29 September 2022 11:04
To: oslc-op@...; Jad El-Khoury <jad@...>; Jim Amsden <jamsden@...>
Subject: RE: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

ELM already uses a http://jazz.net/ns/jrs#inversePropertyDefinition in resource shapes to tie together forward and backward links. Report Builder uses that to query for the union of the forward and backward link. However, that doesn’t provide any indication of which end should be considered the primary vs secondary persistence.

 

Best regards,

David

 

From: oslc-op@... <oslc-op@...> On Behalf Of Jad El-Khoury
Sent: 29 September 2022 09:44
To: oslc-op@...; Jim Amsden <jamsden@...>
Subject: [EXTERNAL] Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

Hi I’m going back to an earlier point in the thread to be more specific in my comment (and to not confuse the new direction of the thread). Given that the relationship is an RDF statement, is it even reasonable to store information about the

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Hi

 

I’m going back to an earlier point in the thread to be more specific in my comment (and to not confuse the new direction of the thread).

 

Given that the relationship is an RDF statement, is it even reasonable to store information about the link – but on “outgoing side” (in RDF, I assume this means the Subject).

While we can’t stop it, I struggling to understand how the server of the Object can save such a statement. (unless of course, one opts for bi-directional links. But in that case, we will have to use a new opposite relationship where the Object becomes the Subject of that relationship).

 

regards

______________________________

Jad El-khoury, PhD

KTH Royal Institute of Technology

School of Industrial Engineering and Management, Mechatronics Division

Brinellvägen 83, SE-100 44 Stockholm, Sweden

Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45

jad@..., www.kth.se

 

From: oslc-op@... <oslc-op@...> On Behalf Of Jim Amsden
Sent: Friday, 23 September 2022 20:21
To: oslc-op@...
Subject: Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

You could just use a normative table of outgoing and incoming link types (i.e., property and inverse properties). However, it would be nice if this was machine readable, and an extension to ResourceShapes would do that.

 

We could also decide to declare property and inverse properties in the OSLC vocabularies. That wouldn’t require any extensions. Since OSLC does not rely on RDF inferencing, this shouldn’t create any problems.

 

 

 

 

 

From: <oslc-op@...> on behalf of Eran Gery <eran.gery@...>
Reply-To: "oslc-op@..." <oslc-op@...>, Eran Gery <eran.gery@...>
Date: Friday, September 23, 2022 at 10:24 AM
To: Eran Gery <eran.gery@...>, "Gentry, Edward" <e.gentry@...>
Cc: "oslc-op@..." <oslc-op@...>
Subject: [EXTERNAL] Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

Ed, Jim did not accept the text as he is not sure that the “store on outgoing side” is respected by ELM. Can you comment on that. One comment I have is that it is enough that it is the 90% case as a principle. We can document exceptions. ‍ ‍

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Ed,

 

Jim did not accept the text as he is not sure that the “store on outgoing side” is respected by ELM.

Can you comment on that.

One comment I have is that it is enough that it is the 90% case as a principle. We can document exceptions.

There are clearly exceptions in opt-out mode that there are still backlinks with CCM. We can document that as an exception.

Jim suggested that we may have to use OSLC shapes to determine the owner, IMO it is a no go for the reason that the maturity level of the bi-diretional profile is far from mandating OSLC shapes. Actually, none of the linking profile require support for shapes.

So the only options I see

  1. Specify “owned by outgoing end” is a rule with some exceptions related to ELM.
  2. Have a detailed per link type (predicate) specification based on all existing OSLC domain links.
  3. A combination of both.

 

Please speak up…

 

Eran

 

From: oslc-op@... <oslc-op@...> On Behalf Of "Eran Gery"
Sent: Thursday, 22 September 2022 15:59
To: Gentry, Edward <e.gentry@...>
Cc: oslc-op@...
Subject: [EXTERNAL] Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

Ed Please review the link ownership text Link ownership In bi-derctional linking scenarios both OSLC participants are aware of links across their owned resources and enable link visibility and navigation at each side. Nevertheless ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Ed

 

Please review the link ownership text

 

Link ownership

 

In bi-derctional linking scenarios both OSLC participants are aware of links across their owned resources and enable link visibility and navigation at each side. Nevertheless, storing a link at both sides is considered an ill-practice as it is essentially replication of data. This may result in inconsistencies as links are updated or deleted, since maintaining consistency requires synchronization across the providers on any update. Therefore, the recommended practice is to store links on one of the participants, and use link discovery by the other participant. Therefore, there needs to be an agreed convention on which side should store the link. OSLC links have an incoming and outgoing sides, determined by the role of the link. Usually one side will have an active predicate name, for example "implements" and the other side will have a passive predicate name, in this example it would be "implemented by". The active side is also considered the outgoing side, and the passive the incoming side. The convention is that the link is stored with the resource on the outgoing side, i.e. the resource with the active predicate. The incoming side would discover the links with one of the discovery methods discussed in the following sections. Note the creation of the link may be initiated by both providers. In case that the link is initiated by the incoming side provider, it needs to store it with the resource on the outgoing side provider. This is discussed in the put on resources section.

 

Thanks

eran

 

From: Gentry, Edward <e.gentry@...>
Sent: Thursday, 22 September 2022 15:16
To: oslc-op@...; james_e_gammon@...; Eran Gery <eran.gery@...>; Jim Amsden <jamsden@...>; David Honey2 <david.honey@...>
Subject: [EXTERNAL] 22.9 oslc-op Weekly Contributors Meeting

 

Hi All, I’m traveling today and so will miss our meeting this afternoon. @David Honey2, could you please arrange a meeting with John Vasta for me regarding the authentication in the link Profile? We should be able to keep it to 30 minutes. 

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Hi All,

 

I’m traveling today and so will miss our meeting this afternoon.

 

@David Honey2, could you please arrange a meeting with John Vasta for me regarding the authentication in the link Profile? We should be able to keep it to 30 minutes. Find something that works for him in the morning and I’ll make it work.

 

Cheers,

 

Ed

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"
 

Guys,

 

The bi-directional profile cannot rely on resource shapes as I noted earlier.

It is the next tier after most basic. Currently no one outside ELM implements shapes.

What makes sense to me is that

  1. We explain the policy of single link as the general rule as I specified
  2. We document ELM exceptions for opt-out mode (e.g. RM<->QM, RM<->CM)

 

The goal of the profile is to be a practical survival guide in the OSLC space…

 

Regards,

Eran

 

From: oslc-op@... <oslc-op@...> On Behalf Of Gentry, Edward
Sent: Thursday, 29 September 2022 12:35
To: oslc-op@...; jad@...; David Honey2 <david.honey@...>; Jim Amsden <jamsden@...>
Subject: [EXTERNAL] Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

There seems to be general agreement we can store a “link” on either side given that the “link” has two predicates (one for the subject and then an inverse-link). Also there seems to be some agreement that the inverse-link information would

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

There seems to be general agreement we can store a “link” on either side given that the “link” has two predicates (one for the subject and then an inverse-link). Also there seems to be some agreement that the inverse-link information would be listed in ResourceShapes, so that a tool might even know what links to query for.

 

The only point is that IBM-ELM doesn’t currently do it this way. In OPT-IN mode links are stored only on the dependent side. In OPT-OUT they are usually (but not always) stored on both side with the inverseLink.

 

Link profile work is trying to be inclusive, to define what is required to get as much as possible to integrate with as little effort as required (therefore I softened my position on oauth1.0a)

 

 

 

 

 

From: oslc-op@... <oslc-op@...> On Behalf Of Jad El-Khoury via lists.oasis-open-projects.org
Sent: Donnerstag, 29. September 2022 11:27
To: David Honey2 <david.honey@...>; oslc-op@...; Jim Amsden <jamsden@...>
Subject: Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

Now you’ve introduced a new discussion: “primary vs secondary persistence”.

 

Putting that aside, and focusing on one-directional links to start with, what’s the problem with suggesting that links are stored on the “outgoing side” (in RDF terms, the Subject)?

 

Even for bi-directional links, this statement can hold - in each direction, given that we will use 2 different properties for each direction.

 

______________________________

Jad El-khoury, PhD

KTH Royal Institute of Technology

School of Industrial Engineering and Management, Mechatronics Division

Brinellvägen 83, SE-100 44 Stockholm, Sweden

Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45

jad@..., www.kth.se

 

From: David Honey2 <david.honey@...>
Sent: Thursday, 29 September 2022 11:04
To: oslc-op@...; Jad El-Khoury <jad@...>; Jim Amsden <jamsden@...>
Subject: RE: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

ELM already uses a http://jazz.net/ns/jrs#inversePropertyDefinition in resource shapes to tie together forward and backward links. Report Builder uses that to query for the union of the forward and backward link. However, that doesn’t provide any indication of which end should be considered the primary vs secondary persistence.

 

Best regards,

David

 

From: oslc-op@... <oslc-op@...> On Behalf Of Jad El-Khoury
Sent: 29 September 2022 09:44
To: oslc-op@...; Jim Amsden <jamsden@...>
Subject: [EXTERNAL] Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

Hi I’m going back to an earlier point in the thread to be more specific in my comment (and to not confuse the new direction of the thread). Given that the relationship is an RDF statement, is it even reasonable to store information about the

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Hi

 

I’m going back to an earlier point in the thread to be more specific in my comment (and to not confuse the new direction of the thread).

 

Given that the relationship is an RDF statement, is it even reasonable to store information about the link – but on “outgoing side” (in RDF, I assume this means the Subject).

While we can’t stop it, I struggling to understand how the server of the Object can save such a statement. (unless of course, one opts for bi-directional links. But in that case, we will have to use a new opposite relationship where the Object becomes the Subject of that relationship).

 

regards

______________________________

Jad El-khoury, PhD

KTH Royal Institute of Technology

School of Industrial Engineering and Management, Mechatronics Division

Brinellvägen 83, SE-100 44 Stockholm, Sweden

Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45

jad@..., www.kth.se

 

From: oslc-op@... <oslc-op@...> On Behalf Of Jim Amsden
Sent: Friday, 23 September 2022 20:21
To: oslc-op@...
Subject: Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

You could just use a normative table of outgoing and incoming link types (i.e., property and inverse properties). However, it would be nice if this was machine readable, and an extension to ResourceShapes would do that.

 

We could also decide to declare property and inverse properties in the OSLC vocabularies. That wouldn’t require any extensions. Since OSLC does not rely on RDF inferencing, this shouldn’t create any problems.

 

 

 

 

 

From: <oslc-op@...> on behalf of Eran Gery <eran.gery@...>
Reply-To: "oslc-op@..." <oslc-op@...>, Eran Gery <eran.gery@...>
Date: Friday, September 23, 2022 at 10:24 AM
To: Eran Gery <eran.gery@...>, "Gentry, Edward" <e.gentry@...>
Cc: "oslc-op@..." <oslc-op@...>
Subject: [EXTERNAL] Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

Ed, Jim did not accept the text as he is not sure that the “store on outgoing side” is respected by ELM. Can you comment on that. One comment I have is that it is enough that it is the 90% case as a principle. We can document exceptions. ‍ ‍

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Ed,

 

Jim did not accept the text as he is not sure that the “store on outgoing side” is respected by ELM.

Can you comment on that.

One comment I have is that it is enough that it is the 90% case as a principle. We can document exceptions.

There are clearly exceptions in opt-out mode that there are still backlinks with CCM. We can document that as an exception.

Jim suggested that we may have to use OSLC shapes to determine the owner, IMO it is a no go for the reason that the maturity level of the bi-diretional profile is far from mandating OSLC shapes. Actually, none of the linking profile require support for shapes.

So the only options I see

  1. Specify “owned by outgoing end” is a rule with some exceptions related to ELM.
  2. Have a detailed per link type (predicate) specification based on all existing OSLC domain links.
  3. A combination of both.

 

Please speak up…

 

Eran

 

From: oslc-op@... <oslc-op@...> On Behalf Of "Eran Gery"
Sent: Thursday, 22 September 2022 15:59
To: Gentry, Edward <e.gentry@...>
Cc: oslc-op@...
Subject: [EXTERNAL] Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

Ed Please review the link ownership text Link ownership In bi-derctional linking scenarios both OSLC participants are aware of links across their owned resources and enable link visibility and navigation at each side. Nevertheless ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Ed

 

Please review the link ownership text

 

Link ownership

 

In bi-derctional linking scenarios both OSLC participants are aware of links across their owned resources and enable link visibility and navigation at each side. Nevertheless, storing a link at both sides is considered an ill-practice as it is essentially replication of data. This may result in inconsistencies as links are updated or deleted, since maintaining consistency requires synchronization across the providers on any update. Therefore, the recommended practice is to store links on one of the participants, and use link discovery by the other participant. Therefore, there needs to be an agreed convention on which side should store the link. OSLC links have an incoming and outgoing sides, determined by the role of the link. Usually one side will have an active predicate name, for example "implements" and the other side will have a passive predicate name, in this example it would be "implemented by". The active side is also considered the outgoing side, and the passive the incoming side. The convention is that the link is stored with the resource on the outgoing side, i.e. the resource with the active predicate. The incoming side would discover the links with one of the discovery methods discussed in the following sections. Note the creation of the link may be initiated by both providers. In case that the link is initiated by the incoming side provider, it needs to store it with the resource on the outgoing side provider. This is discussed in the put on resources section.

 

Thanks

eran

 

From: Gentry, Edward <e.gentry@...>
Sent: Thursday, 22 September 2022 15:16
To: oslc-op@...; james_e_gammon@...; Eran Gery <eran.gery@...>; Jim Amsden <jamsden@...>; David Honey2 <david.honey@...>
Subject: [EXTERNAL] 22.9 oslc-op Weekly Contributors Meeting

 

Hi All, I’m traveling today and so will miss our meeting this afternoon. @David Honey2, could you please arrange a meeting with John Vasta for me regarding the authentication in the link Profile? We should be able to keep it to 30 minutes. 

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Hi All,

 

I’m traveling today and so will miss our meeting this afternoon.

 

@David Honey2, could you please arrange a meeting with John Vasta for me regarding the authentication in the link Profile? We should be able to keep it to 30 minutes. Find something that works for him in the morning and I’ll make it work.

 

Cheers,

 

Ed

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
 

Perhaps this will be clearer with an example.
Say a resource shape for a test case defines an OSLC property:

  • dcterms:title “Validates requirement”
  • oslc:propertyDefinition oslc_qm:validatesRequirement
  • jrs:inversePropertyDefinition oslc_rm:validatedBy

and a resource shape for a requirement defines an OSLC property:

  • dcterms:title “Validated By”
  • oslc:propertyDefinition oslc_rm:validatedBy
  • jrs:inversePropertyDefinition oslc_qm:validatesRequirement

 

That defines a symmetric pair of relationship properties.
But it does not answer any of the following questions:

  • Which is the forward link and which the reverse link?
  • Should I store the link on the test case or the requirement?

 

From: Gentry, Edward <e.gentry@...>
Sent: 29 September 2022 10:40
To: oslc-op@...; David Honey2 <david.honey@...>; Jad El-Khoury <jad@...>; Jim Amsden <jamsden@...>
Subject: [EXTERNAL] RE: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

David, I don’t understand “tells you nothing about which is the forward link or whether the data should be stored on the test case or the requirement. ” What do you mean by “forward link”, and yes I think we do know where we store links when

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

David,

 

I don’t understand “tells you nothing about which is the forward link or whether the data should be stored on the test case or the requirement.”

 

What do you mean by “forward link”, and yes I think we do know where we store links when have inverse-links e.g. validatesRequirement is stored on the test case, and validatedBy on the Requirement. You said this yourself.  

 

From: oslc-op@... <oslc-op@...> On Behalf Of David Honey2 via lists.oasis-open-projects.org
Sent: Donnerstag, 29. September 2022 11:36
To: Jad El-Khoury <jad@...>; oslc-op@...; Jim Amsden <jamsden@...>
Subject: Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

It’s not a new topic. The issue being discussed is knowing which side of the link should store the link. Knowing, for example, that validatesRequirement stored on a test case has an inverse validatedBy that might be stored on a requirement tells you nothing about which is the forward link or whether the data should be stored on the test case or the requirement.

 

From: Jad El-Khoury <jad@...>
Sent: 29 September 2022 10:27
To: David Honey2 <david.honey@...>; oslc-op@...; Jim Amsden <jamsden@...>
Subject: [EXTERNAL] RE: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

Now you’ve introduced a new discussion: “primary vs secondary persistence”. Putting that aside, and focusing on one-directional links to start with, what’s the problem with suggesting that links are stored on the ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Now you’ve introduced a new discussion: “primary vs secondary persistence”.

 

Putting that aside, and focusing on one-directional links to start with, what’s the problem with suggesting that links are stored on the “outgoing side” (in RDF terms, the Subject)?

 

Even for bi-directional links, this statement can hold - in each direction, given that we will use 2 different properties for each direction.

 

______________________________

Jad El-khoury, PhD

KTH Royal Institute of Technology

School of Industrial Engineering and Management, Mechatronics Division

Brinellvägen 83, SE-100 44 Stockholm, Sweden

Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45

jad@..., www.kth.se

 

From: David Honey2 <david.honey@...>
Sent: Thursday, 29 September 2022 11:04
To: oslc-op@...; Jad El-Khoury <jad@...>; Jim Amsden <jamsden@...>
Subject: RE: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

ELM already uses a http://jazz.net/ns/jrs#inversePropertyDefinition in resource shapes to tie together forward and backward links. Report Builder uses that to query for the union of the forward and backward link. However, that doesn’t provide any indication of which end should be considered the primary vs secondary persistence.

 

Best regards,

David

 

From: oslc-op@... <oslc-op@...> On Behalf Of Jad El-Khoury
Sent: 29 September 2022 09:44
To: oslc-op@...; Jim Amsden <jamsden@...>
Subject: [EXTERNAL] Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

Hi I’m going back to an earlier point in the thread to be more specific in my comment (and to not confuse the new direction of the thread). Given that the relationship is an RDF statement, is it even reasonable to store information about the

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Hi

 

I’m going back to an earlier point in the thread to be more specific in my comment (and to not confuse the new direction of the thread).

 

Given that the relationship is an RDF statement, is it even reasonable to store information about the link – but on “outgoing side” (in RDF, I assume this means the Subject).

While we can’t stop it, I struggling to understand how the server of the Object can save such a statement. (unless of course, one opts for bi-directional links. But in that case, we will have to use a new opposite relationship where the Object becomes the Subject of that relationship).

 

regards

______________________________

Jad El-khoury, PhD

KTH Royal Institute of Technology

School of Industrial Engineering and Management, Mechatronics Division

Brinellvägen 83, SE-100 44 Stockholm, Sweden

Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45

jad@..., www.kth.se

 

From: oslc-op@... <oslc-op@...> On Behalf Of Jim Amsden
Sent: Friday, 23 September 2022 20:21
To: oslc-op@...
Subject: Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

You could just use a normative table of outgoing and incoming link types (i.e., property and inverse properties). However, it would be nice if this was machine readable, and an extension to ResourceShapes would do that.

 

We could also decide to declare property and inverse properties in the OSLC vocabularies. That wouldn’t require any extensions. Since OSLC does not rely on RDF inferencing, this shouldn’t create any problems.

 

 

 

 

 

From: <oslc-op@...> on behalf of Eran Gery <eran.gery@...>
Reply-To: "oslc-op@..." <oslc-op@...>, Eran Gery <eran.gery@...>
Date: Friday, September 23, 2022 at 10:24 AM
To: Eran Gery <eran.gery@...>, "Gentry, Edward" <e.gentry@...>
Cc: "oslc-op@..." <oslc-op@...>
Subject: [EXTERNAL] Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

Ed, Jim did not accept the text as he is not sure that the “store on outgoing side” is respected by ELM. Can you comment on that. One comment I have is that it is enough that it is the 90% case as a principle. We can document exceptions. ‍ ‍

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Ed,

 

Jim did not accept the text as he is not sure that the “store on outgoing side” is respected by ELM.

Can you comment on that.

One comment I have is that it is enough that it is the 90% case as a principle. We can document exceptions.

There are clearly exceptions in opt-out mode that there are still backlinks with CCM. We can document that as an exception.

Jim suggested that we may have to use OSLC shapes to determine the owner, IMO it is a no go for the reason that the maturity level of the bi-diretional profile is far from mandating OSLC shapes. Actually, none of the linking profile require support for shapes.

So the only options I see

  1. Specify “owned by outgoing end” is a rule with some exceptions related to ELM.
  2. Have a detailed per link type (predicate) specification based on all existing OSLC domain links.
  3. A combination of both.

 

Please speak up…

 

Eran

 

From: oslc-op@... <oslc-op@...> On Behalf Of "Eran Gery"
Sent: Thursday, 22 September 2022 15:59
To: Gentry, Edward <e.gentry@...>
Cc: oslc-op@...
Subject: [EXTERNAL] Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

Ed Please review the link ownership text Link ownership In bi-derctional linking scenarios both OSLC participants are aware of links across their owned resources and enable link visibility and navigation at each side. Nevertheless ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Ed

 

Please review the link ownership text

 

Link ownership

 

In bi-derctional linking scenarios both OSLC participants are aware of links across their owned resources and enable link visibility and navigation at each side. Nevertheless, storing a link at both sides is considered an ill-practice as it is essentially replication of data. This may result in inconsistencies as links are updated or deleted, since maintaining consistency requires synchronization across the providers on any update. Therefore, the recommended practice is to store links on one of the participants, and use link discovery by the other participant. Therefore, there needs to be an agreed convention on which side should store the link. OSLC links have an incoming and outgoing sides, determined by the role of the link. Usually one side will have an active predicate name, for example "implements" and the other side will have a passive predicate name, in this example it would be "implemented by". The active side is also considered the outgoing side, and the passive the incoming side. The convention is that the link is stored with the resource on the outgoing side, i.e. the resource with the active predicate. The incoming side would discover the links with one of the discovery methods discussed in the following sections. Note the creation of the link may be initiated by both providers. In case that the link is initiated by the incoming side provider, it needs to store it with the resource on the outgoing side provider. This is discussed in the put on resources section.

 

Thanks

eran

 

From: Gentry, Edward <e.gentry@...>
Sent: Thursday, 22 September 2022 15:16
To: oslc-op@...; james_e_gammon@...; Eran Gery <eran.gery@...>; Jim Amsden <jamsden@...>; David Honey2 <david.honey@...>
Subject: [EXTERNAL] 22.9 oslc-op Weekly Contributors Meeting

 

Hi All, I’m traveling today and so will miss our meeting this afternoon. @David Honey2, could you please arrange a meeting with John Vasta for me regarding the authentication in the link Profile? We should be able to keep it to 30 minutes. 

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Hi All,

 

I’m traveling today and so will miss our meeting this afternoon.

 

@David Honey2, could you please arrange a meeting with John Vasta for me regarding the authentication in the link Profile? We should be able to keep it to 30 minutes. Find something that works for him in the morning and I’ll make it work.

 

Cheers,

 

Ed

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

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: Currently no one outside ELM implements shapes
Resource shapes are a central part of OSLC core, and I think it highly unlikely that no non IBM OSLC server implements them. I am not aware that we have conducted an extensive survey to backup such an assertion.

 

From: Eran Gery <eran.gery@...>
Sent: 29 September 2022 10:47
To: oslc-op@...; e.gentry@...; jad@...; David Honey2 <david.honey@...>; Jim Amsden <jamsden@...>
Subject: RE: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

Guys,

 

The bi-directional profile cannot rely on resource shapes as I noted earlier.

It is the next tier after most basic. Currently no one outside ELM implements shapes.

What makes sense to me is that

  1. We explain the policy of single link as the general rule as I specified
  2. We document ELM exceptions for opt-out mode (e.g. RM<->QM, RM<->CM)

 

The goal of the profile is to be a practical survival guide in the OSLC space…

 

Regards,

Eran

 

From: oslc-op@... <oslc-op@...> On Behalf Of Gentry, Edward
Sent: Thursday, 29 September 2022 12:35
To: oslc-op@...; jad@...; David Honey2 <david.honey@...>; Jim Amsden <jamsden@...>
Subject: [EXTERNAL] Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

There seems to be general agreement we can store a “link” on either side given that the “link” has two predicates (one for the subject and then an inverse-link). Also there seems to be some agreement that the inverse-link information would

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

There seems to be general agreement we can store a “link” on either side given that the “link” has two predicates (one for the subject and then an inverse-link). Also there seems to be some agreement that the inverse-link information would be listed in ResourceShapes, so that a tool might even know what links to query for.

 

The only point is that IBM-ELM doesn’t currently do it this way. In OPT-IN mode links are stored only on the dependent side. In OPT-OUT they are usually (but not always) stored on both side with the inverseLink.

 

Link profile work is trying to be inclusive, to define what is required to get as much as possible to integrate with as little effort as required (therefore I softened my position on oauth1.0a)

 

 

 

 

 

From: oslc-op@... <oslc-op@...> On Behalf Of Jad El-Khoury via lists.oasis-open-projects.org
Sent: Donnerstag, 29. September 2022 11:27
To: David Honey2 <david.honey@...>; oslc-op@...; Jim Amsden <jamsden@...>
Subject: Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

Now you’ve introduced a new discussion: “primary vs secondary persistence”.

 

Putting that aside, and focusing on one-directional links to start with, what’s the problem with suggesting that links are stored on the “outgoing side” (in RDF terms, the Subject)?

 

Even for bi-directional links, this statement can hold - in each direction, given that we will use 2 different properties for each direction.

 

______________________________

Jad El-khoury, PhD

KTH Royal Institute of Technology

School of Industrial Engineering and Management, Mechatronics Division

Brinellvägen 83, SE-100 44 Stockholm, Sweden

Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45

jad@..., www.kth.se

 

From: David Honey2 <david.honey@...>
Sent: Thursday, 29 September 2022 11:04
To: oslc-op@...; Jad El-Khoury <jad@...>; Jim Amsden <jamsden@...>
Subject: RE: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

ELM already uses a http://jazz.net/ns/jrs#inversePropertyDefinition in resource shapes to tie together forward and backward links. Report Builder uses that to query for the union of the forward and backward link. However, that doesn’t provide any indication of which end should be considered the primary vs secondary persistence.

 

Best regards,

David

 

From: oslc-op@... <oslc-op@...> On Behalf Of Jad El-Khoury
Sent: 29 September 2022 09:44
To: oslc-op@...; Jim Amsden <jamsden@...>
Subject: [EXTERNAL] Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

Hi I’m going back to an earlier point in the thread to be more specific in my comment (and to not confuse the new direction of the thread). Given that the relationship is an RDF statement, is it even reasonable to store information about the

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Hi

 

I’m going back to an earlier point in the thread to be more specific in my comment (and to not confuse the new direction of the thread).

 

Given that the relationship is an RDF statement, is it even reasonable to store information about the link – but on “outgoing side” (in RDF, I assume this means the Subject).

While we can’t stop it, I struggling to understand how the server of the Object can save such a statement. (unless of course, one opts for bi-directional links. But in that case, we will have to use a new opposite relationship where the Object becomes the Subject of that relationship).

 

regards

______________________________

Jad El-khoury, PhD

KTH Royal Institute of Technology

School of Industrial Engineering and Management, Mechatronics Division

Brinellvägen 83, SE-100 44 Stockholm, Sweden

Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45

jad@..., www.kth.se

 

From: oslc-op@... <oslc-op@...> On Behalf Of Jim Amsden
Sent: Friday, 23 September 2022 20:21
To: oslc-op@...
Subject: Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

You could just use a normative table of outgoing and incoming link types (i.e., property and inverse properties). However, it would be nice if this was machine readable, and an extension to ResourceShapes would do that.

 

We could also decide to declare property and inverse properties in the OSLC vocabularies. That wouldn’t require any extensions. Since OSLC does not rely on RDF inferencing, this shouldn’t create any problems.

 

 

 

 

 

From: <oslc-op@...> on behalf of Eran Gery <eran.gery@...>
Reply-To: "oslc-op@..." <oslc-op@...>, Eran Gery <eran.gery@...>
Date: Friday, September 23, 2022 at 10:24 AM
To: Eran Gery <eran.gery@...>, "Gentry, Edward" <e.gentry@...>
Cc: "oslc-op@..." <oslc-op@...>
Subject: [EXTERNAL] Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

Ed, Jim did not accept the text as he is not sure that the “store on outgoing side” is respected by ELM. Can you comment on that. One comment I have is that it is enough that it is the 90% case as a principle. We can document exceptions. ‍ ‍

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Ed,

 

Jim did not accept the text as he is not sure that the “store on outgoing side” is respected by ELM.

Can you comment on that.

One comment I have is that it is enough that it is the 90% case as a principle. We can document exceptions.

There are clearly exceptions in opt-out mode that there are still backlinks with CCM. We can document that as an exception.

Jim suggested that we may have to use OSLC shapes to determine the owner, IMO it is a no go for the reason that the maturity level of the bi-diretional profile is far from mandating OSLC shapes. Actually, none of the linking profile require support for shapes.

So the only options I see

  1. Specify “owned by outgoing end” is a rule with some exceptions related to ELM.
  2. Have a detailed per link type (predicate) specification based on all existing OSLC domain links.
  3. A combination of both.

 

Please speak up…

 

Eran

 

From: oslc-op@... <oslc-op@...> On Behalf Of "Eran Gery"
Sent: Thursday, 22 September 2022 15:59
To: Gentry, Edward <e.gentry@...>
Cc: oslc-op@...
Subject: [EXTERNAL] Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting

 

Ed Please review the link ownership text Link ownership In bi-derctional linking scenarios both OSLC participants are aware of links across their owned resources and enable link visibility and navigation at each side. Nevertheless ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Ed

 

Please review the link ownership text

 

Link ownership

 

In bi-derctional linking scenarios both OSLC participants are aware of links across their owned resources and enable link visibility and navigation at each side. Nevertheless, storing a link at both sides is considered an ill-practice as it is essentially replication of data. This may result in inconsistencies as links are updated or deleted, since maintaining consistency requires synchronization across the providers on any update. Therefore, the recommended practice is to store links on one of the participants, and use link discovery by the other participant. Therefore, there needs to be an agreed convention on which side should store the link. OSLC links have an incoming and outgoing sides, determined by the role of the link. Usually one side will have an active predicate name, for example "implements" and the other side will have a passive predicate name, in this example it would be "implemented by". The active side is also considered the outgoing side, and the passive the incoming side. The convention is that the link is stored with the resource on the outgoing side, i.e. the resource with the active predicate. The incoming side would discover the links with one of the discovery methods discussed in the following sections. Note the creation of the link may be initiated by both providers. In case that the link is initiated by the incoming side provider, it needs to store it with the resource on the outgoing side provider. This is discussed in the put on resources section.

 

Thanks

eran

 

From: Gentry, Edward <e.gentry@...>
Sent: Thursday, 22 September 2022 15:16
To: oslc-op@...; james_e_gammon@...; Eran Gery <eran.gery@...>; Jim Amsden <jamsden@...>; David Honey2 <david.honey@...>
Subject: [EXTERNAL] 22.9 oslc-op Weekly Contributors Meeting

 

Hi All, I’m traveling today and so will miss our meeting this afternoon. @David Honey2, could you please arrange a meeting with John Vasta for me regarding the authentication in the link Profile? We should be able to keep it to 30 minutes. 

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Hi All,

 

I’m traveling today and so will miss our meeting this afternoon.

 

@David Honey2, could you please arrange a meeting with John Vasta for me regarding the authentication in the link Profile? We should be able to keep it to 30 minutes. Find something that works for him in the morning and I’ll make it work.

 

Cheers,

 

Ed

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