OSLC Configuration Management defines an RDF vocabulary and a set of REST APIs for managing versions and configurations of linked data resources from multiple domains.


The specification:

While the scope of this specification does not include all of [[ITIL]] or [[ITSM]], a configuration as defined by this specification shall be able to contain or reference a set of Configuration Items (CIs) and their specific versions, and hence participate in the Identification, Control, and Monitoring activities of ITIL.



Any software development project team creating anything but the simplest, short-lived solutions knows the value of source code management (SCM). Without SCM, teams could not reliably recreate the source files that were used to build a specific release, making it impossible to reliably maintain what the team has delivered.

However, a large development project involves much more shared information that just source files. Complex products and systems are mix of software, electronics, and hardware, with software taking an increasing role. Solution components are often developed by different organizations, using different method and tools, with lifecycle information stored in different repositories. The design and development of these complex systems requires many kinds of artifacts. Engineers in specialist disciplines produce these artifacts employing various engineering methods, disciplines and tools. However, these artifacts typically are not under Configuration Management, or if they are, it is done manually: with half-measures that incur trade-offs. These challenges exist for software-only systems, yet their magnitude is much greater for products with physical, electrical and software aspects.

For example, specific requirements are often associated with a particular release of components of a system. Analysis and design artifacts are created to understand how to address the impact of, or realize those requirements. Test cases and test results are used to validate that the work done on the systems actually meets the requirements.

All this shared information is generally not available under the control of a single organization, set of tools or content management system, and it is often stored in repositories, not files in the file system. Like source files, all this shared information should be managed in a controllable, predictable way that is coordinated with specific solution releases.

Development teams need an efficient, effective means of managing versions and variants of artifacts across the whole systems development lifecycle. They need to be able to capture, preserve, compare, merge and potentially recreate specific sets of versioned information covering the whole lifecycle in order to know who did what, when, and why.


The OSLC Configuration Management specification defines an RDF vocabulary and a set of REST APIs for managing versions and configurations of linked data resources from multiple domains. Using client and server applications that implement the configuration management vocabulary and REST APIs allow a team administrator to create configurations of versioned resources contributed from tools and data sources across the lifecycle. These contributions can be assembled into aggregate (global) configurations that are used to resolve references to artifacts in a particular, well defined, and reproducible context.

Team members set the configuration context in each of the tools they use to refer to the particular global configuration that represents the state of the systems they are working on. They can create branches to support parallel development, and compare and merge branches to flow changes as needed. Product managers can create branches that represent different variants of a product in order to separate variation points and ensure changes are only applied to the appropriate variants.

Development teams can create baselines that preserve the state of the federated, shared information in order to be able to recreate that state for any reason, including for regulatory compliance or for applying maintenance updates to released versions and/or variants of a product.

Business Value

The primary purpose for versioning and configuration management is to be able to establish and restore or recover a particular set of related resources in order to know and manage who changed what, when, and why. Applying these techniques to other disciplines, and combining them together, offers new opportunities for parallel development, managing change, reuse, and management of product variants in complex development projects.

The benefits of source-code management are well known. However, achieving those benefits across all of the information that goes into designing, building, managing and governing the source code can be a challenge. This is because having multiple change and configuration management solutions for different artifact types requires manual coordination of versions and variants across the tools. The OSLC Configuration Management specification specifies a standard way in which different tools, developed by different suppliers, at different times, using different repositories and data representations can contribute version and configuration information across the whole lifecycle.

The resulting business value includes:

Some typical uses of versioning and configuration management capabilities include:


An immutable configuration of one or more components that corresponds to some meaningful state of its resources. The set of configuration items in a baseline cannot be changed; the state of each of those items cannot be changed. Some of the metadata on the baseline itself can be changed, such as tags, comments, etc. Baselines are useful for recording deliverables, enabling a team to work with a known configuration, or as an initial state for some new stream of work.
(verb) to create a configuration for parallel or insulated development.
(noun) the result of parallel or insulated development after branching - that is, a sequence of baselines, usually with a stream at the end of the branch.
Change Set
A change set is a related set of changes, introducing new versions of resources, grouped together to ensure coherence and consistency. In some systems, a change set may be treated as a configuration that contains a delta to some other configuration; this standard allows but does not require change sets to be represented as configurations.
A unit of organization consisting of a set of version resources. For a particular versioned resource, different versions can be in different components. Components are the units of configurability, and form reusable assets or building blocks. The granularity of a component varies between providers, but typically it contains the set of resources used in some product, project, or a subdivision of such a set.
Concept Resource
An artifact (a requirement, test case, source code file, etc.) as an overall entity, independent of any specific version of that artifact.
A configuration identifies a set of versions of resources in a component. Configurations commonly identify exactly one version of each resource in a component. Configurations can also aggregate other configurations ('contributions'), identifying further sets of versions of resources in other components, thus assembling a shared context across multiple components.
A Linked Data Platform Container, often abbreviated to LDPC.
A configuration that is a member of the set of configurations making up a configuration. The set of versioned resources in a configuration is the union of the set of versioned resources in that configuration and all its contributions; contributions are ordered to resolve any conflicts between that set.
Global Configuration
A configuration that identifies a set of configurations contributed by multiple tools or configuration management servers, allowing you to define all the relevant resources for a system. Using global configurations, you can establish a configuration context across multiple tools, even when each tool stores its resources in otherwise unrelated configurations and repositories.
The set of versions of resources identified by a given configuration.
This term is not used formally by the specifications, but informally it may refer to a version of a resource that is designed to replace an earlier version, such as an edited version of a source file, or a modified requirement.
A modifiable configuration of resources. For example, team members deliver to a stream when they want to make their changes visible to other team members. In many systems, changes to versioned resources can only be made in a stream.
A short string used to find, mark, qualify, or indentify some resource. Resources can have multiple tags. Tags can be used to indicate the intended purpose of a resource, or to flag it for some intention.
This term is not used formally by the specifications, but informally it may refer to a version of a resource that is identified by a specific set of characteristics that distinguish it from other versions of that resource, where each variant can exist at the same time as those other versions of the resource.
A referenceable state of a resource. A resource with separable referenceable versions is called a versioned resource. Each version of such a resource is called a version resource, and can be referenced with a distinct URI.

