1. OSLC Core extensions proposal
Update of the Core WG proposal
V0.10
Gray Bachelor and the PLM Workgroup team
OSLC PLM Workgroup

2. Topics Request to the OSLC Core WG
Why do we need versioning support in Core ?
What is the proposal ?
What examples do we have ?
Q&A
OSLC PLM Workgroup

3. Summary of the request
The OSLC Core Workgroup to adopt an initial versioning spec as a “Core extension”
OSLC PLM Workgroup

4. Why do we need versioning support in Core ?
OSLC PLM Workgroup

5. Definition of version
Indicating some thing as a version of another thing is a common way that some difference, or change of state, between two things is denoted1
Changes of state arise from
Work done on the definition of the thing2
Application of compositional options3
Therefore creation of a version is used to
Signal that some change activity has occurred
Trigger evaluation of alternative process states
1 Alternative approaches are to use unique, but related name for things – say by concatenation or specific coding and classification terms
2 Such as evolving or correcting the definition of the thing
OSLC PLM Workgroup

6. Versioning is a key aspect of configuration and change control
Alternate versions of a resource allow specific resource states to be linked
Configuration by association of versions of resources allows multiple configurations to be available
e.g. to provide alternative product and system descriptions from a common base and to phase the work needed to make change
Identification of resources as versions is a key means to support change control
e.g. to track changes to an artefact at a coarse grained level, to require approval to allocate a new version
OSLC PLM Workgroup

7. Why is versioning needed in OSLC ?
OSLC resources represents things and their inter-relationships
Several OSLC resource can represent composition of related groups of things (e.g. other resources)
Resource use links to signify important relationship e.g. compositional dependencies
Most OSLC resources undergo change
Change to a resource may require re-evaluation of the composition of the resource
Changes to resources may require new links to be established
Changes to resources may invalidate the purpose of a link
Today version support needs to achieve indirectly say by resource properties. However there is a not a common way to define the behaviour of a resource when it is represents a version of another resource
This proposal formalises basic OSLC resource version behaviour
Consistent versioning support if necessary for the OSLC PLM scenario
OSLC PLM Workgroup

8. The main PLM scenario is a typical industry case
Dear Systems Engineer please “implement a change to a system product” that is at some defined state, and make it available at a new state
Is Based upon
Is Implemented By CR CR
System or
product context
Version Alpha
System or
product context
Version Beta
Controlled
config
Transition
Controlled
config
Requirements
Implementation
Requirements
Implementation
Version A
Version 1
Version B
Version 2
State 1
State 2
State 1 is some combination of artefacts that describes what change is based upon, typically it is a previously released configuration . Additional things may be identified to allow e.g. Take account of this, combine these, refer to this too, make one like this from that. The elements that make up the combination are usually under change control to allow an exact as necessary states to be described
State 2 is the result of some change and is a involves new, modified, replaced and removed artefacts compared with State 1. State 2 is typically achieved when the state of the artefacts and their relationships meet the requested change. For simplicity intermediate states are not shown and will depend on the sequence and actual means used to make the change.
OSLC PLM Workgroup

9. Proposal outline
OSLC PLM Workgroup

10. Proposed versioning model: Base resource and versions
Resource: HSUV
ResourceVersion: HSUV V1
replaces
ResourceVersion: HSUV V2
isVersionOf
replaces
replaces
ResourceVersion: HSUV V3
ResourceVersion: HSUV Vulcan
replaces
ResourceVersion: HSUV V5
replaces
ResourceVersion: HSUV
Versions are created by the base resource
Version resource isVersionOf a base resource
OSLC PLM Workgroup

11. Basic versioning model proposed (2)
Resource: HSUV
replaces
replaces
ResourceVersion: HSUV V1
ResourceVersion: HSUV Vulcan
ResourceVersion: HSUV
replaces
replaces
replaces
ResourceVersion: HSUV V2
ResourceVersion: HSUV V3
ResourceVersion: HSUV V5
A base resource
Only the base can make new version resources
Individual resources per version
MAY
isVersionOf the base resource
Replaces another version resource
OSLC PLM Workgroup

12. Simplified proposal OSLC PLM Workgroup Prefixed Name Read-only
Value-type
Representation
Range
Description
dcterms:
isVersionOf
unspecified
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.
replaces
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. Usage guidelines: to represent a related resource, currently available or superceding another version
Considered the of provenance and source too but rejected them.
OSLC PLM Workgroup

