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.

OSLC Core 2.0 Extensions for PLM - Draft for discussion

Document Status: Working draft, used for discussion

Version handling (proposal).


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 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.

OSLC PLM main scenario overview

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.

OSLC Core versioning overview

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 dcterms:replaces as this includes succession and supplanting of one thing for another, in this case resource versions.

Fig3: Overview of the OSLC Core versioning succession proposals NOTE: An update is pending to Case 2 in Fig 3


These are the proposed mandatory and optional properties to added to a Resource Version to associate it with the base Resource

W here a Resource is any OSLC resource type e.g ChangeRequest? , Requirement, AMResource

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.

Prefixed Name Occurs Read-only Value-type Represen-tation Range Description
OSLC Core: Common Properties
rdf:type one -or-many unspecified Resource Reference n/a The resource type URIs. One of at least has the value of Resource Version. Note this requirement is being investigated to try to avoid the use of a new ResourceVersion? type for every Resource. See the feedback below.
Either Resource or local resource Either Reference or Inline resource of same type 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.
unspecified Either Resource or local resource Either Reference or Inline resource of the same type 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.

Version Creation

OSLC base service providers SHOULD support 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 Resource Shapes for Creation Factories as defined in OSLC Core Specification

NOTE: 13/12 An update is due to this topic

Related References

Appendix A - Sample versioned OSLC Resources

Resource type OSLC Ref model example Scenario version Usage example Relationships Example

Base AM Implementation Resource


hasVersion UR2




AM Implementation Version Resource

isVersionOf URI1

CM ECR-000031 Base Base Change Request Resource Optional
hasVersion UR2
CM ECR-000031/A-US and EU 2016 ULEV standards A Change Request Resource isVersionOf URI1 ECR-000031A-US_and_EU_2016_ULEV_standards
RM REQ-20188 Base Requirement base resource Optional hasVersion REQ -20188
RM REQ-20188 - A A Requirement version resource isVersionOf REQ20188 REQ -20188 - A
RM REQ-20188 - B B Requirement version resource

isVersionOf REQ-201188


REQ -20188 - B

Appendix B - Questions and Answers

Q1: What if my tool provides a versioned container

ANSWER: The resource version identifies the versioned container

Q2: What if my tool doesn’t indicate predecessors ?

ANSWER: Indication of succession is a May.

Q3: How to identify the versioning behaviour of a resource ?

ANSWER: base will have a minimal resource shape, infer from a resource types with no “isVersionOf”, or “replaces”. Multiple approaches today – Service provider doc, Query Header.

NOTE: Request guidance from Core.

Q4: What is the preferred use of backlinks for “hasVersion” ?

ANSWER: Preferred approach is not to use backlinks.

NOTE: hasVersion is not included in the specification.

Q5: Is there a better dcterms property for succession ?

ANSWER: dcterms :replaces is ambiguous, however its definition includes succession so it is proposed as the most applicable term

Q6: What if the resource supports versioning but has no concept of a base resource ?

ANSWER:A base resource is an optional concept, if a resource version does not have a hosting base resource then isVersionOf is used between ResourceVersions?

NOTE: This approach needs clarification by examples

Q7: What is a version is hosted by multiple base resources, in the case products when a product version is a member of e.g. different product families

ANSWER: isVersionOf refers to the base resource which created the Version. The recommended approach is that the association of a product version with multiple "hosting" products, e.g. family concepts, is handled through the ProductView? concept. So for a given ProductVersion? , multiple ProductViews? of the hosting product concepts would have hasPart associations linking back to the ProductVersion? of note.

Q8: What if a resource doesn’t support versioning, a resource factory for a ResourceVersion? as a SHALL is over stating the need ?

ANSWER: A creation factory service for a ResourceVersion? is an optional MAY

Note: The Core extensions Spec has been updated.PM Spec draft not updated

Appendix C - Next steps

1. Handle existing feedback

- add definitions- underway - feedback needed

- update Q&A where necessary - underway

- harvest any additional releavnt commentary retire the ppt/pdf from this page- done

- add diagrams to show examples- done

- add motivational links / intro to the page (picture of key elements and relationships) especially why Core needs this- done

- Comment from Olivier Berger 17/11- Should be addressed await feedback

Still to do at Dec 8th - Comment 1 from John Arwe on resource types 22/11- 13/12 The proposal is to be adopted and then solicit feedback

and follow on by Mike Loeffler

- description how to create a version- 13/12 an update will be made to the section on Create Version

Comment 3 from John Arwe on createVersion service 22/11

- comment on and show relationship to the SCM Spec- to be scehduled

2. Make Lyo examples available

3. Continue updates to Core Work Group

4. Seek agreement as an accepted draft based upon substatitive open issues being addressed


Topic attachments
I Attachment Action Size Date Who Comment
xmlxml AM_versioned_resource_examples_AMG60104.xml manage 1.8 K 11 Nov 2011 - 02:05 GrayBachelor AM base resource AMG60104
xmlxml 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
xmlxml CM_versioned_resource_examples_ECR-000031.xml manage 1.5 K 11 Nov 2011 - 01:40 GrayBachelor Sample CM CR resource
xmlxml 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
Edit | Attach | Print version | History: r21 | r19 < r18 < r17 < r16 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r17 - 18 Jan 2012 - 15:10:47 - GrayBachelor
This site is powered by the TWiki collaboration platform 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