Date   

Re: [oslc-op-pgb] Stepping down as a co-chair

Jad El-Khoury
 

Hi all

 

I do hope that this will only be a temporary break, and that we get back a full-fledged doctor in the end.

 

______________________________

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: Gray Bachelor <gray_bachelor@...>
Sent: Tuesday, 21 June 2022 23:27
To: Andrii Berezovskyi <andriib@...>; oslc-op-pgb@...; chet.ensign@...
Cc: Jad El-Khoury <jad@...>; oslc-op@...
Subject: RE: [oslc-op-pgb] Stepping down as a co-chair

 

Dear Andrii

this isnt good news for us but fully understandable

 

You've done a fabulous job on many fronts - pre-OASIS, the shift to OASIS, getting GITHub up and running, working through many issues with Jim and others on getting all of the 2.1's and 3.0s out of the door, plus of course all of the discussions over usage, extensions and compatibility.

 

Your calm attention to detail is legend and a big thanks for keeping us safe and sane with a lot of stuff that could be described as housekeeping - that was always appreciated by me.

 

and as others have already said you can definitely take a lot of satisfaction in your solid technical contribution all round

 

I've been a bit out of the loop recently but I read pretty every every community thread and if you are not at the centre of a thread you are not far away on most all of them.

 

Well done and a very big thank you.

 

Very best wishes for your thesis and likely elevation to the pantheon !

 

regards

Gray


From: oslc-op-pgb@... <oslc-op-pgb@...> on behalf of Chet Ensign <chet.ensign@...>
Sent: Tuesday, June 21, 2022 7:41 PM
To: Andrii Berezovskyi <andriib@...>
Cc: oslc-op-pgb@... <oslc-op-pgb@...>; Jad El-Khoury <jad@...>; oslc-op@... <oslc-op@...>
Subject: [EXTERNAL] Re: [oslc-op-pgb] Stepping down as a co-chair

 

Andrew, I'm sure it will feel great to get your PhD done. Good for you and echoing everyone here - you are always a treat to work with and I hope you can stay involved. The project will benefit from any attention you can give it. ‍ ‍ ‍ ‍ ‍

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

 

ZjQcmQRYFpfptBannerEnd

Andrew, I'm sure it will feel great to get your PhD done. Good for you and echoing everyone here - you are always a treat to work with and I hope you can stay involved. The project will benefit from any attention you can give it. 

 

Regarding your questions... 

 

On Tue, Jun 21, 2022 at 1:19 PM Andrii Berezovskyi <andriib@...> wrote:

Hi,

 

I thought about my involvement in OSLC for a while, and I think there is a big likelihood that I won’t be able to put more time on OSLC after summer.

 

To make sure OSLC progress does not get slowed down by the need to focus on finishing my Ph.D., I would like to step down as a co-chair. I can stay as a PGB member for a little while longer if needed but I am ready to step down from that as well (and suggest that Jad takes the KTH seat on the PGB).

 

Chet, what are the next steps for us? Do we need to involve Martin Törngren who is the KTH representative at OASIS?

 

Probably best if Martin notifies us by email if Jad takes your place. As the KTH rep, that will ensure there is no confusion.

 

Jim, I hope you will be able to fill in the co-chair position with Axel, Jad, or Frej if SodiusWillert will step up to join the PGB (chairs can only be selected among PGB members, AFAIK).

 

That is correct. The PGB chair is elected from among the members. 

 

I hope to re-join the OP activities once I finish the Ph.D. work, but for now, let me thank you for the privilege of co-chairing the OSLC project with you and learning so much (technically and wisdom-wise) from you over the years.

 

I am also thankful to Jad for introducing me to OSLC, to Chet, Paul, and the rest of OASIS for supporting us,

 

It is our honor to host and support your work. 

 

to the PGB for productive work on promoting OSLC, and to everyone in the OP for collaborating on OSLC and ways to improve tool integration! I wish the OP to flourish and gain more members in the future!

 

Here here to that...  

 

Best regards,

Andrew


 

--

Chet Ensign

Chief Technical Community Steward

OASIS Open

 

 

 

+1 201-341-1393

chet.ensign@...

www.oasis-open.org

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


Re: [oslc-op-pgb] Stepping down as a co-chair

Gray Bachelor
 

Dear Andrii
this isnt good news for us but fully understandable

You've done a fabulous job on many fronts - pre-OASIS, the shift to OASIS, getting GITHub up and running, working through many issues with Jim and others on getting all of the 2.1's and 3.0s out of the door, plus of course all of the discussions over usage, extensions and compatibility.

Your calm attention to detail is legend and a big thanks for keeping us safe and sane with a lot of stuff that could be described as housekeeping - that was always appreciated by me.

and as others have already said you can definitely take a lot of satisfaction in your solid technical contribution all round

I've been a bit out of the loop recently but I read pretty every every community thread and if you are not at the centre of a thread you are not far away on most all of them.

Well done and a very big thank you.

Very best wishes for your thesis and likely elevation to the pantheon !

regards
Gray


From: oslc-op-pgb@... <oslc-op-pgb@...> on behalf of Chet Ensign <chet.ensign@...>
Sent: Tuesday, June 21, 2022 7:41 PM
To: Andrii Berezovskyi <andriib@...>
Cc: oslc-op-pgb@... <oslc-op-pgb@...>; Jad El-Khoury <jad@...>; oslc-op@... <oslc-op@...>
Subject: [EXTERNAL] Re: [oslc-op-pgb] Stepping down as a co-chair
 
