1. © OSLC OSLC PLM Workgroup1 OSLC Core extensions proposal Update of the Core WG proposal V0.9

2. © OSLC OSLC PLM Workgroup2 Topics Request to the OSLC Core WG Why do we need versioning support in Core ? What is the proposal ? What examples do we have ?

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

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

5. © OSLC OSLC PLM Workgroup5 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 denoted 1 Changes of state arise from –Work done on the definition of the thing 2 –Application of compositional options 3 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

6. © OSLC OSLC PLM Workgroup6 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

7. © OSLC OSLC PLM Workgroup7 Why is versioning needed in OSLC ? OSLC resources represents things and their inter-relationships Many OSLC resource 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

8. © OSLC OSLC PLM Workgroup8 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 CR Requirements Implementation System or product context Controlled config Is Implemented By CR Requirements Implementation System or product context Is Based upon Transition Controlled config 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. Version AVersion B Version 1Version 2 Version BetaVersion Alpha

9. © OSLC OSLC PLM Workgroup9 Proposal outline

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

11. © OSLC OSLC PLM Workgroup11 Basic versioning model proposed (2) A base resource –Only the base can make new version resources Individual resources per version –MAY isVersionOf the base resource –MAY Replaces another version resource ResourceVersion: HSUV V1 ResourceVersion: HSUV V2ResourceVersion: HSUV V3ResourceVersion: HSUV V5 ResourceVersion: HSUV Vulcan ResourceVersion: HSUV 061111 Resource: HSUV replaces

12. © OSLC OSLC PLM Workgroup12 Simplified proposal Prefixed NameRead- only Value-typeRepresentati on RangeDescription dcterms: isVersionOf unspecifi ed 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. dcterms: replaces unspecifi ed Either Resource or Local Resource Either Reference or Inline resource of 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. Usage guidelines: to represent a related resource, currently available or superceding another version Considered the of provenance and source too but rejected them.

13. © OSLC OSLC PLM Workgroup13 Overview of the need for versioning across the OSLC Specs Change Management - integrations with work item and change management repositories.Change Management –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.Quality Management –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.Requirements Management and Definition –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.Asset Management –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.Architecture Management –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 resourcesSoftware Configuration Management –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.Automation –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

14. © OSLC OSLC PLM Workgroup14 Example: Requirement Resource Requirement resource base + 2 revisions Scenario exampleScenario version Usage exampleRelationshipsReq #Example located at: REQ-20188BaseBase Requirements ResourceOptional hasVersion 45 hasVersion 49 46 http://www.w3.org/RDF/Validator/ARPServlet? URI=http://open- services.net/pub/Main/Plm20SpecExtensions/r eq_46.xml&PARSE=Parse+URI%3A+&TRIPL ES_AND_GRAPH=PRINT_TRIPLES REQ-20188-AARequirement Version Resource isVersionOf 4645 http://www.w3.org/RDF/Validator/ARPServlet? URI=http://open- services.net/pub/Main/Plm20SpecExtensions/r eq_45.xml&PARSE=Parse+URI%3A+&TRIPL ES_AND_GRAPH=PRINT_TRIPLES REQ-20188-BBRequirement Version Resource isVersionOf 46 replaces 45 49 http://www.w3.org/RDF/Validator/ARPS ervlet?URI=http://open- services.net/pub/Main/Plm20SpecExten sions/req_49.xml&PARSE=Parse+URI% 3A+&TRIPLES_AND_GRAPH=PRINT_ TRIPLES RequirementVersion URI2 isVersionOf Requirement URI1 REQ-20188 RequirementVersion:UR3 REQ-20188-A replaces REQ-20188-B isVersionOf shortTitle

15. © OSLC OSLC PLM Workgroup15 Example: ChangeRequest resource ChangeRequestVersion URI2 isVersionOf ChangeRequest URI1 ECR-000031 ECR-000031/A-US and EU 2016 ULEV standards shortTitle Scenario exampleScenario version Usage exampleRelationshipsExample located at: ECR-000031BaseBase Change Request Resource Optional hasVersion UR2 ECR-000031/A-US and EU 2016 ULEV standards AChange Request ResourceisVersionOf URI1 shortTitle

16. © OSLC OSLC PLM Workgroup16 Example: AM Resource AM ResourceVersion URI2 isVersionOf AM Resource URI1 AMG60104/004-POWERSUBSYSTEM shortTitle AM ResourceView URI3AMG60104/004-View hasView AM ResourceVersionURI400010998/003-CALIBRATIONS hasPart shortTitle Scenario exampleScenario version Usage exampleRelationshipsExample located at: BaseBase AM Implementation Resource Optional hasVersion UR2 AMG60104/004- POWERSUBSYSTE M 004AM Implementation Version Resource isVersionOf URI1

17. © OSLC OSLC PLM Workgroup17 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 http://open-services.net/bin/view/Main/Plm20SpecExtensions

18. © OSLC OSLC PLM Workgroup18 Questions & Answers 1.What if my tool provides a versioned container –ANSWER: The resource version identifies the versioned container 2.What if my tool doesn’t indicate predecessors ? –ANSWER: Indication of succession is a May. 3.How identify the versioning behaviour of a resource ? –ANSWER: base will have a minimal resource shape, infer from a resource types with no “isVersionOf” 4.What is the preferred use of backlinks for “hasVersion” ? –ANSWER: May. Preferred approach is not to use backlinks. 5.Is the a better dcterms property for succession ? 1.ANSWER dcterms :replaces is ambiguous, however its definition includes succession so it is proposed as the most applicable term