[oslc-ArchMgmt] Minutes from 15-Sept-2010 meeting

[James Conallen]

I've just posted the minutes from our meeting today:
http://open-services.net/bin/view/Main/ArchMgmtMeetings15Sep2010

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

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.


<jim/>

jim conallen
CAM Lead Architect
jconallen at us.ibm.com
Rational Software, IBM Software Group
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-am_open-services.net/attachments/20100916/6854f4ed/attachment-0003.html>