History   View   Links to this page 2013 September 4 | 04:43 pm

Author: Arthur Ryman

Last modified: 2013-09-04

Status: Proposed addition to OSLC Core V3.0

Introduction

This document proposes two new RDF annotation properties that are intended to be used in RDF vocabulary documents. These proposed properties annotate other RDF properties. They are designed to improve the user experience, for example, when building SPARQL queries. The use cases that motivated this vocabulary come from requirements for a SPARQL query builder.

This vocabulary is proposed as an extension to the OSLC Core vocabulary which has the following URI:

http://open-services.net/ns/core#

Inverse Labels - oslc:inverseLabel

This topic was previously discussed in the 2006 blog post: An RDF design pattern: inverse property labels by Richard Cyganiak who cites a 2006 blog post: Backward and Forward links in RDF just as important by Tim Berners-Lee. Both of these posts discourage the creation of inverse predicates, but bemoan the absence of a property, like rdfs:label, to specify an inverse label for a predicate. One commenter wrote: “Give the damned inverse-properties a URI already!”. That is exactly what oslc:inverseLabel is.

The W3C RDF Schema vocabulary defines the vocabulary annotation property rdfs:label. This property is intended to provide a human-readable description for a resource’s name. It is often used to provide a label for RDF properties.

For example, consider the OSLC Requirements Management (RM) property oslc_rm:validatedBy. When used as the predicate of a triple, this property is used to assert that the subject resource, e.g. a requirement, is validated by the object resource, e.g. a testcase. The rdfs:label for this property is “validatedBy”.

Now consider the user interface of a query builder that allows users to build queries about testcases. It is natural for the query builder to present the user with a list of the properties that apply to testcases. Suppose the user wants to build a query that returns all that requirements that are validated by a testcase. The query builder should describe the available properties from the point of view of the testcase. This implies that the query builder should describe the inverse relation asserted by any triple that has the testcase as an object. In our example, the query builder should describe oslc_rm:validatedBy as “validates”.

The oslc:inverseLabel property provides a human-readable label for the inverse of the subject property.

For example, the following triple (in Turtle notation) would be added to the OSLC RM vocabulary:

oslc_rm:validatedBy oslc:inverseLabel "validates".

It should be noted that the use of inverse labels is independent of the existence of explicit RDF inverse properties. However, if an inverse property is defined by some vocabulary, then a consistent label should be used in order to avoid confusion. In general, it is good practice to avoid the creation of inverse properties since it complicates SPARQL queries. Instead, a single property should be wherever possible and it should be given an inverse label.

For example, the OSLC Quality Management (QM) vocabulary defines two properties that are approximately inverse to oslc_rm:validatedBy. These are oslc_qm:validatesRequirement and oslc_qm:validatesRequirementCollection. In this case the choice of inverse label “validates” for oslc_rm:validatedBy is consistent with the actual labels of the inverse properties, namely “validatesRequirement” and “validatesRequirementCollection”.

Traceability and Impact Type - oslc:impactType, oslc:UpstreamImpact, oslc:DownstreamImpact, oslc:SymmetricImpact, oslc:NoImpact

Some RDF properties express dependency relations between artifacts, and it is often very valuable to trace the impact of a change in an artifact to those artifacts that depend on it directly or indirectly. The concept of dependency is very general. For example, the concept of trace relations is described in SysML: “A generic trace requirement relationship provides a general-purpose relationship between a requirement and any other model element. The semantics of trace include no real constraints and therefore are quite weak.”

As a general guideline, if any triple that uses a given predicate may become invalid if the state of either its subject or object resources change, then we may legitimately regard that predicate as expressing a dependency relation, in which case it may be useful to explicitly describe the nature of the dependency.

In a dependency relationship, the dependent resource is said to be downstream from the artifact it depends on. The artifact it depends on is said to be upstream from the dependent artifact. This terminology reflects the normal flow of work in the sense that artifacts flow downstream where new dependent artifacts are created.

For example, a requirement is said to be upstream from a testcase that validates it because the requirement is normally created before the testcase. Of course, it is possible that the testcase gets created first and then the requirement is abstracted from it. However, the conceptual relation between requirements and testcases is that requirements are prior and drive the creation of testcases.

The property oslc:impactType asserts that the subject property is a dependency relation and gives the direction of impact. The resources oslc:UpstreamImpact and oslc:DownstreamImpact identify the upstream and downstream directions. In addition, oslc:SymmetricImpact describes a symmetric dependency relation in which there is no clear upstream or downstream direction. Finally, it may in some cases be useful to assert that two artifacts are independent. The latter is described using oslc:NoImpact.

For example, the following triple (in Turtle notation) would be added to the OSLC RM vocabulary:

oslc_rm:validatedBy oslc:impactType oslc:DownstreamImpact .

The following triples would be added to the OSLC QM vocabulary:

oslc_qm:validatesRequirement oslc:impactType oslc:UpstreamImpact .
oslc_qm:validatesRequirementCollection oslc:impactType oslc:UpstreamImpact.