Contents
Agendas and Minutes
Draft agenda for 2013-01-29
- Review minutes from last meeting
- Complete review of scenario, terminology, and resource definition pages, so that we can start writing draft spec in February
Draft agenda for 2013-01-22
- Review minutes from last meeting
- Go through comments on RELM Product Definition RDF examples
- Review terminology and resource definition pages
Agenda for 2013-01-15
- Review minutes from last meeting
- Review the ALM-PLM “System Engineer responds to Change Request” scenario to determine what CM capabilities are required or useful, how configurations and baselines might fit into the scenario, and what contexts might be applicable
- Review any feedback on other Configuration Management scenarios
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
Attending: David, Mike, Nick, Peter,
We discussed the changes to the terminology page. Mike questioned the last sentence of the concept resource definition: “Links are almost always established by using the URL of a concept resource – these are the URLs you almost always see in other resources”, saying that there are quite a few cases where one does want a version-specific link, and wondered if should should introduce terms for the types of link - perhaps precise and imprecise links? David mentioned there might be three types - fixed version, most recent version in some branch, and the concept resource which would give you the appropriate version for the context configuration. Nick mentioned that the definition was originally written in this way in order to encourage the use of the concept resource URI as the default kind of link - we do not want people using version-specific links too frequently, as that would bypass configuration management. Nick agreed to re-word the text to give better guidance.
On version skew: this topic needs some discussion in the ALM-PLM WG, and we need to revisit the proposed PLM product resource representation and compare it to that used by the RELM product.
We agreed the terminology page should mention “change set” - though we are not yet sure how to define that in a way that can generalize to many possible providers. Mike believes the terminology page should also define “merge”. Other terms that we might want to define, or explicitly decline to define: merge, variant, option, dimension, view, effectivity.
We started to discuss the revised Resource Definitions, but ran out of time, and it was too important to do quickly or casually. Nick wanted to be present at the continued discussion, but will be traveling next week, so the group agreed to cancel next week’s meeting, and to resume discussion on Oct 30th.
Actions:
- Nick to re-word concept resource URI link guidance
- Nick to create an issues page, and move issues from embedded notes in other pages to this new page
- Nick to send out a description of the RDF model used by Rational’s new RELM product, since that serves as an example of how to handle version skew
- Mike to check with the ALM-PLM WG, and look at other PDM tools, before agreeing that “revision” can be treated as a synonym for “version”
Minutes for 2012-10-02
Attending: Nick, John, Peter, David, Gray, Mike
- Nick thanked David for running the last two meetings. We then discussed the minutes of previous two meetings, so that Nick could catch up.
- Nick asked about baselines just being a set of resources with some tag, and suggested we should require such providers to construct a baseline resource to represent the results of a query over such resources - the idea being to keep configurations and baselines both pretty much the same resource type, to keep things simple. The group did not object to this approach.
- Nick mentioned that there were ways of implementing ‘Compare’ that did not require enumeration of baseline or configuration contents - we could just ask each provider to return an HTML page showing a difference, and not define a way to parse that returned value. However, such an approach would not satisfy all our use cases. Mike mentioned that a separate ‘release object’ could carry the structure information. We agreed to come back to the topic of enumerating the contents of a baseline or configuration on another day, as it was a complex subject.
- David mentioned that a link to the W3C provenance group has been added to the main page.
- We discussed check out , and agreed to make it optional - but we need to review the scenarios to ensure each one can be addressed whether or not checkout is provided.
- We then went on to discuss terminology. Gray mentioned we should be careful about defining resources vs. terms - e.g. version vs. version resource, where there is a difference.
- We agreed to remove baseline as a separate type - but keep it as a term to be defined. Baselines would be represented as configurations, and we would provide a state predicate (like in OSLC Change Management) to define immutability.
Actions:
- Nick to update the terminology page, and also the resource definitions to match.
- Nick to send out note to OSLC SCM and OSLC community about this group, inviting contributors.
Minutes for 2012-09-25
Attending: David, Mike, Gray
- We discussed the PLM Systems Engineering Scenario and the CM capabilities that this requires or implies. The Configuration Management Scenarios has been updated to include details of the points discussed.
- We discussed whether CM actions such as check out should be covered in phase 1, or whether users performed these actions in the underlying tool, perhaps with a delegated UI picker to create links between configuration items or configurations and other resources such as change requests.
- We discussed the need for versioning providers to support two types of resource URIs: absolute and composite (perhaps there is a better term?). An absolute URI always resolves to the same version of a resource. A composite is composed of a concept URI plus some context that the underlying versioning provider resolves to a particular version of that resource. This resolution may change over time. Examples of context might include effectivity for PLM tools, streams for SCM tools and so on.
- We discussed whether the term configuration item should be used. See Configuration Management Terminology for details.
Minutes for 2012-09-18
Attending: David, Mike, Steve S, Niklas
- Reminded everyone to sign the new agreement forms.
- We discussed the Incremental Development Using Baselines scenario. We discussed that some systems might not have baseline as a separate resource, rather it could be a collection of artifacts tagged with some unique baseline identifier. Mike stated that baselines were treated as configurations on a stub branch. We briefly talked about what other types of artifacts are linked. Mike stated that requirements were often held within PLM tools and could be viewed and compared as they can with product hierarchies.
- We discussed Compare Baselines scenario. We discussed that one of the more important aspects of this can be determining the set of changes included in a baseline compared with some previous baseline. Also different processes might be used for this, sometimes aggregating change details from low-level artifacts to a higher level artifacts in order to make querying and reporting easier and more efficient making the predecessor property important. Mike mentioned that they also report on change requests, but they don’t call this a baseline compare.
Particular releases might have a BOM (Bill of Materials), and they can perform a comparison of BOMs. This scenario needs further development since the types of reporting and traceability is not yet described.
- We discussed how incremental development tracked changes that applied to multiple versions of a product or system. Mike stated that change requests tended to apply to a particular product version and documented the effectivity of the change - such as a date or serial number in which the change should be delivered.
- We briefly discussed predecessor/successor relations. Steve stated that the W3C WG on provenance had made some good progress. It would be useful to add a link to that W3C WG from the CM Wiki. This relates to the PLM WG proposals for core using a vocabulary of dcterms:isVersionOf and dcterms:replaces.
- We agreed that it would be useful to review scenarios from the PLM WG to see which aspects might be useful in developing CM WG scenarios.
- We discussed whether issues, comments, and questions should be edited on the scenarios page(s), or on separate pages. Steve mentioned that both practices are commonly used, but early discussion tends to be on the same page as the topic. We agreed to keep the scenarios as a single page for the moment, but it will probably benefit from splitting into several pages as the content expands.
Minutes for 2012-09-11
Attending: Nick, David, Mike, Steve S, Sandeep, Sampath, Peter, Niklas
- We discussed the current state of the OSLC Configuration Management workgroup: the rechartering has been approved by the Steering Committee.
- Nick said that the wiki has been migrated to the new wiki, and asked all members to sign revised the OSLC and workgroup participation agreements.
- Nick mentioned a suggestion that members post short workgroup member descriptions/bios on wiki; another member commented that the new wiki already allowed for that - each member has a wiki page of their own created automatically when they sign the participation agreement forms, and that page has a place for a bio. We agreed that members should post a short bio of themselves - Nick has done so, and has also added a photo.
- Nick went through the slightly revised Configuration Management Terminology page, where the group agreed that we needed to define (or specifically decline to define) version, version skew, revision, and branch - but we did not take the time to define those terms in the meeting.
- We also went through the new Configuration Management Resource Definitions page, but did not have time for any development of that page.
Minutes for 2012-08-21
Attending: Nick, David, Mike, Steve S, Sandeep, Gray, CJ Paul, Niklas, Cheryl, Kartik, Peter
- We first discussed the idea of having alternate meetings at a different time. From the Doodle poll, the best alternative was at 11am US/Pacific on Wednesday, but this was very late for everyone in Europe. After a very brief discussion, the group agreed to leave the current time (Tuesday 6am) for all meetings.
- CJ Paul and Cheryl from Tivoli introduced themselves as new members of the group.
- Nick reminded group members to add their names to the Configuration Management home page on the wiki, and to the OSLC SCM mailing list. Nick and Steve will review whether this group will continue to use that SCM mailing list, or create a new one.
- We then continued the review of configuration management and baseline scenarios, starting with ‘control the use’ - Nick and Mike elaborated the proposal for separate status/workflow objects, trying to keep baselines truly immutable. Steve made the point that with RDF, a provider cannot guarantee true immutability of a resource, since any provider can make new assertions about any resource simply by including a triple with that resource as its subject.
- Nick agreed to write a draft suggestion for the separate workflow idea, send this to Mike for review, then forward to Config Mgt, PLM, and Change Mgt workgroups for discussion.
- Nick walked through the ‘high ceremony requirement-driven development’ scenario. Mike commented how again much of this was process / workflow, and effectivity. Nick agreed, but pointed out how there were some important configuration management aspects: the ability to create configurations from scratch, the ability to create configurations that included, referenced, or depended on other configurations, the ability to freeze/snapshot a configuration, and the ability to have links in the context of a configuration.
- Sandeep suggested we need to define the terminology - and to do so in terms of specific RDF vocabulary definitions, so it would not just be ambiguous English. Nick thought that scenario elaboration and terminology / RDF vocal development had to occur somewhat in conjunction with each other, but agreed that now we had reviewed all the original use cases, it was time for a pass on terminology and vocabulary. Nick undertook to start a draft vocabulary definition on the wiki, and the group would review this draft and the terminology page next week.
Minutes for 2012-08-14
Attending: Nick Crossley, Niklas Larsen, Sandeep Kohli, Mike Loeffler, Peter Hack
- Nick asked all participants to add their names to the Config Mgt wiki.
- The group than reviewed the scenarios, starting with the primary scenario of a cross-tool, cross-domain baseline.
Mike: baseline creation is like release process - it has a workflow, many people participate, and the release is built up and then snapshotted at some time.
- Sandeep asked if we need closure of links - how do we decide what is part of a config. Nick: a baseline certainly needs to have enuerable contents, potentially found through delegation to the underlying providers. A modifiable configuration might need enumeration of contents, though is not yet completely clear. Mike - a baseline should be just a frozen config.
- Mike - not sure about having any modifiable props on baseline - prefer to handle this by having other modifiable resources for workflow process that point to baselines. Mike volunteered to demo this in PLM context, probably a bit later when more of the group was back from vacation.
- Mike also brought up the topic of variability and effectivity; we need to see how those concepts fit in with configurations, baselines, and their properties.
- Nick asked participants to review old Core workgroup baseline proposals, to see two different past approaches - even though neither of them may be quite what we want today.
Meeting Logistics
Nick Crossley will normally host the telecons. Here are the details.
Participant passcode: 73872710#
For the meeting on 27th November, 4th December, and 11th December, David Honey will host the telecons. The participant passcode for these three 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.
