A mechanism to map(?) between configurations and effectivity


Andrii Berezovskyi
 

Hi Jim,

 

Closer to the end of the call, you suggested that adding support for effectivity or doing some other effort of fully reconciling the product/STEP way of versioning based on effectivity and the OSLC was based on configurations is not a good idea. Unfortunately, I didn’t fully get your idea. Could you please repeat your idea here because, regretfully, I didn’t grasp it properly?

 

/Andrew


Jim Amsden
 

Andrew,

Really good to hear from you, we miss you!

 

I think you misunderstood. I think if the PLM community needs to explicitly expose Part and PartVersion artifacts and the notion of effectivity into their domain model, as extensions to am:Resource, that’s fine, even if it overlaps with OSLC Configuration Management in some aspects.

 

What I don’t think is a good idea is commingling product definition/BOM with configuration contribution. That is, a Part and a PartVersion isa am:Resource, not config:Configuration. This keeps separate the notions of decomposition of things from decompositions of contributions that select versions of things. Part/PartVersion tempts us to explore this, but there may be better approaches that have less conceptual coupling.

 

But in any case, this is a good area for us to explore.

 

 

From: <oslc-op@...> on behalf of Andrii Berezovskyi <andriib@...>
Reply-To: "oslc-op@..." <oslc-op@...>, "andriib@..." <andriib@...>
Date: Wednesday, January 18, 2023 at 10:23 AM
To: "oslc-op@..." <oslc-op@...>
Subject: [EXTERNAL] [oslc-op] A mechanism to map(?) between configurations and effectivity

 

Hi Jim, Closer to the end of the call, you suggested that adding support for effectivity or doing some other effort of fully reconciling the product/STEP way of versioning based on effectivity and the OSLC was based on configurations is not

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Hi Jim,

 

Closer to the end of the call, you suggested that adding support for effectivity or doing some other effort of fully reconciling the product/STEP way of versioning based on effectivity and the OSLC was based on configurations is not a good idea. Unfortunately, I didn’t fully get your idea. Could you please repeat your idea here because, regretfully, I didn’t grasp it properly?

 

/Andrew


David Honey2
 

Currently the OSLC Configuration Management specification defines explicit representation of selections.
A configuration may reference zero, one, or many
oslc_config:Selections resources, each of which may specify zero, one or many oslc_config:selects statements. This representation is required to allow consumers of that data, such as an RDF indexer application such as IBM’s Lifecycle Query Engine, to know what version artifacts are selected by a specific configuration. In turn, this underpins the ability for the LinkIndexService to find incoming links in a specified configuration context (often a global configuration), and for Report Builder to report against versioned artifacts in such a configuration context, showing the right versions of concept resources in the report results.

 

If you choose some other representation of selections to address the issue of effectivity, then this compromises discovery of incoming links and reporting of version artifacts. The current specification would require that as the effectivity of a configuration changes, and you want other tools to be able to reflect that, then you must publish TRS modification events for the affected selections resources, and a the RDF content of those selections resources must represent the effective set of selected version artifacts at that point in time, and the reference version artifacts should also be tracked resources.

 

Another way of expressing this is that you need a mechanism for some other tool (e.g. LQE, LDX) to be able to determine the set of selected versions rather than this being solely available within the data owning tool.

 

Best regards,
David

 

 

From: oslc-op@... <oslc-op@...> On Behalf Of Jim Amsden
Sent: 18 January 2023 19:02
To: oslc-op@...; andriib@...
Subject: [EXTERNAL] Re: [oslc-op] A mechanism to map(?) between configurations and effectivity

 

Andrew, Really good to hear from you, we miss you! I think you misunderstood. I think if the PLM community needs to explicitly expose Part and PartVersion artifacts and the notion of effectivity into their domain model, as extensions to am: Resource,

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Andrew,

Really good to hear from you, we miss you!

 

I think you misunderstood. I think if the PLM community needs to explicitly expose Part and PartVersion artifacts and the notion of effectivity into their domain model, as extensions to am:Resource, that’s fine, even if it overlaps with OSLC Configuration Management in some aspects.

 

What I don’t think is a good idea is commingling product definition/BOM with configuration contribution. That is, a Part and a PartVersion isa am:Resource, not config:Configuration. This keeps separate the notions of decomposition of things from decompositions of contributions that select versions of things. Part/PartVersion tempts us to explore this, but there may be better approaches that have less conceptual coupling.

 

