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

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.

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

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

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.

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

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

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

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.

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

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.

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

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

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.

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

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.

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.

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

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

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.

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

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
​

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.

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

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
​

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

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.

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