Agenda

1. Jim will update workgroup on core activities.
2. Should this workgroup begin defining specific resource types and shapes (i.e. UML elements, service specifications, business processes, etc.)
3. Continue discussion of baselines, and Tom's scenarios.
4. Review definitions of terms we discussed last time.

Minutes

Attendees: Bob Maksmchuk, Brenda Ellis, Dan Berg, Peter Yee, Sandeep Kohli, Scott Bosworth, Tom Piccoli, Jim Conallen

1. Jim gave brief update of core activities
2. We started discussions on whether this workgroup should start providing URIs and shapes for common architecture resources (use cases, uml elements, business processes).

Scott started off by saying that it is not the job of the OSLC to define resources types and shapes but rather it is to facilitate integration. Let the definition of the types and shapes come from the other standards bodies (or vendors) that own them.

It was pointed out that from a user point of view (not AM provider), that what is wanted is a system that lets us link up architecture resources with other non-architecture resources, but also one that lets us do interesting things with them.

Jim said that today we don't even have an agreement on a common rdf type uri that represents Use Cases for example. Each vendor, each tool will potenitally define thier own URI type for a Use Case. Perhaps the AM workgroup could define a set of open-services.net based URIs for wel known and externally defined architecture resource types (Use Case, Sequence Diagram, ER model, Business Process, etc.) A next step would be to also define resource shapes for resources of these types.

It was questioned how even defining resource type URIs would help. Jim responded that a generic client, lets say one that specialized in ensuring that uses were tested, could go to all AM servers and ask for use case resources using this common rdf type URI, and then look at the resource links to see that it was tested by a test case. Without this common rdf type URI, that client would have to know all the possible rdf types that could represent a use case, and query each AM service for resources of that type, and then find links to test cases.

The definition of a rdf type for common architecture resources is only the definition of an open services based URI that references the resource type owned by the external body (i.e. OMG, W3C? , ...)

We had some discussion related to using the information in a resource, that is; understanding the semantics of a resource. It would be nice if I client could be coded with some expectations of the shape of common resource types (i.e. use case, etc.), so it could do interesting things with that resource.

Sandeep provided a great explanation of the OSLC, in that it is responsible for exposing specifics about resources when they cross domain boundaries, but not when they don't. So if the resources need to be known in other domains, then the OSLC (and AM) should be defining it. In response it was pointed out that the AM domain is broad, in fact very broad (high level business process diagrams, to low level schemas). Only defining resources that extend beyond this domain might be limiting.

Brenda bought up that from user's point of view there should only be exactly one of something. Meaning that a use case that might have begun life from System Architect, and then got worked on by Rhapsody, that there is only one use case. One URI, not multiple use cases each with their own URI linked together.

The discussion today was very active, and one of our more interesting ones. While we didn't come to any agreed consensus, I feel as though we started a very important discussion that we'll continue with next time.