Agenda

1. Jim will update workgroup on core activities.
2. Continue discussion of baselines, Tom and Dan B's scenarios.
3. Look at changes to definitions Jim made in response to previous meetings discussions, and documents/images Jim posted here.

Minutes

Regrets: Bob Maksimchuk

Atendees: Sandeep Kohli, Scott bosworth, Tom Picolli, Dan Leroux, Dan Berg, Clyde Cuspit, Peter Yee, Jim Conallen

1. Sandeep pointed out that so far in our dicusssions of context there is nothing AM specific. Scott pointed out that some of the definitions used by the RM workgroup, for baselines in particular conflict with ours. The RM use of baseline implies that resources in it can change, and that a baseline is more of a container than a frozen set of resources.
2. Tom mentioned we should be able to lock resources.
3. Clyde askd about the lifecycle of a baseline. Jim said that we should try to keep the concept of a baseline (or context in general) simple.
4. Dan L. pointed out that in the AM domain we have a issue with transitive closure.
5. Scott asked if our concept of a baseline or context implied a copy of resources. The team immediately countered that no, something like that is up to the individual service provider, siting System Architect's example of only cpoying when a delta is made as an example.
6. There was some concern about the need to calculate the the resources in a baseline or context.
7. Scott pointed out that the OSLC project context is embedded in a resource definition (service provider property). Should the baselines it is in also be embedded in the resource representation. Most of the team did not like this idea.
8. Scott suggested that we write downt the needs/motivations for this to better understand them.