CoreExtensionForPlm < Main

This wiki is locked. Future workgroup activity and specification development must take place at our new wiki. For more information, see this blog post about the new governance model and this post about changes to the website.
TWiki>
Main Web>PlmHome>CoreExtensionForPlm (23 Apr 2012, GrayBachelor) (raw view)
---++!! OSLC Core 2.0 Extensions for PLM - V1.1 Draft for discussion
 *Document Status:* Working draft, used for discussion and prototyping. Updated to V1.1 at 13th March 2012

%TOC%

---++ Version handling (proposal).

---+++ Introduction

A version is a very important concept in managing the lifecycle of products and system, explicit OSLC support for versioning is lacking in today's OSLC Specifications(Core, CM, AM, RM), there is some coverage in the SCM Spec. Whilst noting it is possible to apply existing Core, CM, AM and RM OSLC properties, for say, version identification, the aim here is to create an explict version handling approach for OSLC resources.

To support ALM or PLM, indication that a resource is a version of another resource is a common way of denoting some difference or variation, such as a change of state, between the two resources. The business purpose of which is to shift the focus of the work done by contributors, denote a specialisation of product or system content say for a given customer or market application or signal some significant event ((like achieving a certain condition) to trigger alternate processing by the business .Here the concern is the product or system definition and so changes of state arise from work done or selection of compositional options; options can be logical and physical or some combination.

To achieve coherency within PLM typically all significant business items (products, systems, components, documents etc) undergo versioning as part of change and configuratiion management including variant handling.Companies build up buisness rules so that stakeholders know what conditions need to be fulfilled to declare a version as available to some criteria or how to react when such signals are received.

It is worth noting that typically for complex products and systems the exact state of a resource is more ambiguous and is usually designated as being available to some criteria by assessment, i.e. approval. This ambiguity alllows for late customisation, thus reducing the effort to build up and maintain many similar configurations in parallel throughout the lifecycle. Whereas within ALM for software the availability of a version may be more readily signalled by way a simpler test, like an error free build. However for software with many options and parameters such simple tests are insufficent and then ALM and PLM needs become similar - that is version readiness for consumption is assessed by domain rules and criteria.

From an OSLC perspective alternate versions of OSLC resources, like a product, allow specific resource states, as product versions, to be linked to, and by, other resources like requirements, AM resources and SCM baselines. Similarly for requirement versions to be associated with each other or AM resource versions or SCM baselines, and so on. In general most OSLC resources undergo changes which may:

1- require re-evaluation of the composition of the OSLC resource

2- invalidate the purpose of a link between OSLC resources

3- require new links to be established between OSLC resources

Therefore a common way to define the behaviour of an OSLC resource as a version of another OSLC resource is needed. This proposal formalises basic OSLC resource version behaviour, and proposes that it be made explict in extensions to the OSLC Core Specification.
---+++++ Need for versioning with the target scenario

Consistent versioning support is necessary for OSLC to be able to support the target PLM scenario [[PlmSystemsEngineeringScenarioSystemsEngineerReactstoChangedRequirements][A systems engineer responds to a change in requirements]].

The scenario begins with a product (or system) and associated requirenents and their associated, satisfying, implementations at some definied state; a change request is applied (i.e changes are made to relevant and impacted items) and their version identification are updated to signal completion of the change, with approvals. Version handling of the OSLC resource used in the scenario is needed, namely CM, AM and RM resources plus the new proposed PM resource that supports Products, Product Versions and Product Views.

<img width="781" alt="OSLC PLM main scenario overview" src="http://open-services.net/pub/Main/PlmWorkingMaterials/OSLC_versioning_cases_2.PNG" title="Fig 1: OSLC PLM main scenario overview" height="183" />

*Fig1:* Overview of the need for versioning in the target scenario

*Additional notes on the scenario:*

Typically all items are under version control including the Change Request which may evolve during its evolution and approval.

The system or product context is the prevailing configuration, including variants.

The state of requirements and implementation is simplified as multiple constituents will go through various and multiple revisions before State 2 is achieved.

---+++ Resource Terminology and usage

*Base resource*

A base resource is an optional resource which act as a reference for one or more versions and may be able to generate additional resources which are versions of this resource.

May be superceded by another base resource as the resource history evolves

May generate versions, and additionally optional domain views, from criteria (not specified yet here, see the Draft PLM Specification for examples.

A base resource may maintain and make available a full version history for resource versions that it has generated.

*Resource version*

A resource version is resource which is a revision or variation of another resource, either or both, a base resource or another versioned resource.

So it may indicate some difference, or variance, from some other related version resources e.g. from a similar basis. It may be transient, or it may be worthy of sustaining for some time, or

indeed forever.

<img width="370" alt="OSLC Core versioning overview" src="http://open-services.net/pub/Main/PlmWorkingMaterials/OSLC_versioning_cases_3.PNG" title="OSLC Core versioning overview" height="272" />

*Fig2:* Overview of the OSLC Core versioning proposal

*Additional notes on the examples in the diagram:*

In Fig2 Case 1 Resource A may or may not be a base resource. The advantage of the base resource concept are that the full version history can be readily provided and that resource A can provide configuration services to specifiy the versions, such as by variant determinants and expressions; which will be addressed later.

In Fig2 Case 2 Resource C may or may not supercede Resource A, this is a business decision and will be addressed further here.
---++++++ *Specification of versions and their status*

The proposal here does not specify how one version is distinguished from another, other than by way of being a separate resource. It is up to the service provider or consumer to do this. Additional proposals are being prepared for managing variation of resources.

*Handling of succession*

Control of availability or designation of significance like "release", "latest", "use this one" is an orthogonal concern to creation and maintaining version history. For instance the designation of succession is a separate concern to denoting the basis of a version. The releationship needed is "isSuccesorOf" however it is proposed to adopt the [[http://dublincore.org/documents/dcmi-terms/#terms-replaces][dcterms:replaces]] as this includes succession and supplanting of one thing for another, in this case resource versions.

<img width="472" alt="" src="http://open-services.net/pub/Main/PlmWorkingMaterials/OSLC_versioning_cases_4.PNG" title="Examples of version succession" height="393" />

*Fig3:* Overview of the OSLC Core versioning succession proposals %RED% _NOTE: An update is pending to Case 2 in Fig 3_ %ENDCOLOR%

---+++ Properties

These are the proposed mandatory and optional properties to added to an OSLC Resource to make it a Version or View to associate it with the base Resource, examples of

OSLC resource type are e.g ChangeRequest, Requirement, (AM) Resource

Versions of a base resource are associated with that base resource by way of a new property adopted from dcterms:isVersionOf

A version can signify that it replaces one or more versions of the same base resource by the use of a new property adopted from dcterms: replaces, to show that this _Resource_ version succeeds another version.

   * *Name:* _Resource_
   * *Type URI* http://open-services.net/ns/oslcdomainname# _Resource_

<table cellspacing="0" cellpadding="0" id="table2" border="1"><thead><tr style="background-color: #a9a9a9"><th valign="top">%WHITE%Prefixed Name%ENDCOLOR% </th> <th valign="top"> %WHITE%Occurs%ENDCOLOR% </th> <th valign="top"> %WHITE%Read-only%ENDCOLOR% </th> <th valign="top"> %WHITE%Value-type%ENDCOLOR% </th> <th valign="top"> %WHITE%Represen-tation%ENDCOLOR% </th> <th valign="top"> %WHITE%Range%ENDCOLOR% </th> <th colspan="2" valign="top"> %WHITE%Description%ENDCOLOR% </th> </tr> </thead> <tbody> <tr> <td colspan="8" align="center" bgcolor="#ffffff" valign="top"> *OSLC Core:* Common Properties </td> </tr> <tr style="background-color: #ccffff"> <td bgcolor="#ffffff" valign="top"> rdf:type </td> <td bgcolor="#ffffff" valign="top">one -or-many </td> <td bgcolor="#ffffff" valign="top"> unspecified </td> <td bgcolor="#ffffff" valign="top"> Resource </td> <td bgcolor="#ffffff" valign="top"> Reference </td> <td bgcolor="#ffffff" valign="top"> n/a </td> <td colspan="2" bgcolor="#ffffff" valign="top">New resource type of Version and/or View added to existing OSLC Resource Types </td></tr><tr><td>dcterms:isVersionOf</td><td>zero-or-one</td><td>yes<br /></td><td>Either Resource or local resource </td><td>Either Reference or Inline</td><td> resource of same type</td><td colspan="2"> A related resource of which the described resource is a version, edition, or adaptation. OSLC usage requires the target resource *MUST* be a resource of the same type as the owning resource. </td></tr><tr><td>dcterms:replaces</td><td>zero-or-many<br /></td><td> unspecified</td><td> Either Resource or local resource </td><td> Either Reference or Inline</td><td> resource of the same type</td><td colspan="2"> A related resource that is supplanted, displaced, or superseded by the described resource. OSLC usage requires the target resource *MUST* be a resource of the same type as the owning resource. </td></tr></tbody></table>

---+++ Version Creation

OSLC base service providers *SHOULD* support [[OslcCoreSpecification#Creation_Factories][Creation Factories]] for creating versions and list them in the Service Provider Resource as defined by OSLC Core. OSLC base resource service providers *SHOULD* support [[OslcCoreSpecification#Resource_Shapes][Resource Shapes for Creation Factories]] as defined in [[OslcCoreSpecification#Resource_Shapes][OSLC Core Specification]]

---+++ Related References

   * [[ScmSpecV1][OSLC SCM draft v1.0 Specification]]
   * [[Plm20SpecExtensions][OSLC PLM draft v1.0 Specificiation]]

---+++ Appendix A - Sample versioned OSLC Resources

| Resource type | OSLC Ref model example | Scenario version | Usage example | Relationships | Example |
| AM | AMG60104 POWERSUBSYSTEM | Base | <!--[if !mso]> <style> v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} p\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} v\:textbox {display:none;} </style> <![endif]--><!--[if !ppt]--><!--[endif]--> <p> </p><p>Base AM Implementation Resource </p> <p> </p> | <!--[if !mso]> <style> v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} p\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} v\:textbox {display:none;} </style> <![endif]--><!--[if !ppt]--><!--[endif]--> <p> </p><p>Optional </p> <p>hasVersion UR2(Non-preferred property)</p> <p> </p> | [[%ATTACHURL%/AM_versioned_resource_examples_AMG60104.xml][AMG60104]] |
| AM | <!--[if !mso]> <style> v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} p\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} v\:textbox {display:none;} </style> <![endif]--><!--[if !ppt]--><!--[endif]--> <p> </p><p>AMG60104/004-POWERSUBSYSTEM </p> <p> </p> | 004 | <!--[if !mso]> <style> v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} p\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} v\:textbox {display:none;} </style> <![endif]--><!--[if !ppt]--><!--[endif]--> <p> </p><p>AM Implementation Version Resource </p> <p> </p> | <!--[if !mso]> <style> v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} p\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} v\:textbox {display:none;} </style> <![endif]--><!--[if !ppt]--><!--[endif]--> <p> </p><p>isVersionOf URI1 </p> <p> </p> | [[%ATTACHURL%/AM_versioned_resource_examples_AMG60104_004-POWERSUBSYSTEM.xml][ AMG60104_004-POWERSUBSYSTEM ]] |
| CM | ECR-000031 | Base | Base Change Request Resource | Optional<br />hasVersion UR2 (Non-preferred property) | [[%ATTACHURL%/CM_versioned_resource_examples_ECR-000031.xml][ECR-000031]] |
| CM | ECR-000031/A-US and EU 2016 ULEV standards | A | Change Request Resource | isVersionOf URI1 | [[%ATTACHURL%/CM_versioned_resource_examples_ECR-000031A-US_and_EU_2016_ULEV_standards.xml][ECR-000031A-US_and_EU_2016_ULEV_standards]] |
| RM | REQ-20188 | Base | Requirement base resource | Optional hasVersion (Non-preferred property) | [[%PUBURL%/Main/Plm20SpecExtensions/req_46.xml][REQ -20188]] |
| RM | REQ-20188 - A | A | Requirement version resource | isVersionOf REQ20188 | [[%PUBURL%/Main/Plm20SpecExtensions/req_45.xml][REQ -20188 - A]] |
| RM | REQ-20188 - B | B | Requirement version resource | <p>isVersionOf REQ-201188</p><p>replacesREQ-20188-A</p> | [[%PUBURL%/Main/Plm20SpecExtensions/req_49.xml][REQ -20188 - B]] |

end
Attachments
Topic attachments
I	Attachment	Action	Size	Date	Who	Comment
xml	AM_versioned_resource_examples_AMG60104.xml	manage	1.8 K	11 Nov 2011 - 02:05	GrayBachelor	AM base resource AMG60104
xml	AM_versioned_resource_examples_AMG60104_004-POWERSUBSYSTEM.xml	manage	1.7 K	11 Nov 2011 - 01:59	GrayBachelor	AM versioned resource example AMG60104_004-POWERSUBSYSTEM
xml	CM_versioned_resource_examples_ECR-000031.xml	manage	1.5 K	11 Nov 2011 - 01:40	GrayBachelor	Sample CM CR resource
xml	CM_versioned_resource_examples_ECR-000031A-US_and_EU_2016_ULEV_standards.xml	manage	3.7 K	11 Nov 2011 - 01:40	GrayBachelor	Sample CM CR versioned resource
Topic revision: r21 - 23 Apr 2012 - 10:53:36 - GrayBachelor
Main
Webs
Main
Sandbox
TWiki
Copyright � by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Contributions are governed by our Terms of Use
Ideas, requests, problems regarding this site? Send feedback