[oslc-rm] Adding new predicates to the RM specification

[Ian Green1]

On our recent biweekly calls there has been some discussion around 
scenarios that can be best described as "RM-to-RM" scenarios.  By this I 
mean two RM applications with traceability between them.  These two RM 
systems may be instances of the same product, or could be different 
products.  The particular scenario we we're looking at is described at 
[1].

One of the reasons that this scenario cannot be satisfied currently is 
that the elaboration relationship (oslc_rm:elaboratedBy) is one-sided. 
There is no oslc_rm:elaborates that can be used to link to other 
requirements in some other system.

 A simple suggestion is to extend the vocabulary with oslc_rm:elaborates.  
  There are of course other RM-to-RM relationships that are as important - 
for example, "satisfaction", "decomposes" etc.

There are two issues here that I would like the workgroup to consider:

(1) We can never have a complete list of all interesting relationships 
that are relevant to RM.  We've discussed this frequently enough in the 
past, and have always conceded that would be able to make progress with a 
simplistic approach (to enumerate the link types in the specification).

My view here is that whilst we ought to consider a means to create new 
link types (OSLC Property creation, perhaps) we can also look for some 
symmetry in the link predicates that we've defined.  This would involving 
introducing new terms:

        oslc_rm:elaborates
        oslc_rm:specifies

that correspond to existing predicates oslc_rm:elaboratedBy, 
oslc_rm:specifiedBy.   The other predicates (affectedBy, trackedBy, 
implementedBy and validatedBy) look like less of a priority since they are 
more obviously not RM-to-RM, but we could consider adding those too.

(2) Paul pointed out that the behaviour of query over RM-to-RM links may 
require some clarification.  The scope of OSLC Simple Query is not 
required to span service providers.  Links from resources in one provider 
are not required to be accessible to query at some other provider.  For 
links which naturally cross providers (RM-to-CM, RM-to-QM and so on) this 
query "fault line" is not entirely satisfactory but it is understandable 
to clients.  With RM-to-RM links, the fault line is no longer so obvious, 
because the link type is not so obviously going across a provider.

My personal view on (2) is that RM 2.0 clients should not be assuming that 
the currently specified link types are "cross-provider" (indeed, we took 
care not to bake such a constraint into the specification).  Thus a simple 
query involving "elaboratedBy" could in fact be entirely within a service 
provider (requirement elaboratedBy requirement).

(3) We would like there to be a way to bring these new predicates into the 
community .  Our discussions touched on the idea of extending the RM 2.0 
specification (in a backwards compatible way), rather then having to wait 
for an RM 3.0 specification.  I'll fire this question to the OSLC core 
mailing list and see if there is preferred way to do this.


[1] 
http://open-services.net/bin/view/Main/RmElaborationBusinessRequirements


best wishes,
    -ian

ian.green at uk.ibm.com (Ian Green1/UK/IBM at IBMGB)
Chief Software Architect, Requirements Definition and Management
IBM Rational





Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-rm_open-services.net/attachments/20110907/13f51cbd/attachment-0003.html>