[OSLC-RM] Link types
Simon Wills
simon.wills at integrate.biz
Wed Oct 7 07:46:55 EDT 2009
Hi
I think that there are three distinct issues here, namely:
a. Whether there is a need for a uniform approach to defining link-related resources across OSLC;
b. Whether we attempt to define a minimal set of standardised link types;
c. Assuming that we *do* adopt a uniform approach to linking across OSLC, how and when we do so.
Of these points, deciding whether or not to implement a uniform linking model is by far and away the most important. Standardising link labels is a ‘nice to have’ that follows on from this first decision (this was the main focus of the RM discussion document), but is something that we can live without. And the last point is to do with implementation.
Ben’s interests (i.e. reporting) provide a good illustration of the key issue. If I understand correctly, he wants to be able to generate reports about lifecycle artefacts, some of which may require him to traverse links between artefacts, without having to make allowances for the domains in which those artefacts live. This seems to me to be entirely reasonable – and reporting isn’t the only domain for which this expectation holds.
OSLC stands for Open Services for Lifecycle Collaboration. Lifecycle collaboration requires that we leverage relationships between lifecycle artefacts. If we don’t tackle the issue of uniformity in the handling of links, we risk ending up with a series of poorly connected domain islands, each with its own domain-specific linking paradigm. Surely there is a prima facie case to recognise that links are the things that tie these domains together, and hence that the definition of link-related resources and their behaviour should be common across all OSLC domains?
Best regards
Simon
From: oslc-rm-bounces at open-services.net [mailto:oslc-rm-bounces at open-services.net] On Behalf Of Ian Green1
Sent: 07 October 2009 11:39
To: James Conallen
Cc: oslc-rm at open-services.net
Subject: Re: [OSLC-RM] Link types
Hello Jim,
I think your description of how OSLC links currently work in the defining of a relationship is accurate. There has been some discussion about the merit of such a design, since it is exposed to a fragility, namely, that for each link, there should be a corresponding link in the other direction. The need for the "backlink" as it has been called, aids navigability (we typically want the relationship to be navigable in both directions). It is also reasonably easy to implement.
The fragility is maintaining this invariant: for example, when a resource is deleted, any "backlinks" to that resource should be removed. There are other "relationship management" designs which don't have this weakness.
My reading of Simon's document is that it is talking about these relationships, rather than the lower-level "nuts and bolts" of how one resource links to some other resource. We need to think about how we can uniformly manage these relationships across all the domains.
best wishes,
-ian
ian.green at uk.ibm.com (Ian Green1/UK/IBM at IBMGB)
Chief Software Architect, Requirements Definition and Management
IBM Rational
From:
James Conallen <jconallen at us.ibm.com>
To:
Benjamin Williams/UK/IBM at IBMGB
Cc:
Ian Green1/UK/IBM at IBMGB, oslc-rm at open-services.net
Date:
06/10/2009 16:44
Subject:
Re: [OSLC-RM] Link types
________________________________
I have one concern about the link types document's attempt to define *both* the forward and reverse links. I believe that the general OSLC mechanism for creating bi-directional links is to create two unidirectional links managed by each server, and hope that it is possible with a query on the other server to find the right back link when deleting.
If this is the case, then we should probably restrict the definition of the link types to those that are managed by the OSLC RM implementing service, and not make assumptions that all the other services (i.e. OSLC CM, OSLC AM, OSLC QM, ...) will support these OSLC RM defined link types.
In the OSLC AM space our scenarios have all sorts of link types that are referenced. For example a model element can implement a requirement, or specify a requirement, or a requirement resource can be documentation (i.e. how to guide) for a model element. Given that both models and requirements can be used in many different ways, it is hard to pin down, generically, just a few relationship types between AM resources and requirements. With this said, if we just say that links from Requirements to Architecture Management Resources will be one of (modeledBy, realisedBy or incorporatedBy) that will be fine from an OSLC AM client point of view.
<jim/>
jim conallen
jconallen at us.ibm.com
Rational Software, IBM Software Group
Benjamin Williams ---10/06/2009 10:22:09 AM---Ian As per my other email on reporting, I feel that such such collaboration
From:
Benjamin Williams <bwilliams at uk.ibm.com>
To:
Ian Green1 <ian.green at uk.ibm.com>
Cc:
oslc-rm at open-services.net, oslc-rm-bounces at open-services.net
Date:
10/06/2009 10:22 AM
Subject:
Re: [OSLC-RM] Link types
Sent by:
oslc-rm-bounces at open-services.net
________________________________
Ian
As per my other email on reporting, I feel that such such collaboration and consistency across domains will be extremely important, if not absolutely necessary.
Specifically in the context of reporting, the features exposed by service providers across each domain will need to (consistently) support the requirements and use-cases defined in the Reporting domain such that reporting consumers can leverage lifecycle data without needing any knowledge of the source domains and any differences in the way they expose data.
The scenarios and use-cases that we are defining in the reporting domain should be entirely domain agnostic, as far as I am concerned. We can use specific examples for both single domain reporting as well as cross domain reporting, but the domains used in the examples should be freely interchangeable without any impact on the reporting consumer.
The reporting domain is still in its infancy, and my involvement in OSLC is only just beginning, but from what I understand, the reporting domain might be one of the first things to force us to think about some of the cross domain issues that you and Simon have discussed.
/Ben
-----------------------------------------------------------------------------
Benjamin Williams
Senior Product Manager - Rational Publishing Engine
Email: bwilliams at uk.ibm.com
Tel: +44 20 8818 4360
Cell: +44 7710 637 067
IBM Extension: 364360
IBM ITN: 37364360
-----------------------------------------------------------------------------
From:
Ian Green1/UK/IBM at IBMGB
To:
"Simon Wills" <simon.wills at integrate.biz>
Cc:
oslc-rm at open-services.net
Date:
06/10/2009 14:16
Subject:
Re: [OSLC-RM] Link types
Sent by:
oslc-rm-bounces at open-services.net
________________________________
Hello Simon,
this is good progress both on explaining our current position w.r.t. link types, and also taking a longer term view of the role we see link types playing the future. Thanks very much for putting this together.
Steve/Scott: whilst there is no pressure as yet to drive this forward, Simon makes a good case for any such effort to be cross-OSLC domains. How do you see this shaping up over time? Is there some tension between designing an OSLC-wide vocabulary and being entirely scenario-driven?
best wishes,
-ian
ian.green at uk.ibm.com (Ian Green1/UK/IBM at IBMGB)
Chief Software Architect, Requirements Definition and Management
IBM Rational
From:
"Simon Wills" <simon.wills at integrate.biz>
To:
Ian Green1/UK/IBM at IBMGB
Date:
05/10/2009 15:42
Subject:
Link types
________________________________
Hi Ian
Just to let you know ... I’ve put a new section titled ‘Discussion Topics’ in the right hand sidebar of the main RM page, and put a link to a discussion document on link types (at http://open-services.net/bin/view/Main/RmDiscussionLinkTypes <http://open-services.net/bin/view/Main/RmDiscussionLinkTypes> ). Haven’t quite sussed out how to format tables properly in the Wiki editor, but the content is all there.
Would you like me to put out an announcement on the mailing list?
Cheers
Simon
________________________________
Simon Wills
Managing Director
integrate systems engineering ltd
m: +44 (0)7967 091824
t: +44 (0)1225 859991
f: +44 (0)1225 859993
e: simon.wills at integrate.biz
w: www.integrate.biz <http://www.integrate.biz/>
________________________________
________________________________
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
_______________________________________________
OSLC-RM mailing list
OSLC-RM at open-services.net
http://open-services.net/mailman/listinfo/oslc-rm_open-services.net <http://open-services.net/mailman/listinfo/oslc-rm_open-services.net>
________________________________
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
_______________________________________________
OSLC-RM mailing list
OSLC-RM at open-services.net
http://open-services.net/mailman/listinfo/oslc-rm_open-services.net <http://open-services.net/mailman/listinfo/oslc-rm_open-services.net>
________________________________
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/20091007/9d652beb/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 105 bytes
Desc: image001.gif
URL: <http://open-services.net/pipermail/oslc-rm_open-services.net/attachments/20091007/9d652beb/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.gif
Type: image/gif
Size: 45 bytes
Desc: image002.gif
URL: <http://open-services.net/pipermail/oslc-rm_open-services.net/attachments/20091007/9d652beb/attachment-0001.gif>
More information about the Oslc-Rm
mailing list