This wiki is locked. Future workgroup activity and specification development must take place at our new wiki. For more information, see this blog post about the new governance model and this post about changes to the website.

Standardised OSLC Link Types

This page is defunct. The effort has moved to OSLC Core. Please see OSLCCoreLinksDRAFT.

Background

This document describes standard link types used in OSLC specifications.

It was initially prepared for discussion purposes in response to an action from the RM OSLC meeting on 7 September 2009, and was later updated in an effort to document the RDF vocabularies currently in use in some OSLC implementations, and to additionally include those link types being considered by OSLC workgroups during 2010.

OSLC believes that scenarios shall be used to motivate its specification efforts. This document describes the relationships that have been discussed and motivated during the scenario development that has taken place as part of the workgroup efforts.

How do workgroups get relationships added to this OSLC document? How do domain specifications reference the properties that they support - for example, the RM V2.0 specification should refer to the "manages" relationship, indicating that a requirement resource may contain zero or more "oslc:managedBy" OSLC Properties.

Scope

In real world applications, links may be formed between any lifecycle artefacts. This suggests an ultimate need for a uniform mechanism for managing link resources across all OSLC domains, but this is not an achievable objective at this early stage in the OSLC initiative.

Naming Link Types

Our first interest is in the semantics of the relationship that is being considered. In OSLC, relationships are modelled with two links: a forward link and a back link. These links are described in accordance with the OSLC Core specification in terms of "OSLC Properties": an OSLC Property for each of the forward and back links.

Naming is an emotive subject, because there is very little consensus about what to call relationships: while we may agree on what the common relationships are, we may find it very difficult to agree on how to name them. This issue alone may threaten the standardisation of link types at OSLC.

Recognising this risk, the labels used in the table below have been chosen to be precise and meaningful, but seek to avoid as far as possible scope for misunderstanding or ambiguity. For example, the term 'qualify' is used rather than 'verify' or 'validate' (since the terms 'verify' or 'validate' are sometimes used loosely, sometimes used with very precise meaning, and sometimes understood in one environment to have exactly the opposite meaning that they have in another environment).

From another perspective, it is conventional (and beneficial) to consider links to be directed (i.e. from source to target), and to name them accordingly. Hence, a relationship between two requirements, A and B, might be expressed as 'A satisfies B'. This means that there is an implicit 'reverse' relationship between B and A - namely 'B is satisfied by A'. The table below identifies both 'forward' and 'reverse' labels.

We include "role names" as suggested labels to be used for forwards and backwards sense of these relationships.

Design Issues (open)

Should relationships be specific to the motivating scenario, or should they more general? Do we anticipate a reusable vocabulary?

Example: is the relationship between a test case and a requirement a "qualification relationship", or is it a "test case verifies a requirement"?

One view is that this specialization makes reporting and query easier - the denormalization of the type into the property makes query possible over local data.

An opposing view is that such specialised vocabularies are less reusable. Additionally this specialization leads to coupling between domains. For example, a requirement could be qualified by many kinds of resource (eg theoretical, comparative, tests, etc.) and consumers of that requirement resource should be flexible to the kind of qualification resource that is actually present. the

Common OSLC Link Types

The following table summarises link types that are potential candidates for standardisation. This includes only those relationships that are found most commonly and consistently in the RM domain. In addition, the list only includes relationships that have a requirement as the source or target (e.g. relationships between test results and test cases are considered to be outwith the RM domain). Despite this, the list may be incomplete.

Namespaces

OSLC Relationships

The following table summarises the relationships which have been part of scenario development at OSLC.

How to OSLC Domain specifications reference/include these properties in specifications?
This table could be better described in the resource model. See RmRelationships for thoughts on that.

Relation Link Property Back link Property Type (can we do without this?) Description/Example References
implementation oslc:implements oslc:implementedBy Change Request implements Requirement Asserting the Change Request which implements a Requirement.  
qualifies oslc:qualifies oslc:qualifiedBy Test Case qualifies Requirement Asserting the Test Case or Test Plan which validates a Requirement or Requirement Collection.  
blocking oslc:blocks oslc:blockedBy Resource is impeding progress on another resource Asserting the Change Request which blocks the execution of a Test Case.  
manages oslc:manages oslc:managesRequirement Change Request manages Requirement Asserting the Change Request which governs the evolution of a Requirement. CmSpecificationV2
affects oslc:affectsTestCase oslc:affectedBy Change Request affects Test Case Asserting Change Request which affects a Test Case. CmSpecificationV2

OSLC Relationship * Candidates *

The following table summarises the relationships which have not yet been fully considered by OSLC. They are here as placeholders for future efforts. When the meaning of these relationships has been elaborated and justified by scenarios, they can become "OSLC Relationships".

Relation Link Backlink Type Description Reference
satisfaction unknown:satisfies unknown:satisfiedBy Requirement satisfies Requirement Asserting satisfaction in requirement decomposition  
elaboration unknown:elaborates unknown:elaboratedBy Model elaborates Requirement Elaboration of a requirement with a model arefact RmRequirementElaboration
realization unknown:realizes unknown:realizedBy Design realizes Requirement Asserting satisfaction in design decomposition  
allocation unknown:allocatedTo unknown:allocatedIn Requirement allocated to Design Allocating requirements to design structure  
supports unknown:supportedBy unknown:supports Requirement to supporting information Providing information needed to support or interpret a requirement  
affects unknown:affectedBy unknown:affects Requirement to issue Identifying issues that affect a requirement  
mitigates unknown:mitigatedBy unknown:mitigates Risk to mitigation Identifying artefacts which mitigate a risk  
Topic revision: r13 - 27 May 2010 - 11:48:50 - IanGreen
 
This site is powered by the TWiki collaboration platform Copyright � by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Contributions are governed by our Terms of Use
Ideas, requests, problems regarding this site? Send feedback