[oslc-rm] Discussion during today's bi-weekly call - link naming

[Ian Green1]

During today's call there was an interesting discussion on the RM resource 
model.  (I don't pretend here to have summarized the discussion.)

In 1.0, we had fairly general relationships between requirements and other 
resources. For example, "validatedBy" was motivated by a scenario in which 
a requirement was validated by a QM resource.  The QM resource was 
considered to be a "test case".   A related scenario used "validatedBy" to 
capture a similar relationship between a collection of requirements and a 
test plan.  We discussed other forms of validation (indeed, there was a 
call, during 1.0 effort, to call the relation "qualified by" since that is 
often recognised as more general that "validated by".  (Please put to the 
back of your minds thoughts that it should be "verified by", since here 
I'm making a different point - one of generality.)

Of course the RM workgroup did some thinking about the names of relations: 
we produced [1].

OSLC RM 2.0 formally specifies the names of these relations - they are 
part of the spec., and the names are important.  The QM and CM workgroups 
[2,3] have adopted a style of naming which we need to consider adopting in 
RM.  There are also ramifications for OSLC generally that we might 
consider.

The naming convention is to include in the type of the object resource in 
the name of the predicate.  So for example, QM has "validatesRequirement" 
and "validatesRequirementCollection".  The former is from a test case to a 
requirement, the latter from a test plan to a requirement collection.  In 
addition to naming, OSLC specifications have also introduced a "range" 
specifier, in the specification and in the OSLC Shape resource, which 
describes what type of resource is at the other end of such a link.  For 
these examples, it's "Requirement" and "RequirementCollection". 

With this design, we have a number of issues, I think:
        - the number of predicates grows exponentially in the number of 
resources.  I can't judge if this will impact OSLC in a practical way.
        - the names are suggestive/indicative of an unstated (?) contract 
that OSLC providers may not be aware of, or want to offer.  This might be 
an onerous contract.
        - consumers use this denormalized data to avoid fetching/querying 
the resource. 
                - does an authority have to check that nothing breaks this 
invariant
                - does it prevent the resource from changing type (eg a 
test case changes into a test plan)
                - a client does not have access to the richness of the 
model - a resource may have more than one type (for example, a requirement 
may also be a model element)

Consistency suggests that RM follows the draft CM and QM specs in this 
regard ("implementedByChangeRequest", validatedByTestCase) etc.  But my 
feeling is that consistency should not compromise our design.  I'm minded 
to use the more general predicates:  "implementedBy", and "validatedBy", 
and to leave the "range" as unspecified.

Clients wanting to establish the type of the resource at the other end of 
a link can GET that resource, or they can query for the type of the 
object, and react accordingly.   Looking at the name of the predicate or 
the range specifier in the spec. is fragile, and almost bound to break in 
the future, and/or limit the extent to which OSLC can reuse these 
vocabulary terms, or to unnecessarily narrow their interpretation. 

I don't believe that any such decision by RM on this topic will affect the 
other OSLC workgroup specifications, or be conflicting with the OSLC Core.

Any reactions?

[1] http://open-services.net/bin/view/Main/RmDiscussionLinkTypes
[2] http://open-services.net/bin/view/Main/QmSpecificationV2
[3] http://open-services.net/bin/view/Main/CmSpecificationV2

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