Andrew, I'm sure it will feel great to get your PhD done. Good for you and echoing everyone here - you are always a treat to work with and I hope you can stay involved. The project will benefit from any attention you can give it. ‍ ‍ ‍ ‍ ‍
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
 
ZjQcmQRYFpfptBannerEnd
Andrew, I'm sure it will feel great to get your PhD done. Good for you and echoing everyone here - you are always a treat to work with and I hope you can stay involved. The project will benefit from any attention you can give it. 

Regarding your questions... 

On Tue, Jun 21, 2022 at 1:19 PM Andrii Berezovskyi <andriib@...> wrote:

Hi,

 

I thought about my involvement in OSLC for a while, and I think there is a big likelihood that I won’t be able to put more time on OSLC after summer.

 

To make sure OSLC progress does not get slowed down by the need to focus on finishing my Ph.D., I would like to step down as a co-chair. I can stay as a PGB member for a little while longer if needed but I am ready to step down from that as well (and suggest that Jad takes the KTH seat on the PGB).

 

Chet, what are the next steps for us? Do we need to involve Martin Törngren who is the KTH representative at OASIS?


Probably best if Martin notifies us by email if Jad takes your place. As the KTH rep, that will ensure there is no confusion.

 

Jim, I hope you will be able to fill in the co-chair position with Axel, Jad, or Frej if SodiusWillert will step up to join the PGB (chairs can only be selected among PGB members, AFAIK).


That is correct. The PGB chair is elected from among the members. 
 

I hope to re-join the OP activities once I finish the Ph.D. work, but for now, let me thank you for the privilege of co-chairing the OSLC project with you and learning so much (technically and wisdom-wise) from you over the years.

 

I am also thankful to Jad for introducing me to OSLC, to Chet, Paul, and the rest of OASIS for supporting us,


It is our honor to host and support your work. 
 

to the PGB for productive work on promoting OSLC, and to everyone in the OP for collaborating on OSLC and ways to improve tool integration! I wish the OP to flourish and gain more members in the future!


Here here to that...  

 

Best regards,

Andrew



--

Chet Ensign

Chief Technical Community Steward

OASIS Open

     
+1 201-341-1393
chet.ensign@...
www.oasis-open.org
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


Re: Stepping down as a co-chair

Michael Rowe
 

Andrew,

 

Our paths have not crossed much, but your welcome when I joined my first call was much appreciated. However, your leadership on the call and drive to push OSLC forward was palatable.  

 

-- 

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

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

Sustainable Software

 

 

 

From: oslc-op@... <oslc-op@...> on behalf of Andrii Berezovskyi <andriib@...>
Date: Tuesday, June 21, 2022 at 13:20
To: oslc-op-pgb@... <oslc-op-pgb@...>
Cc: Chet Ensign <chet.ensign@...>, Jad El-Khoury <jad@...>, oslc-op@... <oslc-op@...>
Subject: [EXTERNAL] [oslc-op] Stepping down as a co-chair

Hi, I thought about my involvement in OSLC for a while, and I think there is a big likelihood that I won’t be able to put more time on OSLC after summer. To make sure OSLC progress does not get slowed down by the need to focus on finishing

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Hi,

 

I thought about my involvement in OSLC for a while, and I think there is a big likelihood that I won’t be able to put more time on OSLC after summer.

 

To make sure OSLC progress does not get slowed down by the need to focus on finishing my Ph.D., I would like to step down as a co-chair. I can stay as a PGB member for a little while longer if needed but I am ready to step down from that as well (and suggest that Jad takes the KTH seat on the PGB).

 

Chet, what are the next steps for us? Do we need to involve Martin Törngren who is the KTH representative at OASIS?

 

Jim, I hope you will be able to fill in the co-chair position with Axel, Jad, or Frej if SodiusWillert will step up to join the PGB (chairs can only be selected among PGB members, AFAIK). I hope to re-join the OP activities once I finish the Ph.D. work, but for now, let me thank you for the privilege of co-chairing the OSLC project with you and learning so much (technically and wisdom-wise) from you over the years.

 

I am also thankful to Jad for introducing me to OSLC, to Chet, Paul, and the rest of OASIS for supporting us, to the PGB for productive work on promoting OSLC, and to everyone in the OP for collaborating on OSLC and ways to improve tool integration! I wish the OP to flourish and gain more members in the future!

 

Best regards,

Andrew


Re: Stepping down as a co-chair

Chet Ensign
 

Andrew, I'm sure it will feel great to get your PhD done. Good for you and echoing everyone here - you are always a treat to work with and I hope you can stay involved. The project will benefit from any attention you can give it. 

Regarding your questions... 

On Tue, Jun 21, 2022 at 1:19 PM Andrii Berezovskyi <andriib@...> wrote:

Hi,

 

I thought about my involvement in OSLC for a while, and I think there is a big likelihood that I won’t be able to put more time on OSLC after summer.

 

To make sure OSLC progress does not get slowed down by the need to focus on finishing my Ph.D., I would like to step down as a co-chair. I can stay as a PGB member for a little while longer if needed but I am ready to step down from that as well (and suggest that Jad takes the KTH seat on the PGB).

 

Chet, what are the next steps for us? Do we need to involve Martin Törngren who is the KTH representative at OASIS?


Probably best if Martin notifies us by email if Jad takes your place. As the KTH rep, that will ensure there is no confusion.

 

