Aug 23rd Tuesday 11am OSLC PLM workgroup working meeting

1. Welcome

Attendees: Gray, Rainer, Steve, Jim, David H, Mike, , Carlos

Apologies: Nick

2. Update on the reference model availability and feedback

No updates this week

3. Resource prototyping using RIO / eclipse Lyo

Mike Loeffler to present on his additional prototyping. The session was recorded.

Notes from Mike's description

URI mapping of TC objects as per the versioning proposal

Map the TC UID to the URI as an extension to the base RIO - ID is an attribute

Use the TC Web URL

(Not able to show the hover preview

(Not fill in hasVersion at the Item level

Plan to add hasPart

Q? How get the data from TC

Adapt the RIO/Lyo code to replace the local file-system store with TC-SOA API. TC java classes to implement client side, type of RESTful service over HTTP

Replace file system

Q? Show hasVersion

Models are version specific

Try to import model on top - should work

Q? What was the difficultly of getting from TC

Simple GET doesnt provide

4. Application and extension of the reference model

Covered above in Mike's session. Gray has also installed the sample data originating from TC into Lyo, with Mike's new RDF (PLM extensions

5. Responding to new OSLC Specs and concepts being published

Feedback welcome on the published version and version progression.

> Longer term to Core and a wider set of stakeholders

> Shorter term as a PLM extension and then reconcile later

> SCM 1 addresses Change Sets, versions, baselines

Q? 2 main cases - direct and indirect

> Asset management has versioning included

Q? Scenario span the different Specs

Yes as a release by discipline or sub-system

Aim to socialise with in the PLM WG membership

then go to wider community via Core

Core needs to support baselines (snapshots are versions (immutable) and tracked resources

Q? examples needed

Show examples as versions in multiple tools inc SCM

PLM typically offers that all items are versioned

Need a detailed view of ...

1. CRs not typically versioned

2. Sequential vs concurrent versions

Branching concept needs to be supported. Common ancestor supported included in the proposal, via isVersionOf

Q? How TC support

TC supports identification but revision history may require a particular naming scheme

Auto version ident dotted branch notation #, branch #

or own namespace (container) version

3. Individual artefacts or higher level groupings

STEP supports specific approach (I, IV, IVD)

Standards allows open version naming

TC can use any names

For the Core workgroup aim to describe extensions by way of their capability

Carlos act as guinea pig on consumability of the description

ACTION: Carlos provide feedback on scenarios and reference model

1. Which step in what activity/role in the scenario

2. Identify the need and sense of urgency fro updates in particular areas

In terms of feedback on the propossal David recommend Nick + SCM WG Geoff Clemm

6. AOB

Propose to discuss prototyping and sandboxing needs as pat of the roadmap discussion on Aug 30th

7. Summary, actions and close