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

[Steve K Speicher]

Jim,

Sounds like a good discussion.  I'd like to make some observations as 
well, included below.

Thanks,
Steve Speicher | IBM Rational Software | (919) 254-0645

> From: James Conallen/Philadelphia/IBM at IBMUS
> To: oslc-am at open-services.net, 
> Date: 02/16/2012 03:19 PM
> Subject: [oslc-ArchMgmt] OSLC AM 16-Feb-2012 meeting minutes
> Sent by: oslc-am-bounces at open-services.net
> 
> 
> 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.

The choice of predicate names within CM 2.0 was done based on a number of 
scenarios and little naming guidance, or experience, at the time.  If 
redone today, may have similar model you describe to remove the type from 
the name.  The idea what as you stated, from the point of view of the 
source, the related item is that "kind" of resource (whether it has an RDF 
representation or not, and if so, does it have a rdf:type and it is a 
known type? etc, etc).

> 
> 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.
> 

These approaches also depend on the requirement that both ends of the link 
be represented in RDF and that an application has the appropriate rights 
to insert the right end of the relationship (write to source vs. target). 
In cases like this, I can see where predicates of the forward and inverse 
makes sense.  Just depends on the design constraints and the scenario 
being supported.