Agenda

1. Jim will update workgroup on core activities.
2. Continue discussion from last time about whether this workgroup should begin defining specific resource types and shapes (i.e. UML elements, service specifications, business processes, etc.)
3. If time permits continue discussion of baselines, and Tom's scenarios.

Minutes

Attendees: Brenda Ellis, Dan Berg, John Crouchley, Peter Yee, Scott Bosworth, Tom Piccoli, Jim Conallen

Regrets: Vishy Ramaswamy, Bob Maksimchuk

Jim updated the workgroup with Core activities (see core workgroup meeting minutes)

The workgroup continued it discussion of whether it should be defining URIs for common architecture resource types (just the URI, not the shape, the definition of the shape will be the next discussion).

Dan B. and Jim C. both expressed agreement that we should be defining URIs for well know architecture resource types. These uris would be used by clients to just identify the type of the resource, not the shape. It will allow clients to do some level of interesting things with the links to those resources. Scott was asked to play the devils advocate and suggested that we flesh this out a little more. Jim agreed to start a new wiki page where we can all put candidate URIs for architecture resource types. Next meeting we can look over this list and vet it to see if it will be useful.

There was some discussion on versioning of these URIs, and it was agreed that the general guidance of the OSLC is appropriate; only add stuff, don't redefine or remove anything. Future specs can deprecate things.

Jim raised a concern that we should not go too far in defining these URIs, to the point where we are defining constraints at the URI level (i.e. an http://open-services.net/ns/am#operation can't also be a http://open-services.net/ns/am#property).

The topic of baselines popped up again (a topic near and dear to Brenda's heart) in relation to how it might affect granularity of the URIs we define. It was agreed that the topic of baselines needs to be brought up at the core level, and that it is a cross cutting concern. In the meantime we will continue to work on it, and work towards ensure compatibilty with the SCM concept of baselines, and any results the core might come up with.