Jim, I hope you will be able to fill in the co-chair position with Axel, Jad, or Frej if SodiusWillert will step up to join the PGB (chairs can only be selected among PGB members, AFAIK).


That is correct. The PGB chair is elected from among the members. 
 

I hope to re-join the OP activities once I finish the Ph.D. work, but for now, let me thank you for the privilege of co-chairing the OSLC project with you and learning so much (technically and wisdom-wise) from you over the years.

 

I am also thankful to Jad for introducing me to OSLC, to Chet, Paul, and the rest of OASIS for supporting us,


It is our honor to host and support your work. 
 

to the PGB for productive work on promoting OSLC, and to everyone in the OP for collaborating on OSLC and ways to improve tool integration! I wish the OP to flourish and gain more members in the future!


Here here to that...  

 

Best regards,

Andrew



--

Chet Ensign

Chief Technical Community Steward

OASIS Open

   
+1 201-341-1393
chet.ensign@...
www.oasis-open.org


Re: Stepping down as a co-chair

Robert Baillargeon
 

A tough but important decision Andrew.  I wish you all the best with the next step of finishing your Ph.D.  Thanks for the efforts and the consideration of your focus on the future.

The SodiusWillert team will review how we could consider stepping up in our contribution.  We aren't Andrew, but we do share the care and interest in OSLC's success.

Good luck Andrew!

Thanks!
Robert


Chief Product Officer – Linked Data

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

 


 

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


From: oslc-op@... <oslc-op@...> on behalf of "Eran Gery" via lists.oasis-open-projects.org <eran.gery=il.ibm.com@...>
Sent: Tuesday, June 21, 2022 2:07 PM
To: oslc-op@... <oslc-op@...>; axel.reichwein@... <axel.reichwein@...>
Cc: Andrii Berezovskyi <andriib@...>
Subject: Re: [oslc-op] Stepping down as a co-chair
 
Indeed… i liked Andrew’s constructive approach to move things forward, and his interaction with team members.
I hope you stay connected Andrew!



On 21 Jun 2022, at 20:29, Axel Reichwein <axel.reichwein@...> wrote:




Re: Stepping down as a co-chair

"Eran Gery"
 

Indeed… i liked Andrew’s constructive approach to move things forward, and his interaction with team members.
I hope you stay connected Andrew!



On 21 Jun 2022, at 20:29, Axel Reichwein <axel.reichwein@...> wrote:




Re: Stepping down as a co-chair

Axel Reichwein
 

I'm very sad to hear this.

Andrew, I hope that you will be involved one way or another with OSLC, even after stepping down as co-chair!

It was a pleasure working with you to organize the OSLCFest events!

Cheers,
Axel


Stepping down as a co-chair

Andrii Berezovskyi
 

Hi,

 

I thought about my involvement in OSLC for a while, and I think there is a big likelihood that I won’t be able to put more time on OSLC after summer.

 

To make sure OSLC progress does not get slowed down by the need to focus on finishing my Ph.D., I would like to step down as a co-chair. I can stay as a PGB member for a little while longer if needed but I am ready to step down from that as well (and suggest that Jad takes the KTH seat on the PGB).

 

Chet, what are the next steps for us? Do we need to involve Martin Törngren who is the KTH representative at OASIS?

 

Jim, I hope you will be able to fill in the co-chair position with Axel, Jad, or Frej if SodiusWillert will step up to join the PGB (chairs can only be selected among PGB members, AFAIK). I hope to re-join the OP activities once I finish the Ph.D. work, but for now, let me thank you for the privilege of co-chairing the OSLC project with you and learning so much (technically and wisdom-wise) from you over the years.

 

I am also thankful to Jad for introducing me to OSLC, to Chet, Paul, and the rest of OASIS for supporting us, to the PGB for productive work on promoting OSLC, and to everyone in the OP for collaborating on OSLC and ways to improve tool integration! I wish the OP to flourish and gain more members in the future!

 

Best regards,

Andrew


Now: oslc-op Weekly Contributors Meeting - 06/16/2022 #cal-notice

Group Notification <noreply@...>
 

oslc-op Weekly Contributors Meeting

When:
06/16/2022
10:00am to 11:00am
(UTC-04:00) America/New York

Where:
https://meet.jit.si/oslc-op

Organizer: Jim Amsden jamsden@...

View Event

Description:
oslc-op contributors weekly telecon. 


One tap audio Dial In: +15124022718,,,,2979764690# (US) or +498938038719,,,,2979764690# (Germany) Looking for a different dial in number? Please see: https://meet.jit.si/static/dialInInfo.html?room=oslc-op
Meeting ID: 2979764690#
 
The meeting minutes are edited in https://hackmd.io/@driib/oslc-op-minutes/edit
Previous minutes can be found under https://github.com/oslc-op/oslc-admin/tree/master/minutes/2019 