Concept resources, version resources, and configuration context

All the major “Artifacts” or “Entities” in OSLC domains are concept resources. Examples are defects, tasks, products, projects, users, tests cases requirements, plans and so on. Like all resources, concept resources have URLs. Except in a few technical and specialized scenarios, URLs of concept resources are used throughout the system. “Entities” are addressed in HTTP messages via their concept resource URLs. Links are typically established using the URL of a concept resource.

The state (including the properties) of a concept resource can vary over time, or for other reasons. A versioned resource is a concept resource that keeps track of different states. a version resource is a resource that represents one specific state of a versioned resource. Not every past state is necessarily kept; a server may elide or discard states that are no longer referenced.

Not all resource types need be versioned - for example, OSLC change requests are typically not versioned. OSLC configurations and components need not be versioned.

For a versioned resource, a GET on the URI of a concept resource resolves that URI to an appropriate state of (version of) that concept resource for the appropriate configuration context (see later). The returned http resource will contain RDF statements about both the version resource and the concept resource; most statements should use the concept resource as the subject, because a version resource reflects the state of (properties of) the concept resource as it appeared at some time. Using the concept resource URI as the subject of RDF statements is more consistent with the handling of non-versioned resources; using the versioned resource URI as the subject of RDF statements requires more client knowledge of versioning.

Since different versions reflecting different states of the concept resource may return conflicting RDF statements about the same subject, it is important for clients handling multiple versions (multiple configurations) to keep track of the relevant versions; this can be done using RDF named graphs.

As an example, GET http://example.com/conceptResourceA in one configuration context might return:

    a oslc_config:VersionResource ;
    dcterms:isVersionOf :conceptResourceA . # dcterms:isVersionOf relates the version resource itself to its concept resource
    a :someType ;
    oslc_config:versionId "23" ;
    dcterms:title "Concept Resource A" ;
    :color "blue" ;
    dcterms:description "Concept resource A as it appears in the state with the URI :conceptResourceA-version23" .

while in a different configuration context it might return:

    a oslc_config:VersionResource ;
    dcterms:isVersionOf :conceptResourceA .
    a :someType ;
    oslc_config:versionId "17" ;
    dcterms:title "Concept Resource A" ;
    :color "red" ;
    dcterms:description "Concept resource A as it appears in the state with the URI :conceptResourceA-version17" .

To keep track of which version represented which state of the conflicting color statements, use of RDF named graphs is recommended, as shown here using TriG:

:conceptResourceA-version23 = {
        a oslc_config:VersionResource ;
        dcterms:isVersionOf :conceptResourceA .
        a :someType ;
        oslc_config:versionId "23" ;
        dcterms:title "Concept Resource A" ;
        :color "blue" ;
        dcterms:description "Concept resource A as it appears in the state with the URI :conceptResourceA-version23" .

:conceptResourceA-version17 = {
        a oslc_config:VersionResource ;
        dcterms:isVersionOf :conceptResourceA .
        a :someType ;
        oslc_config:versionId "17" ;
        dcterms:title "Concept Resource A" ;
        :color "red" ;
        dcterms:description "Concept resource A as it appears in the state with the URI :conceptResourceA-version17" .

Updating a versioned resource is typically performed in a stream, and usually results in the creation of a new version of the same concept resource. In some systems, a related batch of changes to one or more resources can be grouped into a change set; this version of OSLC Configuration Management does not define how change sets might work.

Since concept resource URIs for versioned resources do not inherently identify a specific version of that resource, a client needs to provide a configuration context within which the concept resource is resolved to a specific version.

A client requests a specific configuration context in a header or a query string.

Conformance to other standards

OSLC Configuration Management 1.0 servers MUST conform to [[!OSLCCore2]], and SHOULD conform to [[!OSLCCore3]] (and hence [[!LDP]]).

All Configuration Management resources SHOULD be compliant with [[!LDP]].

All Tracked Resource Sets for Configuration Management resources MUST be compliant with [[!TRS]], and configuration servers providing such Tracked Resource Sets SHOULD follow the guidance in [[!ILDP]].


RDF Namespaces

OSLC Configuration Management defines the namespace URI of http://open-services.net/ns/config# with a namespace prefix of oslc_config.

OSLC Configuration Management uses the following prefixes:

Specification and Vocabulary Documents

The OSLC Configuration Management Specification consists of the following parts. Each part includes the associated OSLC 2.0 resource shapes.

Versioned Resource Specification
All versioned resources, and servers providing such resources, MUST be compliant with this specification.
Configuration Specification
All configuration resources (including global configurations), and providers of such resources, MUST be compliant with this specification. Configuration and component resources MAY be versioned; versioned configuration and component resources MUST be compliant with both the Configuration Specification and the Versioned Resource Specification.
Client Requirements
TBD - This document defines the required behavior for clients of configurations and versioned resources
RDF Vocabulary
The RDF vocabulary for versioned resources, configurations, and related resources.

Non-RDF Sources

All resources described in this specification are RDF resources. Providers SHOULD follow the Linked Data Platform recommendation for handling non-RDF data sources.