[oslc-ArchMgmt] OSLC AM 16-Feb-2012 meeting minutes

[James Conallen]

Today's meeting minutes are posted here:
http://open-services.net/bin/view/Main/ArchMgmtMeetings20120216

Minutes

In the OSLC AM domain resources are incredibly varied. There is no fixed
set of properties (literal or relations) that apply to all resources in
this domain. When performing impact analysis it isn't all that clear which
references indicate an impact and which do not.

One approach is to list and identify properties that can be defined for
resource types. With a full enough listing of properties an impact engine
could determine when one resources changes, which related resources are
also impacted.

Looking at the OSLC CM specification as an exemplar of a vocabulary, we saw
many relations of the form:
      relatedChangeRequest
      relatedTestCase
      relatedTestExecutionRecord
      relatedTestPlan
      relatedTestScript


where there was a verb, and some expectation of the type of resource on the
target end. We can interpret this to mean an expectation that the resource
on the target end of the link is a specific type. Or we can interpret this
to mean that from the source resource's point of view it considers the
target one of those types.

There was some concern over so many types of predicates that all basically
mean the same thing, but with different expectations of the type of
resource on the other end. We all agreed that we would rather have one
predicate (i.e. related ) and get the target type directly from the
resource.

We also noticed another pattern with predicates like:
      affectedByDefect
      affectsPlanItem


How the predicate is worded directly affects the impact analysis. For
example, if A is affectedByDefect B, then any change in B will impact A,
however the reverse is indeterminant. This means that if the target of the
relationship changes then the source is impacted.

On the other had with a relationship like A affectsPlanItem B. If B changes
it does not imply A is impacted, however if A changes then B is impacted.
Or if the source of the relationship changes the target is impacted.

It would be nice if all relationships were consistent (i.e. if the target
changes the source is impacted), however we can not garantee this.

After some discussion we came up with the following:
   1.	In general the default 'impact determiniation' of a relationship is
      that if the target changes, it impacts the source resource. If the
      source changes, it is undetermined if the target is affected.
   2.	If this is not the case then ontology writers should explicitly
      indicate that which direction impact is felt (i.e. both, neither,
      target to source, or source to target). We will investigate any
      existing RDFS or OWL mechanisms that do this.


This was a good discussion, and we hope the rest of the team will
contribute via the email list.


Thanks,

jim conallen
Rational Design Management (DM) Integration Architect, OSLC AM Lead
jconallen at us.ibm.com
Rational Software, IBM Software Group