OASIS OSLC Open Project group home: https://lists.oasis-open-projects.org/g/oslc-op 
oslc-op GitHub Organization: https://github.com/oslc-op
Mailing list: oslc-op@... (archives: https://lists.oasis-open-projects.org/g/oslc-op)


OSLC Configuration Management v1.0 Project Specification 01 approved by the OSLC Open Project

Paul Knight
 

OASIS is pleased to announce that OSLC Configuration Management Version 1.0 from the Open Services for Lifecycle Collaboration Open Project [1] has been approved as an OASIS Project Specification.

Managing change and configuration in a complex systems development lifecycle is very difficult, especially in heterogeneous environments that include homegrown tools, open source projects, and commercial tools from different vendors. The OSLC initiative applies World Wide Web and Linked Data principles to enable interoperation of change, configuration, and asset management processes across a product's entire application and product lifecycle.

OSLC Configuration Management defines an RDF vocabulary and a set of REST APIs for managing versions and configurations of linked data resources from multiple domains.

This Project Specification is an OASIS deliverable, completed and approved by the OP's Project Governing Board and fully ready for testing and implementation. The applicable open source licenses can be found in the project's administrative repository at https://github.com/oslc-op/oslc-admin/blob/master/LICENSE.md.

The specification and related files are available at:

OSLC Configuration Management Version 1.0
Project Specification 01
30 May 2022

- OSLC Configuration Management Version 1.0. Part 1: Overview
https://docs.oasis-open-projects.org/oslc-op/config/v1.0/ps01/oslc-config-mgt.html
https://docs.oasis-open-projects.org/oslc-op/config/v1.0/ps01/oslc-config-mgt.pdf

- OSLC Configuration Management Version 1.0. Part 2: Versioned Resources
https://docs.oasis-open-projects.org/oslc-op/config/v1.0/ps01/versioned-resources.html
https://docs.oasis-open-projects.org/oslc-op/config/v1.0/ps01/versioned-resources.pdf

- OSLC Configuration Management Version 1.0. Part 3: Configuration Specification
https://docs.oasis-open-projects.org/oslc-op/config/v1.0/ps01/config-resources.html
https://docs.oasis-open-projects.org/oslc-op/config/v1.0/ps01/config-resources.pdf

- OSLC Configuration Management Version 1.0. Part 4: RDF Vocabulary
https://docs.oasis-open-projects.org/oslc-op/config/v1.0/ps01/config-vocab.html
https://docs.oasis-open-projects.org/oslc-op/config/v1.0/ps01/config-vocab.pdf

- OSLC Configuration Management machine readable "turtle" files:
Vocabulary Terms: https://docs.oasis-open-projects.org/oslc-op/config/v1.0/ps01/config-vocab.ttl
Vocabulary Constraints: https://docs.oasis-open-projects.org/oslc-op/config/v1.0/ps01/config-shapes.ttl

Distribution ZIP file

For your convenience, OASIS provides a complete package of the specification and related files in a ZIP distribution file. You can download the ZIP file at:
https://docs.oasis-open-projects.org/oslc-op/config/v1.0/ps01/config-v1.0-ps01.zip

Members of the OSLC OP Project Governing Board approved this specification by Special Majority Vote [2] as required by the Open Project rules [3].

Our congratulations to the participants and contributors in the Open Services for Lifecycle Collaboration Open Project on their achieving this milestone.

========== Additional references:

[1] Open Services for Lifecycle Collaboration Open Project
https://open-services.net/

[2] Approval ballot:
- https://lists.oasis-open-projects.org/g/oslc-op-pgb/message/239

[3] https://www.oasis-open.org/policies-guidelines/open-projects-process
--
OASIS...Setting the standard for open collaboration


Re: Now: oslc-op Weekly Contributors Meeting - 06/09/2022 #cal-notice

Andrii Berezovskyi
 

Minutes: https://github.com/oslc-op/oasis-open-project/blob/master/minutes/2022/2022-05-26.md

 

/Andrew

 

From: <oslc-op@...> on behalf of Group Notification <noreply@...>
Reply-To: "oslc-op@..." <oslc-op@...>, "noreply@..." <noreply@...>
Date: Thursday, 9 June 2022, W23 at 16:00
To: "oslc-op@..." <oslc-op@...>
Subject: [oslc-op] Now: oslc-op Weekly Contributors Meeting - 06/09/2022 #cal-notice

 

oslc-op Weekly Contributors Meeting

When:
06/09/2022
10:00am to 11:00am
(UTC-04:00) America/New York

Where:
https://meet.jit.si/oslc-op

Organizer: Jim Amsden jamsden@...

View Event

Description:
oslc-op contributors weekly telecon. 


One tap audio Dial In: +15124022718,,,,2979764690# (US) or +498938038719,,,,2979764690# (Germany) Looking for a different dial in number? Please see: https://meet.jit.si/static/dialInInfo.html?room=oslc-op

Meeting ID: 2979764690#

 

The meeting minutes are edited in https://hackmd.io/@driib/oslc-op-minutes/edit
Previous minutes can be found under https://github.com/oslc-op/oslc-admin/tree/master/minutes/2019 


OASIS OSLC Open Project group home: https://lists.oasis-open-projects.org/g/oslc-op 
oslc-op GitHub Organization: https://github.com/oslc-op
Mailing list: oslc-op@... (archives: https://lists.oasis-open-projects.org/g/oslc-op)


Re: Link profiles

Andrii Berezovskyi
 

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

 

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

 

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

 

Looking forward to your feedback.

 

/Andrew

 

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

 

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

I will look at this next week.

 

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

 

David

 

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

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

 

(See XL attachment to the original message)

 

Thanks

Eran

 

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

 

Hi David, all,

 

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

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

 

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

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

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

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

 

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

 

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

 

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

Can you please confirm its accuracy?

Hope this makes sense…

Regards,

Eran

 

 

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

 

Always trying to create both forward and back links seems like the wrong thing to do, even in opt-out mode. Servers are free to either silently ignore RDF properties it doesn’t support, or to fail the whole PUT if it contains an unsupported property. That could give rise to unpredictable behaviour.

 

An OSLC client may be able to discover which direction(s) are to be used. Consider a user wanting to create a validates requirement link between a test case and a requirement. There are two potential links (as defined by OSLC specs):

·         oslc_qm:validatesRequirement stored on the test case

·         oslc_rm:validatedBy stored on the requirement

 

A caller can GET the test case, look for its oslc:instanceShape, get that shape, and then look for the presence or absence of an OSLC property for oslc_qm:validatesRequirement. It can then GET the requirement, look for its oslc:instanceShape, get that shape, and then look for the presence or absence of an OSLC property for oslc_rm:validatedBy.

I wonder whether that’s sufficient to do the right thing for ELM and for other applications.

 

Thinking about the opt-in case….

Say you have requirement R1 version 1 (R1-1), and test case TC1 version 1 (TC1-1).
You update the test case in the context of some ETM stream, creating TC1-2 that has a
oslc_qm:validatesRequirement link to the concept R1. In order to create the back-link, you’d need to update R1-1 in the context of a DNG stream, to create R1-2. A caller won’t know which stream to use for that backlink, so the only way I can see this working is if this is done in a GC context. It also has the side-effect of creating a new version of both the source and the target. If someone looked at R1 in a GC context that resolved to R1-1, and resolved TC1 to TC1-2, you end up with an inconsistency. The oslc_rm:validatedBy link didn’t exist on R1-1, but the forward link to that requirement exists on TC1-2. I think these were the reasons why ELM decided for opt-in, there would be no backlinks.

 

David.

 

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

 

This is a good start, but we should understand how it supports the use cases and common practice.

 

On the issues we’ve been discussing on links: the OSLC specifications define vocabularies and shapes that specify links that would be reasonably considered inverses. Requirement validatedBy TestCase and TestCase validatesRquirement Requirement is one such example. However, OSLC does not specify which one is the property, which would be considered the inverse property, which or  “owed by” any particular server that supports RM and/or QM domains. Rather this is a server implementation decision, often driven by use cases/scenarios that support a particular work-flow – i.e., requirements vs. test driven develop in this case.

 

Fundamentally OSLC ResourceShape constraints have no way of indicating what a server expects to store vs. expects another server involved in a link relationship expects/can/has to store. So, implementations do what works for them and what is stored where must be documented outside OSLC discovery.

 

Added to that, OSLC delegated dialogs don’t establish a clear distinction between the requester and provider of the delegated dialog and who’s supposed to “own” the link – that is, which link property the pair of tools considers the actual source and target of the link, and whether the source or target resource will be the subject of the link property triple.

 

Jazz.net tools attempt to make this transparent, so the user doesn’t have to know which server is storing the link, or how the incoming links are stored or calculated. This is purely a usability issue. However, the participating servers do have to know because even through the creation of the link can be created from either direction, the servers must know which one stores it and implement the link creation accordingly. Again, there is no way to discover this.

 

We could expand ResourceShape to define inverse property constraints to provide a discoverable way for clients and servers to interoperate when creating links from either direction. I expect that might be a better approach than defining a number of profile special cases.

 

 

 

From: Andrii Berezovskyi <andriib@...>
Date: Thursday, May 26, 2022 at 11:49 AM
To: Eran Gery <
eran.gery@...>, David Honey2 <david.honey@...>, Jim Amsden <jamsden@...>, "e.gentry@..." <e.gentry@...>
Cc: "
oslc-op@..." <oslc-op@...>
Subject: [EXTERNAL] Link profiles

 

Hi, I put together a simple table for the possible profiles after the call: https://docs.google.com/spreadsheets/d/1fjjGvHrv2yPru8S_6HNoJ5atn6617cUfFUDRz5xAfKQ/edit?usp=sharing Please look at them and tell me what you think. Thanks to Eran

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Hi,

 

I put together a simple table for the possible profiles after the call: https://docs.google.com/spreadsheets/d/1fjjGvHrv2yPru8S_6HNoJ5atn6617cUfFUDRz5xAfKQ/edit?usp=sharing

 

Please look at them and tell me what you think. Thanks to Eran for taking extra time to explain some things to me.

 

/A

Unless otherwise stated above:

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


Now: oslc-op Weekly Contributors Meeting - 06/09/2022 #cal-notice

Group Notification <noreply@...>
 

oslc-op Weekly Contributors Meeting

When:
06/09/2022
10:00am to 11:00am
(UTC-04:00) America/New York

Where:
https://meet.jit.si/oslc-op

Organizer: Jim Amsden jamsden@...

View Event

Description:
oslc-op contributors weekly telecon. 


One tap audio Dial In: +15124022718,,,,2979764690# (US) or +498938038719,,,,2979764690# (Germany) Looking for a different dial in number? Please see: https://meet.jit.si/static/dialInInfo.html?room=oslc-op
Meeting ID: 2979764690#
 
The meeting minutes are edited in https://hackmd.io/@driib/oslc-op-minutes/edit
Previous minutes can be found under https://github.com/oslc-op/oslc-admin/tree/master/minutes/2019 

OASIS OSLC Open Project group home: https://lists.oasis-open-projects.org/g/oslc-op 
oslc-op GitHub Organization: https://github.com/oslc-op
Mailing list: oslc-op@... (archives: https://lists.oasis-open-projects.org/g/oslc-op)


OSLC PROMCODE v1.0 Errata 01 from the OSLC PROMCODE TC approved

Paul Knight
 

OASIS members and other interested parties,

We are pleased to announce that OSLC PROMCODE v1.0 Errata 01 from the OSLC PROMCODE TC is now an Approved Errata.

This document lists errata for the OASIS Standard "OSLC PROMCODE Version 1.0." As described in the document, there are no changes to the published textual documents of the OASIS Standard (Part 1: Specification, Part 2: Vocabulary, and Part 3: Constraints). Changes have been made only to the two machine-readable "turtle" files (promcode-vocab.ttl and promcode-shapes.ttl). As required by OASIS policy, these are not Material Changes. The modified "turtle" files are included in this publication.

OSLC PROMCODE Version 1.0 defines the overall approach to PROMCODE (PROject Management of COntracted DElivery) based on the Open Services for Lifecycle Collaboration (OSLC) Core 3.0 [OSLCCore3] Specification.

The documents and related files are available here:

OSLC PROMCODE Version 1.0 Errata 01
Approved Errata
03 June 2022

HTML:
https://docs.oasis-open.org/oslc-promcode/promcode/v1.0/errata01/os/promcode-v1.0-errata01-os.html (Authoritative)
PDF:
https://docs.oasis-open.org/oslc-promcode/promcode/v1.0/errata01/os/promcode-v1.0-errata01-os.pdf

Machine-readable files
Vocabulary terms: https://docs.oasis-open.org/oslc-promcode/promcode/v1.0/errata01/os/promcode-vocab.ttl
Constraints: https://docs.oasis-open.org/oslc-promcode/promcode/v1.0/errata01/os/promcode-shapes.ttl

For your convenience, OASIS provides a complete package of the specification document and any related files in ZIP distribution files. You can download the ZIP file at:
https://docs.oasis-open.org/oslc-promcode/promcode/v1.0/errata01/os/promcode-v1.0-errata01-os.zip

Members of the OSLC PROMCODE TC approved Errata 01 by Full Majority Vote. The specification had been released for public review as required by the TC Process [2]. The vote to approve as Approved Errata passed [3], and the document is now available online in the OASIS Library as referenced above.

Our congratulations to the TC on achieving this milestone and our thanks to the reviewers who provided feedback on the specification drafts to help improve the quality of the work.

Additional information about the specification and the OSLC PROMCODE TC can be found at the TC's public home page:
https://www.oasis-open.org/committees/oslc-promcode/

========== Additional references:

[1] OASIS OSLC Lifecycle Integration for Project Management of Contracted Delivery (OSLC PROMCODE) TC
https://www.oasis-open.org/committees/oslc-promcode/

[2] Public review:
* 15-day public review began 19 May 2022
Announcement email: https://lists.oasis-open.org/archives/members/202205/msg00004.html
https://docs.oasis-open.org/oslc-promcode/promcode/v1.0/errata01/csd01/promcode-v1.0-errata01-csd01-public-review-metadata.html

[3] Meeting minutes:
https://wiki.oasis-open.org/oslc-promcode/telecon%20June%203%2C%202022
--
OASIS...Setting the standard for open collaboration


Preparing PS01 files (was: Your ballot to approve Configuration Management v1.0 as a PS has passed)

Paul Knight
 

Hi all,

As usual, we will rely on the OSLC OP team to prepare the PS01 HTML and TTL files for Configuration Management v1.0. I will provide quality review as needed and handle preparation of the PDF format files and other publication tasks.

Chet noted that the work is being tracked in https://issues.oasis-open.org/browse/TCADMIN-4198, and I will monitor the ticket for any updates.

Of course, please feel free to contact me or Chet directly with any questions, as we make your approved Project Specification available in the OASIS OP Library.

Best regards,
Paul

On Tue, May 31, 2022 at 5:26 PM Chet Ensign <chet.ensign@...> wrote:
Participants in the OSLC Open Project, 


The ballot to approve OSLC Configuration Management Version 1.0 PSD01 as a Project Specification, found in https://lists.oasis-open-projects.org/g/oslc-op-pgb/message/239, closed on 30 May 2022. The ballot passed.

Project Admin will now work with you to get the Project Spec published. TC Admin JIRA ticket https://issues.oasis-open.org/browse/TCADMIN-4198
has been opened to track the work. Feel free to follow the ticket and post questions or updates to it. 

And congratulations on another  milestone for the OSLC Open Project! 

Best regards, 

/chet


--

Chet Ensign

Chief Technical Community Steward

OASIS Open

   
+1 201-341-1393
chet.ensign@...
www.oasis-open.org


--
OASIS...Setting the standard for open collaboration


Now: oslc-op Weekly Contributors Meeting - 06/02/2022 #cal-notice

Group Notification <noreply@...>
 

oslc-op Weekly Contributors Meeting

When:
06/02/2022
10:00am to 11:00am
(UTC-04:00) America/New York

Where:
https://meet.jit.si/oslc-op

Organizer: Jim Amsden jamsden@...

View Event

Description:
oslc-op contributors weekly telecon. 


One tap audio Dial In: +15124022718,,,,2979764690# (US) or +498938038719,,,,2979764690# (Germany) Looking for a different dial in number? Please see: https://meet.jit.si/static/dialInInfo.html?room=oslc-op
Meeting ID: 2979764690#
 
The meeting minutes are edited in https://hackmd.io/@driib/oslc-op-minutes/edit
Previous minutes can be found under https://github.com/oslc-op/oslc-admin/tree/master/minutes/2019 

OASIS OSLC Open Project group home: https://lists.oasis-open-projects.org/g/oslc-op 
oslc-op GitHub Organization: https://github.com/oslc-op
Mailing list: oslc-op@... (archives: https://lists.oasis-open-projects.org/g/oslc-op)


Re: Regrets

Jad El-Khoury
 

hi

I will also be away today.

 

______________________________

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 Andrii Berezovskyi
Sent: Tuesday, 31 May 2022 17:06
To: oslc-op@...
Subject: [oslc-op] Regrets

 

Hi,

 

I will attend an off-site project meeting on Thursday and won’t be able to join the OP call. Please make sure to have someone take minutes.

 

/Andrew


Re: Link profiles

David Honey2
 

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

I will look at this next week.

 

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

 

David

 

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

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

 

(See XL attachment to the original message)

 

Thanks

Eran

 

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

 

Hi David, all,

 

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

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

 

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

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

 

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

 

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

 

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

Can you please confirm its accuracy?

Hope this makes sense…

Regards,

Eran

 

 

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

 

Always trying to create both forward and back links seems like the wrong thing to do, even in opt-out mode. Servers are free to either silently ignore RDF properties it doesn’t support, or to fail the whole PUT if it contains an unsupported property. That could give rise to unpredictable behaviour.

 

An OSLC client may be able to discover which direction(s) are to be used. Consider a user wanting to create a validates requirement link between a test case and a requirement. There are two potential links (as defined by OSLC specs):

  • oslc_qm:validatesRequirement stored on the test case
  • oslc_rm:validatedBy stored on the requirement

 

A caller can GET the test case, look for its oslc:instanceShape, get that shape, and then look for the presence or absence of an OSLC property for oslc_qm:validatesRequirement. It can then GET the requirement, look for its oslc:instanceShape, get that shape, and then look for the presence or absence of an OSLC property for oslc_rm:validatedBy.

I wonder whether that’s sufficient to do the right thing for ELM and for other applications.

 

Thinking about the opt-in case….

Say you have requirement R1 version 1 (R1-1), and test case TC1 version 1 (TC1-1).
You update the test case in the context of some ETM stream, creating TC1-2 that has a
oslc_qm:validatesRequirement link to the concept R1. In order to create the back-link, you’d need to update R1-1 in the context of a DNG stream, to create R1-2. A caller won’t know which stream to use for that backlink, so the only way I can see this working is if this is done in a GC context. It also has the side-effect of creating a new version of both the source and the target. If someone looked at R1 in a GC context that resolved to R1-1, and resolved TC1 to TC1-2, you end up with an inconsistency. The oslc_rm:validatedBy link didn’t exist on R1-1, but the forward link to that requirement exists on TC1-2. I think these were the reasons why ELM decided for opt-in, there would be no backlinks.

 

David.

 

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

 

This is a good start, but we should understand how it supports the use cases and common practice.

 

On the issues we’ve been discussing on links: the OSLC specifications define vocabularies and shapes that specify links that would be reasonably considered inverses. Requirement validatedBy TestCase and TestCase validatesRquirement Requirement is one such example. However, OSLC does not specify which one is the property, which would be considered the inverse property, which or  “owed by” any particular server that supports RM and/or QM domains. Rather this is a server implementation decision, often driven by use cases/scenarios that support a particular work-flow – i.e., requirements vs. test driven develop in this case.

 

Fundamentally OSLC ResourceShape constraints have no way of indicating what a server expects to store vs. expects another server involved in a link relationship expects/can/has to store. So, implementations do what works for them and what is stored where must be documented outside OSLC discovery.

 

Added to that, OSLC delegated dialogs don’t establish a clear distinction between the requester and provider of the delegated dialog and who’s supposed to “own” the link – that is, which link property the pair of tools considers the actual source and target of the link, and whether the source or target resource will be the subject of the link property triple.

 

Jazz.net tools attempt to make this transparent, so the user doesn’t have to know which server is storing the link, or how the incoming links are stored or calculated. This is purely a usability issue. However, the participating servers do have to know because even through the creation of the link can be created from either direction, the servers must know which one stores it and implement the link creation accordingly. Again, there is no way to discover this.

 

We could expand ResourceShape to define inverse property constraints to provide a discoverable way for clients and servers to interoperate when creating links from either direction. I expect that might be a better approach than defining a number of profile special cases.

 

 

 

From: Andrii Berezovskyi <andriib@...>
Date: Thursday, May 26, 2022 at 11:49 AM
To: Eran Gery <
eran.gery@...>, David Honey2 <david.honey@...>, Jim Amsden <jamsden@...>, "e.gentry@..." <e.gentry@...>
Cc: "
oslc-op@..." <oslc-op@...>
Subject: [EXTERNAL] Link profiles

 

Hi, I put together a simple table for the possible profiles after the call: https://docs.google.com/spreadsheets/d/1fjjGvHrv2yPru8S_6HNoJ5atn6617cUfFUDRz5xAfKQ/edit?usp=sharing Please look at them and tell me what you think. Thanks to Eran

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Hi,

 

I put together a simple table for the possible profiles after the call: https://docs.google.com/spreadsheets/d/1fjjGvHrv2yPru8S_6HNoJ5atn6617cUfFUDRz5xAfKQ/edit?usp=sharing

 

Please look at them and tell me what you think. Thanks to Eran for taking extra time to explain some things to me.

 

/A

Unless otherwise stated above:

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


Re: Link profiles

"Eran Gery"
 

David

 

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

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

 

(See XL attachment to the original message)

 

Thanks

Eran

 

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

 

Hi David, all,

 

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

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

 

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

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

 

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

 

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

 

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

Can you please confirm its accuracy?

Hope this makes sense…

Regards,

Eran

 

 

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

 

Always trying to create both forward and back links seems like the wrong thing to do, even in opt-out mode. Servers are free to either silently ignore RDF properties it doesn’t support, or to fail the whole PUT if it contains an unsupported property. That could give rise to unpredictable behaviour.

 

An OSLC client may be able to discover which direction(s) are to be used. Consider a user wanting to create a validates requirement link between a test case and a requirement. There are two potential links (as defined by OSLC specs):

  • oslc_qm:validatesRequirement stored on the test case
  • oslc_rm:validatedBy stored on the requirement

 

A caller can GET the test case, look for its oslc:instanceShape, get that shape, and then look for the presence or absence of an OSLC property for oslc_qm:validatesRequirement. It can then GET the requirement, look for its oslc:instanceShape, get that shape, and then look for the presence or absence of an OSLC property for oslc_rm:validatedBy.

I wonder whether that’s sufficient to do the right thing for ELM and for other applications.

 

Thinking about the opt-in case….

Say you have requirement R1 version 1 (R1-1), and test case TC1 version 1 (TC1-1).
You update the test case in the context of some ETM stream, creating TC1-2 that has a
oslc_qm:validatesRequirement link to the concept R1. In order to create the back-link, you’d need to update R1-1 in the context of a DNG stream, to create R1-2. A caller won’t know which stream to use for that backlink, so the only way I can see this working is if this is done in a GC context. It also has the side-effect of creating a new version of both the source and the target. If someone looked at R1 in a GC context that resolved to R1-1, and resolved TC1 to TC1-2, you end up with an inconsistency. The oslc_rm:validatedBy link didn’t exist on R1-1, but the forward link to that requirement exists on TC1-2. I think these were the reasons why ELM decided for opt-in, there would be no backlinks.

 

David.

 

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

 

This is a good start, but we should understand how it supports the use cases and common practice.

 

On the issues we’ve been discussing on links: the OSLC specifications define vocabularies and shapes that specify links that would be reasonably considered inverses. Requirement validatedBy TestCase and TestCase validatesRquirement Requirement is one such example. However, OSLC does not specify which one is the property, which would be considered the inverse property, which or  “owed by” any particular server that supports RM and/or QM domains. Rather this is a server implementation decision, often driven by use cases/scenarios that support a particular work-flow – i.e., requirements vs. test driven develop in this case.

 

Fundamentally OSLC ResourceShape constraints have no way of indicating what a server expects to store vs. expects another server involved in a link relationship expects/can/has to store. So, implementations do what works for them and what is stored where must be documented outside OSLC discovery.

 

Added to that, OSLC delegated dialogs don’t establish a clear distinction between the requester and provider of the delegated dialog and who’s supposed to “own” the link – that is, which link property the pair of tools considers the actual source and target of the link, and whether the source or target resource will be the subject of the link property triple.

 

Jazz.net tools attempt to make this transparent, so the user doesn’t have to know which server is storing the link, or how the incoming links are stored or calculated. This is purely a usability issue. However, the participating servers do have to know because even through the creation of the link can be created from either direction, the servers must know which one stores it and implement the link creation accordingly. Again, there is no way to discover this.

 

We could expand ResourceShape to define inverse property constraints to provide a discoverable way for clients and servers to interoperate when creating links from either direction. I expect that might be a better approach than defining a number of profile special cases.

 

 

 

From: Andrii Berezovskyi <andriib@...>
Date: Thursday, May 26, 2022 at 11:49 AM
To: Eran Gery <
eran.gery@...>, David Honey2 <david.honey@...>, Jim Amsden <jamsden@...>, "e.gentry@..." <e.gentry@...>
Cc: "
oslc-op@..." <oslc-op@...>
Subject: [EXTERNAL] Link profiles

 

Hi, I put together a simple table for the possible profiles after the call: https://docs.google.com/spreadsheets/d/1fjjGvHrv2yPru8S_6HNoJ5atn6617cUfFUDRz5xAfKQ/edit?usp=sharing Please look at them and tell me what you think. Thanks to Eran

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Hi,

 

I put together a simple table for the possible profiles after the call: https://docs.google.com/spreadsheets/d/1fjjGvHrv2yPru8S_6HNoJ5atn6617cUfFUDRz5xAfKQ/edit?usp=sharing

 

Please look at them and tell me what you think. Thanks to Eran for taking extra time to explain some things to me.

 

/A


Your ballot to approve Configuration Management v1.0 as a PS has passed

Chet Ensign
 

Participants in the OSLC Open Project, 


The ballot to approve OSLC Configuration Management Version 1.0 PSD01 as a Project Specification, found in https://lists.oasis-open-projects.org/g/oslc-op-pgb/message/239, closed on 30 May 2022. The ballot passed.

Project Admin will now work with you to get the Project Spec published. TC Admin JIRA ticket https://issues.oasis-open.org/browse/TCADMIN-4198
has been opened to track the work. Feel free to follow the ticket and post questions or updates to it. 

And congratulations on another  milestone for the OSLC Open Project! 

Best regards, 

/chet


--

Chet Ensign

Chief Technical Community Steward

OASIS Open

   
+1 201-341-1393
chet.ensign@...
www.oasis-open.org

81 - 100 of 948