Contents
Meeting Logistics
Nick Crossley will normally host the telecons. Here are the details.
Date and Time: Tuesday at 6am US/Pacific time
Participant passcode: 73872710#
When Nick is away, David Honey may host the telecons. The participant passcode for such meetings is 40766597#.
Commonly used phone numbers
|
Toll-free Phone Numbers |
| US and Canada |
1-888-426-6840 |
| Britain |
0800-368-0638 |
| France |
0800-94-0558 |
| Germany |
0800-000-1018 |
| Israel |
1-809-417-783 |
| Sweden |
0200-12-5807 |
Additional phone numbers
Additional international dial-in numbers.
Web conference
A web conference is set up only if required - the meeting agenda will indicate this.
Agendas and Minutes
Agenda for 2013-03-26
Review first draft specification.
This will be a community review meeting, open to people that have not signed the Workgroup Participation Agreement. Comments can be received, but no new material will be developed.
Agenda for 2013-03-19
- Review minutes and issues; prepare for review of first draft specification.
Agenda for 2013-03-12
TBD
Agenda for 2013-03-05
TBD
No meeting on 2013-02-26
Agenda for 2013-02-19
- Review minutes from previous meeting
- Review the Configuration Management Issues, specifically issue 3.
- Complete review of scenario, terminology, and resource definition pages
Minutes for 2013-02-12
Attending: Nick C, Gray, Niklas, David, Peter, Mike,
Discussed terminology changes - no objections.
Discussed suggested division of responsibilities between Config Mgt group and PLM-ALM workgroup - no objections.
Nick will update the references to the Linked Data Platform.
We then discussed the issues list, looking at issues 1 and 3. For issue 1, the group agreed, with the provision that we make a strong recommendation for the use of LDPC, since without such common standards a client cannot discover members in an otherwise unknown domain. For issue 3, Nick took an action to write up straw man proposal for the group to discuss next week. Issue 2 was not discussed.
2013-02-05: meeting canceled
2013-01-29: meeting canceled
Minutes for 2013-01-22
Attending: Mike L, Mike F, Niklas, Nick, Steve, Gray, David
After reviewing the minutes from the previous meeting, we discussed the terminology page. On change sets, the group agreed that while the predefined OSLC oslc_cm:changeSet link should always target a change set, other OSLC or application-specific links may go directly from change requests to CIs. The definition of a change set should also indicate that a change set might be the same as a configuration in some providers.
While change sets also usually indicate atomic transactions, but that usage is outside the scope of our initial scenarios.
On the definition of context, Nick has an action item to clarify ‘real or potential’, by stating that the config resource might not exist.
Add to the list of issues: partial configurations, and how to separate the concerns of containment or structure from the configuration management vocabulary.
Minutes for 2013-01-15
Attending: Nick, Mike L, Mike F, David, Steve S, Niklas, Gray
Nick reminded the group that all active participants must sign the WPA. For those who are unable to do so, we will hold a monthly informational meeting, open to all interested parties, but we also strongly recommend that you contact Steve Speicher or some other member of the Steering Committee to discuss the roadblocks preventing your signing.
The wording for version skew was discussed, and agreed after Nick made one more tweak to allow different scenarios for providers with and without support for version skew within a configuration.
Initial wording was provided for change set, but Nick needs to refine this. Mike L wondered where change sets were defined, and mentioned that some systems do not support such things. Nick described how the link from a change request to a change set was defined by the OSLC Change Management spec, but that the definition of a change set resource was left to the Configuration Management spec (originally the OSLC SCM spec). We agreed that the change set might have to be a resource synthesized by a provider from the actual set of changes linked directly to a change request (via some link type not defined by OSLC), so our scenarios could not explicitly describe how change set resources are created or managed - that is, a POST or PUT on a change set might fail, and only the result of a GET would be defined. In our scenarios, links between change sets and modified or new resources would be created implicitly when a resource was modified, and would not be created by explicit client action.
At Gray’s suggestion, Nick added an entry for context to the terminology page. A context is probably either a configuration or a configuration specification or something similar.
We then discussed the PLM Systems engineering change scenario scenario. Nick tried to relate the contexts for steps a4, a5, and a6 with the contexts identified in the text after steps a1, a2, and a3, believing that the context for a4 was intended to be the third of the identified contexts (the context of the workspace …). After some discussion, it was realized that there are really four contexts, not three:
- The context against which the issue is being reported.
- A context representing the target in which the change will be delivered.
- A context (baseline?) identifying the appropriate versions of resources as a starting point for applying the change.
- A context representing the workspace in which the change is developed, and which will contain new versions of modified resources.
Nick also questioned the need to describe locking explicitly in steps a5 and a6, since some configuration management systems do not support locking in this way (for example, they might just support private workspaces, where two or more parallel such workspaces may exist, and any concurrent changes would have to be resolved or merged). After some discussion about the difficulties in wording scenarios in a general but vague way, Mike L suggested that it would be better to write different scenarios to cover the two different modes of operation. Nick and Gray have an action item to work on new or elaborated scenarios, including ones that work for providers that do not use locking.
Action items:
- Nick to refine change set definition
- Nick and Gray to refine scenarios, possibly splitting them into multiple sets for different provider capabilities
- Nick to provide strawman definition of context
Minutes for 2013-01-08
Attending: Nick, David, Peter, Niklas, Steve, Mike Loeffler, Mike Saylor
A short meeting to start off the new year; we welcomed a new member (Mike Saylor from IBM ClearCase), reviewed the minutes of previous meetings, reviewed the revised definition of version skew, and discussed the agenda for the next month.
Action items:
- Nick to talk to Gray and schedule a date for review of the ALM-PLM scenario - hopefully next week
- Nick to further revise the wording on version skew, to clarify the intent that scenarios can be addressed by systems which cannot represent version skew in a single configuration while acknowledging that some systems can represent it in a single configuration
- David to set up a link from the Config Mgt wiki to his HSUV example on the ALM-PLM wiki page
- Mike L and the rest of the workgroup to study the RELM RDF and David’s HSUV example, and we set a review date of Jan 22
- Nick to set up draft schedule for next few meetings (done - see above)
- Steve to provide updated link for Linked Data Platform
- Entire workgroup to review scenario, terminology, and resource definition pages
- Nick to update milestones to show completion of scenarios and requirements by end of January (done)
Minutes for 2012-12-18
Attending: Nick, David, Peter, Niklas, Mike
We discussed agenda items, and agreed to defer the review of the ALM-PLM “System Engineer responds to Change Request” scenario until Gray was available.
We discussed enumeration of the resources contained in a baseline and/or configuration. It was agreed that enumerating the resources contained in a baseline was a high-priority use case, while doing the same for other (mutable) configurations was desirable but not as high priority.
Mike still evaluating RELM PD structure, so we agreed to defer further review of that.
Issues and Action items:
- Nick to reword the terminology section on version skew, to allow systems to implement version skew within a single configuration but not to require support for such a feature. This raises some questions with enumerating the contents of a configuration - can a resource appear more than once while enumerating a baseline?
- Nick to contact Steve Speicher re CM links (??)
Minutes for 2012-12-11
Attending: David, Mike
We intended to review the ALM-PLM “System Engineer responds to Change Request” scenario. However, neither Gray nor Niklas were able to attend. We decided to cancel this meeting and reconvene on the 18th December.
Minutes for 2012-12-04
Attending: David, Gray, Mike, Niklas
- We recapped last week’s discussion on prov:wasRevisionOf.
- We discussed whether baselines should only contain immutable members. It was felt that PLM tools tended not to use baselines as such, but rather use the term “release” to describe a fixed set of known versioned resources. There was at least one case mentioned where the term “baselining” tended to mean the act of preparing for a release. It was suggested that we use the term “configuration” for this since some of the versioned resources might be mutable.
- We talked about how baselines and configurations might differ. It seems useful to be able to compare a configuration with a configuration or a baseline, and compare two baselines. However, there are potential issues with this if a configuration in a tool is not enumerable (has a known finite set of versioned resource members).
- We discussed version skew. The definition on the terminology page would require that different configurations are used to support version skew. There was a feeling that this was too restrictive, especially in the PLM domain. Perhaps a configuration plus a “path” is what determines the version of a resource used in a configuration. We will revisit this topic when Nick is available.
Minutes for 2012-11-27
Attending: David, Mike, Gray
- We reviewed the W3C PROV Model Primer. The prov:wasRevisionOf predicate seemed like a good fit for the concept of a history predecessor. We discussed whether we should use both that predicate and dcterms:replaces. The feeling was that dcterms:replaces is a more generalized usage that might be used when a resource becomes obsolete and is replaced by a different concept resource. For that reason, the suggestion was that we solely use prov:wasRevisionOf to represent history predecessor. The The W3C PROV Ontology does not anything about cardinality. There was agreement that a versioned resource might have zero, one, or many prov:wassRevisionOf statements. Zero would apply to the first version in the history as it has no predecessor. One occurrence would apply to typical sequential revisions. Two or more occurrences might apply when parallel revisions are merged.
- We discussed dcterms:isVersionOf. The W3C PROV Model Primer does not seem to discuss the notion of concept resources, so dcterms:isVersionOf is a good fit to represent a version resource and its base concept resource.
- We discussed prov:used. This doesn’t seem that relevant to the CM workgroup, and it appears to overlap the existing dcterms:references predicate.
- We discussed baselines and configurations. In some domains, a baseline may be constructed over time. While the baseline is being prepared, the baseline itself is mutable, but the resources it references are immutable. It is not clear whether baselines should be a different type of resource than configurations. Baselines may undergo a lifecycle that includes an approval process before the baseline resource itself becomes an unchangeable collection of versioned resources.
Minutes for 2012-11-20
Attending: Steve, Gray, Niklas, Nick, David, Peter, John, Mike,
Mike needs a little more time to think about the RELM Product Definition RDF - probably by converting the examples to XML. Topic to be revisited in the next meeting or two.
Nick added Niklas’ scenarios for having a predecessor link on configuration resources. Niklas then talked through those scenarios, describing how a predecessor property enabled efficient calculation of differences/changes, and how that history needed to be preserved as configurations were assembled from other configurations. Having a configuration itself be a CI, with all the properties of a CI, would be the simplest way to achieve this. Nick questioned if this was possible for all CIs - consider ones that are instantiated such as using GEARS. Mike explained that they tracked the recipe for a configuration for this very reason.
Niklas suggested we add recipe to the terminology page; Nick to do so.
Provenance - we discussed use of the W3C provenance links vs. use of dcterms:replaces. That working group is now in final working draft status (get right terms here), so we can use it as a reference. The group should review and consider making recommendations on which predicates we will reference; to be followed up in the next meeting.
Gray, Nick and David to work on reconciling OSLC Core extension proposals vs. RELM product/part vocal.
Since Nick will be out traveling for the rest of the year, David will run the next three meetings, and has sent out invitations.
Minutes for 2012-11-13
Attending: Nick, Steve S, David, Steve Wasleski
- Given the light attendance, we deferred discussion of the RELM 1.0 RDF till next week.
- We discussed the use of the OSLC mailing lists. Nick has sent out a notice that the workgroup will from now on use only the newer oslc-configuration mailing list.
- We discussed the schedule for upcoming meetings. Nick will hold the meeting next week, Tuesday Nov 20, and will cancel the next three meeting invitations. David will later issue invitations for Nov 27, Dev 4, and Dec 11 (after participants have had a chance to react to the mailing list notice mentioned above). Nick will probably be back for the meeting on Dec 18.
- We talked about the need for a configuration predecessor property. The conclusion was that some providers kept track of a property of this nature, while others had no such concept. For this reason, if the workgroup decides that we want to define such a property, it would have to be optional, and important scenarios could not depend on it. Furthermore, it would not be worth defining even this optional property unless we had some convincing use case. The workgroup will consider such use cases in future meetings.
Minutes for 2012-11-01, rescheduled from 2012-10-30
Attending: Nick, David, Niklas, Peter, Mike
- We discussed the wg schedule, and agreed to move out some intermediate milestones, but keep the finalization end date unchanged
- We discussed the meeting schedule. We agreed to cancel next week (2012-11-06) because of VoiCE and vacations
- David will run some meetings later in the year while Nick is away
- We discussed Nick’s changes to terminology page - no objections
- Nick introduced and reviewed the document describing RELM 1.0 RDF
Actions:
- Workgroup members to review RELM 1.0 RDF document for discussion at next meeting
- Nick to fix broken link to that document
Minutes for 2012-10-16
Minutes for 2012-10-02
Minutes for 2012-09-25
Minutes for 2012-09-18
Minutes for 2012-09-11
Minutes for 2012-08-21
Minutes for 2012-08-14