But in any case, this is a good area for us to explore.

 

 

From: <oslc-op@...> on behalf of Andrii Berezovskyi <andriib@...>
Reply-To: "oslc-op@..." <oslc-op@...>, "andriib@..." <andriib@...>
Date: Wednesday, January 18, 2023 at 10:23 AM
To: "oslc-op@..." <oslc-op@...>
Subject: [EXTERNAL] [oslc-op] A mechanism to map(?) between configurations and effectivity

 

Hi Jim, Closer to the end of the call, you suggested that adding support for effectivity or doing some other effort of fully reconciling the product/STEP way of versioning based on effectivity and the OSLC was based on configurations is not

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Hi Jim,

 

Closer to the end of the call, you suggested that adding support for effectivity or doing some other effort of fully reconciling the product/STEP way of versioning based on effectivity and the OSLC was based on configurations is not a good idea. Unfortunately, I didn’t fully get your idea. Could you please repeat your idea here because, regretfully, I didn’t grasp it properly?

 

/Andrew

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
 

Is there a chance there is a recording of yesterday’s session?

 

______________________________

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 David Honey2 via lists.oasis-open-projects.org
Sent: Wednesday, 18 January 2023 20:18
To: oslc-op@...; Jim Amsden <jamsden@...>; Andrii Berezovskyi <andriib@...>
Subject: Re: [oslc-op] A mechanism to map(?) between configurations and effectivity

 

Currently the OSLC Configuration Management specification defines explicit representation of selections.
A configuration may reference zero, one, or many
oslc_config:Selections resources, each of which may specify zero, one or many oslc_config:selects statements. This representation is required to allow consumers of that data, such as an RDF indexer application such as IBM’s Lifecycle Query Engine, to know what version artifacts are selected by a specific configuration. In turn, this underpins the ability for the LinkIndexService to find incoming links in a specified configuration context (often a global configuration), and for Report Builder to report against versioned artifacts in such a configuration context, showing the right versions of concept resources in the report results.

 

If you choose some other representation of selections to address the issue of effectivity, then this compromises discovery of incoming links and reporting of version artifacts. The current specification would require that as the effectivity of a configuration changes, and you want other tools to be able to reflect that, then you must publish TRS modification events for the affected selections resources, and a the RDF content of those selections resources must represent the effective set of selected version artifacts at that point in time, and the reference version artifacts should also be tracked resources.

 

Another way of expressing this is that you need a mechanism for some other tool (e.g. LQE, LDX) to be able to determine the set of selected versions rather than this being solely available within the data owning tool.

 

Best regards,
David

 

 

From: oslc-op@... <oslc-op@...> On Behalf Of Jim Amsden
Sent: 18 January 2023 19:02
To: oslc-op@...; andriib@...
Subject: [EXTERNAL] Re: [oslc-op] A mechanism to map(?) between configurations and effectivity

 

Andrew, Really good to hear from you, we miss you! I think you misunderstood. I think if the PLM community needs to explicitly expose Part and PartVersion artifacts and the notion of effectivity into their domain model, as extensions to am: Resource,

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Andrew,

Really good to hear from you, we miss you!

 

I think you misunderstood. I think if the PLM community needs to explicitly expose Part and PartVersion artifacts and the notion of effectivity into their domain model, as extensions to am:Resource, that’s fine, even if it overlaps with OSLC Configuration Management in some aspects.

 

What I don’t think is a good idea is commingling product definition/BOM with configuration contribution. That is, a Part and a PartVersion isa am:Resource, not config:Configuration. This keeps separate the notions of decomposition of things from decompositions of contributions that select versions of things. Part/PartVersion tempts us to explore this, but there may be better approaches that have less conceptual coupling.

 

But in any case, this is a good area for us to explore.

 

 

From: <oslc-op@...> on behalf of Andrii Berezovskyi <andriib@...>
Reply-To: "oslc-op@..." <oslc-op@...>, "andriib@..." <andriib@...>
Date: Wednesday, January 18, 2023 at 10:23 AM
To: "oslc-op@..." <oslc-op@...>
Subject: [EXTERNAL] [oslc-op] A mechanism to map(?) between configurations and effectivity

 

Hi Jim, Closer to the end of the call, you suggested that adding support for effectivity or doing some other effort of fully reconciling the product/STEP way of versioning based on effectivity and the OSLC was based on configurations is not

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Hi Jim,

 