13. Overview of the need for versioning across the OSLC Specs
Change Management - integrations with work item and change management repositories.
e.g. early redefinition of the business intent of a change request may need to be signalled
Quality Management - integrations in quality management and testing.
e.g. a test plan is approved in a certain state, indicated by the state of test harness, test cases and test data. Alternative system configurations may required alterations of any of these to be visibly controlled
Requirements Management and Definition - integrations in requirements management and requirements definition tools.
e.g. a requirement may be allowed to evolve after some agreement amongst stakeholders and so the change will need to be indicated so that the correct stakeholders can be brought to bear on a new agreement on the updated requirement
Asset Management - integrations between asset management and other lifecycle tools.
e.g. an asset will evolve through a series of definition stages with changes during in its lifecycle, the changes may invalidate deployment and management services applied
Architecture Management - integrations related to models and other artifacts used during analysis, design and construction that help maintain architectural integrity.
e.g. an architectural model will undergo significant changes during its evolution and some certain important changes will trigger governance or design review activities
Software Configuration Management - integrations targeted at version control, change sets, baselines and other resources
E.g. revision control is very important to control which artefacts are applied in a given setting and to denote change, either to an individual thing, group via a container or explicit structure
Automation - integrations involving automation tools like build, deploy, and analysis tools.
E.g. an automation plan will evolve, be tested and sanctioned by SMEs based upon evaluation of its outcome. Changes to the plan will result in re-running and re-evaluation or application of alternatives tests and evaluations
OSLC PLM Workgroup

14. Example: Requirement Resource Requirement resource base + 2 revisions
shortTitle
Requirement URI1
REQ-20188
isVersionOf
shortTitle
RequirementVersion URI2
REQ A
isVersionOf
replaces
shortTitle
RequirementVersion:UR3
REQ B
Scenario example
Scenario version
Usage example
Relationships
Req #
Example located at:
REQ-20188
Base
Base Requirements Resource
Optional
hasVersion 45
hasVersion 49 46
REQ A A
Requirement Version Resource
isVersionOf 46 45
REQ B B
replaces 45 49
OSLC PLM Workgroup

15. Example: ChangeRequest resource
shortTitle
ChangeRequest URI1
ECR
isVersionOf
shortTitle
ChangeRequestVersion URI2
ECR /A-US and EU 2016 ULEV standards
Scenario example
Scenario version
Usage example
Relationships
Example located at:
ECR
Base
Base Change Request Resource
Optional
hasVersion UR2
ECR /A-US and EU 2016 ULEV standards A
Change Request Resource
isVersionOf URI1
OSLC PLM Workgroup

16. Example: AM Resource OSLC PLM Workgroup shortTitle AM Resource URI1
isVersionOf
shortTitle
AM ResourceVersion URI2
AMG60104/004-POWERSUBSYSTEM
hasView
shortTitle
AM ResourceView URI3
AMG60104/004-View
hasPart
shortTitle
AM ResourceVersionURI4
/003-CALIBRATIONS
Scenario example
Scenario version
Usage example
Relationships
Example located at:
AMG60104
Base
Base AM Implementation Resource
Optional
hasVersion UR2
AMG60104/004-POWERSUBSYSTEM
004
AM Implementation Version Resource
isVersionOf URI1
OSLC PLM Workgroup

17. Summary of the version handling proposal
Any OSLC resource can gain version support behaviour through extensions to Core
Applicable to any OSLC resource, including the new proposed Product resource
A base resource can have multiple version resources
hasVersion is an optional property of a base resource
A version resource identifies its base resource
isVersionOf
A version resource can indicate its succession
replaces
OSLC PLM Workgroup

18. Questions & Answers What if my tool provides a versioned container
ANSWER: The resource version identifies the versioned container
What if my tool doesn’t indicate predecessors ?
ANSWER: Indication of succession is a May.
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. Request guidance from Core.
ISSUE: Some SCM tools don’t have a base resource explicitly available e.g. SCCS/RCS/CVS/PVCS
What is the preferred use of backlinks for “hasVersion” ?
ANSWER: May. Preferred approach is not to use backlinks.
Is the 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
What if the resource supports versioning but has no concept of a base resource ?
Consequence isVersionOf would be used between ResourceVersions
ANSWER: Implemented in the draft at 11/11 but not in the PM Spec
Base Resource could be optional MAY
Resource Factory for creating a new resource version on a base is optional MAY
A creation factory service for a ResourceVersion would be an optional MAY
How associate ResourcesVersions with multiple base resources ?
ANSWER: Allow multiple associations isVersionOf one or many
What if a resource doesn’t support versioning, a resource factory for a ResourceVersion as a SHALL is over stating the need
OSLC PLM Workgroup