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

[Vasaiely, Parham]

Hi AM team,

Impact analysis is of course one use case where we need fixed resource
types, but when thinking about tools interoperability (spec. exchanging
of information between tools from the same domain), we need also a fixed
set of resource types. Obviously we need to divide the AM domain first
in all its sub-domains. Was there already an approach to do this?

Best Regards,
Parham Vasaiely

EADS Innovation Works UK
Engineering & Architecture, Software and Systems Engineering



> -----Original Message-----
> From: oslc-am-bounces at open-services.net [mailto:oslc-am-bounces at open-
> services.net] On Behalf Of James Conallen
> Sent: Thursday, February 16, 2012 8:09 PM
> To: oslc-am at open-services.net
> Subject: [oslc-ArchMgmt] OSLC AM 16-Feb-2012 meeting minutes
> 
> 
> 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
> 
> 
> 
> _______________________________________________
> Oslc-Am mailing list
> Oslc-Am at open-services.net
> http://open-services.net/mailman/listinfo/oslc-am_open-services.net