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: http://open-services.net/xmlns/oslc/1.0#

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