Closer to the end of the call, you suggested that adding support for effectivity or doing some other effort of fully reconciling the product/STEP way of versioning based on effectivity and the OSLC was based on configurations is not a good idea. Unfortunately, I didn’t fully get your idea. Could you please repeat your idea here because, regretfully, I didn’t grasp it properly?

 

/Andrew

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
 

I’d be interested in such recording(s). Unfortunately, the meetings have thus far been scheduled so they conflict with another meeting that I need to attend, so I have been unable to join any of them. Which makes it harder for me to contribute to discussions around OSLC configuration management.

 

From: oslc-op@... <oslc-op@...> On Behalf Of Jad El-Khoury
Sent: 19 January 2023 09:24
To: oslc-op@...
Subject: [EXTERNAL] Re: [oslc-op] A mechanism to map(?) between configurations and effectivity

 

Is there a chance there is a recording of yesterday’s session? ______________________________ Jad El-khoury, PhD KTH Royal Institute of Technology School of Industrial Engineering and Management, Mechatronics Division Brinellvägen 83, SE-100

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Is there a chance there is a recording of yesterday’s session?

 

______________________________

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 David Honey2 via lists.oasis-open-projects.org
Sent: Wednesday, 18 January 2023 20:18
To: oslc-op@...; Jim Amsden <jamsden@...>; Andrii Berezovskyi <andriib@...>
Subject: Re: [oslc-op] A mechanism to map(?) between configurations and effectivity

 

Currently the OSLC Configuration Management specification defines explicit representation of selections.
A configuration may reference zero, one, or many
oslc_config:Selections resources, each of which may specify zero, one or many oslc_config:selects statements. This representation is required to allow consumers of that data, such as an RDF indexer application such as IBM’s Lifecycle Query Engine, to know what version artifacts are selected by a specific configuration. In turn, this underpins the ability for the LinkIndexService to find incoming links in a specified configuration context (often a global configuration), and for Report Builder to report against versioned artifacts in such a configuration context, showing the right versions of concept resources in the report results.

 

If you choose some other representation of selections to address the issue of effectivity, then this compromises discovery of incoming links and reporting of version artifacts. The current specification would require that as the effectivity of a configuration changes, and you want other tools to be able to reflect that, then you must publish TRS modification events for the affected selections resources, and a the RDF content of those selections resources must represent the effective set of selected version artifacts at that point in time, and the reference version artifacts should also be tracked resources.

 

Another way of expressing this is that you need a mechanism for some other tool (e.g. LQE, LDX) to be able to determine the set of selected versions rather than this being solely available within the data owning tool.

 

Best regards,
David

 

 

From: oslc-op@... <oslc-op@...> On Behalf Of Jim Amsden
Sent: 18 January 2023 19:02
To: oslc-op@...; andriib@...
Subject: [EXTERNAL] Re: [oslc-op] A mechanism to map(?) between configurations and effectivity

 

Andrew, Really good to hear from you, we miss you! I think you misunderstood. I think if the PLM community needs to explicitly expose Part and PartVersion artifacts and the notion of effectivity into their domain model, as extensions to am: Resource,

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Andrew,

Really good to hear from you, we miss you!

 

I think you misunderstood. I think if the PLM community needs to explicitly expose Part and PartVersion artifacts and the notion of effectivity into their domain model, as extensions to am:Resource, that’s fine, even if it overlaps with OSLC Configuration Management in some aspects.

 

What I don’t think is a good idea is commingling product definition/BOM with configuration contribution. That is, a Part and a PartVersion isa am:Resource, not config:Configuration. This keeps separate the notions of decomposition of things from decompositions of contributions that select versions of things. Part/PartVersion tempts us to explore this, but there may be better approaches that have less conceptual coupling.

 

But in any case, this is a good area for us to explore.

 

 

From: <oslc-op@...> on behalf of Andrii Berezovskyi <andriib@...>
Reply-To: "oslc-op@..." <oslc-op@...>, "andriib@..." <andriib@...>
Date: Wednesday, January 18, 2023 at 10:23 AM
To: "oslc-op@..." <oslc-op@...>
Subject: [EXTERNAL] [oslc-op] A mechanism to map(?) between configurations and effectivity

 

