The current OSLC PLM spec assumes the PLM is a separate domain of Parts and PartUsages that may also be VersionResources, similar to most of the other OSLC Domains. Note that by convention, OSLC CM ChangeRequest is not considered a VersionResource (although this is not discussed in the OSLC CM spec).
Part and PartUsage have defined relationships to other OSLC domain artifacts, and their properties and relationships can be versioned using HTTP PUT.
This means that OSLC Configuration Management applies to PLM Parts and PartUsages. They can have versions, and their versions can be selected by local or global configurations. Clients choose what version of a BOM made up of Parts and PartUsages to use with a Configuration-Context. The selections in a specific configuration are explicitly selected with HTTP PUT.
From another perspective, a Configuration and its Contributions also defines a hierarchy of references to selections of version resources. This could also be a kind of BOM of references to actual artifacts, where the configurations and contributions aren't versioned, rather the BOM specifies what versions of the actual artifacts are selected in a Configuration-Context.
So if a Part is a kind of Configuration, then it might be a local configuration that has oslc_config:selections resources that are the elements the BOM part represents. Notice the one to many association between Part as a configuration and its selections resources. Contrast with Part as VersionResource that would have versions of links to other resources.
So the question is, Is a Part an oslc_config:VersionResource, an oslc_config:Configuration or possibly both?
Why is this important, and why isn't a Configuration of related parts as VersionResources (as in SysML) sufficient?
Because a PLM Part isn't the same as a SysML PartDefinition which is a model of something that implements a PLM Part. A Part is an element of a BOM, and all its PartUsages are contributions of other Parts. Each part and sub-part has its own configuration defining the selections of artifacts the part represents. T
A Part also represents an element in a PLM BOM for a product or deliverable. It is intended to link other AM, RM, CM, QM, SysML OSLC artifacts that control the Part's lifecycle. A Part may have attributes, links and is composed of other Parts through the PartUsage associative object. he version of the Part represents its attributes, links, configuration and contribution state, and represents the evolution of the BOM.
If a Part has attributes, has links to other OSLC resources that realize and/or control its lifecycle, then the Part could be a VersionResource.
So it appears that Part could be considered both a Configuration and a VersionResource.
That means that a Configuration (Baseline, Stream or ChangeSet) can have oslc_config:selections and have contributions (i.e., PartUsages) that refer to Parts which could be linked to other OSLC resources included in contribution to that configuration, just like e.g., oslc_am:Resource.
If a Part is a VersionResource and Configuration (like Baseline, Stream or ChangeSet - Configuration is abstract) then:
- It could have versions that manage the lifecycle of its properties, including its contribution. That means when it is used in a configuration, a Configuration-Context would be provided to select the proper version of the Part (Configuration)
- It could have Contributions from other configurations, including other Parts - which Martin considers PartUsages
- It could be contributed to other configurations as a usage of that part
- It could have selections that are VersionResources - what would these selections be?
- It wouldn't be the sub-Parts since the PartUsages are modeled as contribution to the Part configuration
- What selections would be needed/applicable? Versions of the resources the Part represents?
- Could a Part have no selections, everything about the part is in its properties and the PartUsages that contribute to the Part's configuration?
Can an OSLC Configuration also be a VersionResource? The OSLC specification allows for Configurations to be treated as VersionResources, enabling the versioning and management of the resources that make up the Configuration, its properties (including attributes and links). This allows for better traceability, collaboration, and change management in the context of software development and lifecycle management. However there are currently no implementations that support versioned configurations.
When a versioned Part is contributed to a configuration, a Configuration-Context would be required to select the version of the part to contribute. The Part would have selections that are VersionResources. If a Part changes, and it is contribution to other configurations, its concept URI and some Configuration-Context would determine what version of the part is selected, what its property values would be, what its links to other resources would be, and what its selections would be when it is contributed to other configurations.
Possibly the concepts of effectivity and variant management should be considered to better understand the full semantics of OSLC PLM Part and PartUsage to help answer the question of whether a Part is a Configuration and/or VersionResource.
The current OSLC PLM spec assumes the PLM is a separate domain of Parts and PartUsages that may also be VersionResources, similar to most of the other OSLC Domains. Note that by convention, OSLC CM ChangeRequest is not considered a VersionResource (although this is not discussed in the OSLC CM spec).
Part and PartUsage have defined relationships to other OSLC domain artifacts, and their properties and relationships can be versioned using HTTP PUT.
This means that OSLC Configuration Management applies to PLM Parts and PartUsages. They can have versions, and their versions can be selected by local or global configurations. Clients choose what version of a BOM made up of Parts and PartUsages to use with a Configuration-Context. The selections in a specific configuration are explicitly selected with HTTP PUT.
From another perspective, a Configuration and its Contributions also defines a hierarchy of references to selections of version resources. This could also be a kind of BOM of references to actual artifacts, where the configurations and contributions aren't versioned, rather the BOM specifies what versions of the actual artifacts are selected in a Configuration-Context.
So if a Part is a kind of Configuration, then it might be a local configuration that has oslc_config:selections resources that are the elements the BOM part represents. Notice the one to many association between Part as a configuration and its selections resources. Contrast with Part as VersionResource that would have versions of links to other resources.
So the question is, Is a Part an oslc_config:VersionResource, an oslc_config:Configuration or possibly both?
Why is this important, and why isn't a Configuration of related parts as VersionResources (as in SysML) sufficient?
Because a PLM Part isn't the same as a SysML PartDefinition which is a model of something that implements a PLM Part. A Part is an element of a BOM, and all its PartUsages are contributions of other Parts. Each part and sub-part has its own configuration defining the selections of artifacts the part represents. T
A Part also represents an element in a PLM BOM for a product or deliverable. It is intended to link other AM, RM, CM, QM, SysML OSLC artifacts that control the Part's lifecycle. A Part may have attributes, links and is composed of other Parts through the PartUsage associative object. he version of the Part represents its attributes, links, configuration and contribution state, and represents the evolution of the BOM.
If a Part has attributes, has links to other OSLC resources that realize and/or control its lifecycle, then the Part could be a VersionResource.
So it appears that Part could be considered both a Configuration and a VersionResource.
That means that a Configuration (Baseline, Stream or ChangeSet) can have oslc_config:selections and have contributions (i.e., PartUsages) that refer to Parts which could be linked to other OSLC resources included in contribution to that configuration, just like e.g., oslc_am:Resource.
If a Part is a VersionResource and Configuration (like Baseline, Stream or ChangeSet - Configuration is abstract) then:
Can an OSLC Configuration also be a VersionResource? The OSLC specification allows for Configurations to be treated as VersionResources, enabling the versioning and management of the resources that make up the Configuration, its properties (including attributes and links). This allows for better traceability, collaboration, and change management in the context of software development and lifecycle management. However there are currently no implementations that support versioned configurations.
When a versioned Part is contributed to a configuration, a Configuration-Context would be required to select the version of the part to contribute. The Part would have selections that are VersionResources. If a Part changes, and it is contribution to other configurations, its concept URI and some Configuration-Context would determine what version of the part is selected, what its property values would be, what its links to other resources would be, and what its selections would be when it is contributed to other configurations.
Possibly the concepts of effectivity and variant management should be considered to better understand the full semantics of OSLC PLM Part and PartUsage to help answer the question of whether a Part is a Configuration and/or VersionResource.