Hi Jim, Closer to the end of the call, you suggested that adding support for effectivity or doing some other effort of fully reconciling the product/STEP way of versioning based on effectivity and the OSLC was based on configurations is not

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Hi Jim,

 

Closer to the end of the call, you suggested that adding support for effectivity or doing some other effort of fully reconciling the product/STEP way of versioning based on effectivity and the OSLC was based on configurations is not a good idea. Unfortunately, I didn’t fully get your idea. Could you please repeat your idea here because, regretfully, I didn’t grasp it properly?

 

/Andrew

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


Jad El-Khoury
 

I am also unfortunately blocked on Wednesdays.

We are starting a national research project with direct relation to this same topic. So I do hope I can get others to join also/instead.

______________________________

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, 19 January 2023 10:27
To: oslc-op@...; Jad El-Khoury <jad@...>
Subject: RE: [oslc-op] A mechanism to map(?) between configurations and effectivity

 

I’d be interested in such recording(s). Unfortunately, the meetings have thus far been scheduled so they conflict with another meeting that I need to attend, so I have been unable to join any of them. Which makes it harder for me to contribute to discussions around OSLC configuration management.

 

From: oslc-op@... <oslc-op@...> On Behalf Of Jad El-Khoury
Sent: 19 January 2023 09:24
To: oslc-op@...
Subject: [EXTERNAL] Re: [oslc-op] A mechanism to map(?) between configurations and effectivity

 

Is there a chance there is a recording of yesterday’s session? ______________________________ Jad El-khoury, PhD KTH Royal Institute of Technology School of Industrial Engineering and Management, Mechatronics Division Brinellvägen 83, SE-100

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Is there a chance there is a recording of yesterday’s session?

 

______________________________

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 David Honey2 via lists.oasis-open-projects.org
Sent: Wednesday, 18 January 2023 20:18
To: oslc-op@...; Jim Amsden <jamsden@...>; Andrii Berezovskyi <andriib@...>
Subject: Re: [oslc-op] A mechanism to map(?) between configurations and effectivity

 

Currently the OSLC Configuration Management specification defines explicit representation of selections.
A configuration may reference zero, one, or many
oslc_config:Selections resources, each of which may specify zero, one or many oslc_config:selects statements. This representation is required to allow consumers of that data, such as an RDF indexer application such as IBM’s Lifecycle Query Engine, to know what version artifacts are selected by a specific configuration. In turn, this underpins the ability for the LinkIndexService to find incoming links in a specified configuration context (often a global configuration), and for Report Builder to report against versioned artifacts in such a configuration context, showing the right versions of concept resources in the report results.

 

If you choose some other representation of selections to address the issue of effectivity, then this compromises discovery of incoming links and reporting of version artifacts. The current specification would require that as the effectivity of a configuration changes, and you want other tools to be able to reflect that, then you must publish TRS modification events for the affected selections resources, and a the RDF content of those selections resources must represent the effective set of selected version artifacts at that point in time, and the reference version artifacts should also be tracked resources.

 

Another way of expressing this is that you need a mechanism for some other tool (e.g. LQE, LDX) to be able to determine the set of selected versions rather than this being solely available within the data owning tool.

 

Best regards,
David

 

 

From: oslc-op@... <oslc-op@...> On Behalf Of Jim Amsden
Sent: 18 January 2023 19:02
To: oslc-op@...; andriib@...
Subject: [EXTERNAL] Re: [oslc-op] A mechanism to map(?) between configurations and effectivity

 

Andrew, Really good to hear from you, we miss you! I think you misunderstood. I think if the PLM community needs to explicitly expose Part and PartVersion artifacts and the notion of effectivity into their domain model, as extensions to am: Resource,

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Andrew,

Really good to hear from you, we miss you!

 

I think you misunderstood. I think if the PLM community needs to explicitly expose Part and PartVersion artifacts and the notion of effectivity into their domain model, as extensions to am:Resource, that’s fine, even if it overlaps with OSLC Configuration Management in some aspects.

 

What I don’t think is a good idea is commingling product definition/BOM with configuration contribution. That is, a Part and a PartVersion isa am:Resource, not config:Configuration. This keeps separate the notions of decomposition of things from decompositions of contributions that select versions of things. Part/PartVersion tempts us to explore this, but there may be better approaches that have less conceptual coupling.

 

But in any case, this is a good area for us to explore.

 

 

From: <oslc-op@...> on behalf of Andrii Berezovskyi <andriib@...>
Reply-To: "oslc-op@..." <oslc-op@...>, "andriib@..." <andriib@...>
Date: Wednesday, January 18, 2023 at 10:23 AM
To: "oslc-op@..." <oslc-op@...>
Subject: [EXTERNAL] [oslc-op] A mechanism to map(?) between configurations and effectivity

 

Hi Jim, Closer to the end of the call, you suggested that adding support for effectivity or doing some other effort of fully reconciling the product/STEP way of versioning based on effectivity and the OSLC was based on configurations is not

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Hi Jim,

 

Closer to the end of the call, you suggested that adding support for effectivity or doing some other effort of fully reconciling the product/STEP way of versioning based on effectivity and the OSLC was based on configurations is not a good idea. Unfortunately, I didn’t fully get your idea. Could you please repeat your idea here because, regretfully, I didn’t grasp it properly?

 

/Andrew

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


Ulrich Martin (BD/PLM5)
 

Hi,

 

I was hesitating to jump into the discussion, as I felt there are so many different topics discussed. Therefore I was wondering how to structure the topics.

 

Please find a proposal attached, which is based on capabilities.

 

At Bosch we design the business architecture based on capabilities according to ToGAF.

 

In addition I tried to map the standards with the capabilities.

 

I would have proposed to present it in today’s meeting. As it was cancelled I circulate the info upfront.

 

 

Mit freundlichen Grüßen / Best regards

Martin Ulrich


IoT Engineering Digital Realities, Collaboration and Engineering Simulation (BD/PLM5)
Robert Bosch GmbH | Postfach 30 02 20 | 70442 Stuttgart | GERMANY |
www.bosch.com
Tel.
+49 711 811-30414 | Mobil +49 152 28822142 | Telefax +49 711 811-5181990 | Martin.Ulrich@...

Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart, HRB 14000;
Aufsichtsratsvorsitzender: Prof. Dr. Stefan Asenkerschbaumer; Geschäftsführung: Dr. Stefan Hartung,
Dr. Christian Fischer, Filiz Albrecht, Dr. Markus Forschner, Dr. Markus Heyn, Dr. Tanja Rückert

Von: oslc-op@... <oslc-op@...> Im Auftrag von Jim Amsden via lists.oasis-open-projects.org
Gesendet: Mittwoch, 18. Januar 2023 20:02
An: oslc-op@...; andriib@...
Betreff: Re: [oslc-op] A mechanism to map(?) between configurations and effectivity

 

Andrew,

Really good to hear from you, we miss you!

 

I think you misunderstood. I think if the PLM community needs to explicitly expose Part and PartVersion artifacts and the notion of effectivity into their domain model, as extensions to am:Resource, that’s fine, even if it overlaps with OSLC Configuration Management in some aspects.

 

What I don’t think is a good idea is commingling product definition/BOM with configuration contribution. That is, a Part and a PartVersion isa am:Resource, not config:Configuration. This keeps separate the notions of decomposition of things from decompositions of contributions that select versions of things. Part/PartVersion tempts us to explore this, but there may be better approaches that have less conceptual coupling.

 

But in any case, this is a good area for us to explore.

 

 

From: <oslc-op@...> on behalf of Andrii Berezovskyi <andriib@...>
Reply-To: "oslc-op@..." <oslc-op@...>, "andriib@..." <andriib@...>
Date: Wednesday, January 18, 2023 at 10:23 AM
To: "oslc-op@..." <oslc-op@...>
Subject: [EXTERNAL] [oslc-op] A mechanism to map(?) between configurations and effectivity

 

Hi Jim, Closer to the end of the call, you suggested that adding support for effectivity or doing some other effort of fully reconciling the product/STEP way of versioning based on effectivity and the OSLC was based on configurations is not

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Hi Jim,

 

Closer to the end of the call, you suggested that adding support for effectivity or doing some other effort of fully reconciling the product/STEP way of versioning based on effectivity and the OSLC was based on configurations is not a good idea. Unfortunately, I didn’t fully get your idea. Could you please repeat your idea here because, regretfully, I didn’t grasp it properly?

 

/Andrew


Ulrich Martin (BD/PLM5)
 

Hi David,

 

thank you - you opened my eyes.

 

I was always wandering what the purpose of the concept of selections is.

 

The purpose is missing in the standard.

 

 

Mit freundlichen Grüßen / Best regards

Martin Ulrich


IoT Engineering Digital Realities, Collaboration and Engineering Simulation (BD/PLM5)
Robert Bosch GmbH | Postfach 30 02 20 | 70442 Stuttgart | GERMANY | www.bosch.com
Tel. +49 711 811-30414 | Mobil +49 152 28822142 | Telefax +49 711 811-5181990 | Martin.Ulrich@...


Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart, HRB 14000;
Aufsichtsratsvorsitzender: Prof. Dr. Stefan Asenkerschbaumer; Geschäftsführung: Dr. Stefan Hartung,
Dr. Christian Fischer, Filiz Albrecht, Dr. Markus Forschner, Dr. Markus Heyn, Dr. Tanja Rückert

Von: oslc-op@... <oslc-op@...> Im Auftrag von David Honey2 via lists.oasis-open-projects.org
Gesendet: Mittwoch, 18. Januar 2023 20:18
An: oslc-op@...; Jim Amsden <jamsden@...>; andriib@...
Betreff: Re: [oslc-op] A mechanism to map(?) between configurations and effectivity

 

Currently the OSLC Configuration Management specification defines explicit representation of selections.
A configuration may reference zero, one, or many
oslc_config:Selections resources, each of which may specify zero, one or many oslc_config:selects statements. This representation is required to allow consumers of that data, such as an RDF indexer application such as IBM’s Lifecycle Query Engine, to know what version artifacts are selected by a specific configuration. In turn, this underpins the ability for the LinkIndexService to find incoming links in a specified configuration context (often a global configuration), and for Report Builder to report against versioned artifacts in such a configuration context, showing the right versions of concept resources in the report results.

 

If you choose some other representation of selections to address the issue of effectivity, then this compromises discovery of incoming links and reporting of version artifacts. The current specification would require that as the effectivity of a configuration changes, and you want other tools to be able to reflect that, then you must publish TRS modification events for the affected selections resources, and a the RDF content of those selections resources must represent the effective set of selected version artifacts at that point in time, and the reference version artifacts should also be tracked resources.

 

Another way of expressing this is that you need a mechanism for some other tool (e.g. LQE, LDX) to be able to determine the set of selected versions rather than this being solely available within the data owning tool.

 

Best regards,
David

 

 

From: oslc-op@... <oslc-op@...> On Behalf Of Jim Amsden
Sent: 18 January 2023 19:02
To: oslc-op@...; andriib@...
Subject: [EXTERNAL] Re: [oslc-op] A mechanism to map(?) between configurations and effectivity

 

Andrew, Really good to hear from you, we miss you! I think you misunderstood. I think if the PLM community needs to explicitly expose Part and PartVersion artifacts and the notion of effectivity into their domain model, as extensions to am: Resource,

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Andrew,

Really good to hear from you, we miss you!

 

I think you misunderstood. I think if the PLM community needs to explicitly expose Part and PartVersion artifacts and the notion of effectivity into their domain model, as extensions to am:Resource, that’s fine, even if it overlaps with OSLC Configuration Management in some aspects.

 

What I don’t think is a good idea is commingling product definition/BOM with configuration contribution. That is, a Part and a PartVersion isa am:Resource, not config:Configuration. This keeps separate the notions of decomposition of things from decompositions of contributions that select versions of things. Part/PartVersion tempts us to explore this, but there may be better approaches that have less conceptual coupling.

 

But in any case, this is a good area for us to explore.

 

 

From: <oslc-op@...> on behalf of Andrii Berezovskyi <andriib@...>
Reply-To: "oslc-op@..." <oslc-op@...>, "andriib@..." <andriib@...>
Date: Wednesday, January 18, 2023 at 10:23 AM
To: "oslc-op@..." <oslc-op@...>
Subject: [EXTERNAL] [oslc-op] A mechanism to map(?) between configurations and effectivity

 

Hi Jim, Closer to the end of the call, you suggested that adding support for effectivity or doing some other effort of fully reconciling the product/STEP way of versioning based on effectivity and the OSLC was based on configurations is not

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Hi Jim,

 

Closer to the end of the call, you suggested that adding support for effectivity or doing some other effort of fully reconciling the product/STEP way of versioning based on effectivity and the OSLC was based on configurations is not a good idea. Unfortunately, I didn’t fully get your idea. Could you please repeat your idea here because, regretfully, I didn’t grasp it properly?

 

/Andrew

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