Terminology

Baseline

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.

Branch

(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.

Component

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 servers, but typically it contains the set of resources used in some product, project, or a subdivision of such a set. The resources in a component may be of any type, or multiple types, including but not limited to types defined in various OSLC domain specifications.

Concept Resource

An artifact (a requirement, test case, source code file, etc.) as an overall entity, independent of any specific version of that artifact. In Product Line Management (PLM) systems, this is often referred to as a 'master' item or part, of which there are revisions and versions or iterations.

Configuration

A configuration identifies a set of versions of resources in a component. In some systems, those resources are called configuration items. 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.

Configuration Item

A configuration item is a resource selected in a configuration - that is, it is a versioned resource. See version.

Container

A Linked Data Platform Container, often abbreviated to LDPC, as defined in [[LDP]].

Contribution

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.

Revision

In PLM systems, changes to an item are often divided into more significant changes marked as new revisions, and less significant changes marked as versions or iterations within the same revision. The boundary between revisions is often marked by a state change, such as marking the last version within a revision as 'released'. This specification does not require such a distinction between major and minor changes, using the generic term 'version' for both revision and version or iteration, but does not prohibit systems from providing the distinction.

Selections

The set of versions of resources identified by a given configuration.

Stream

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.

Tag

A short string used to find, mark, qualify, or identify 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.

Variant

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.

Version

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. In PLM systems, versions are often subdivided into revisions and versions or iterations.

Concept resources, version resources, and configuration context

All the major “Artifacts” or “Entities” in OSLC domains are concept resources. Examples are defects, tasks, products, physical parts or items, 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 normally 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.

For some PLM or PLE applications, it is useful to be able to represent incomplete or abstract hierarchies as partially-bound configurations, where not all versions of the concepts in that configuration have yet been determined. That determination may be made later in time, or dynamically based on parameters defined elsewhere in the system.

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 https://example.com/conceptResourceA in one configuration context might return:

:conceptResourceA-version23
    a oslc_config:VersionResource ;
    dcterms:isVersionOf :conceptResourceA . # dcterms:isVersionOf relates the version resource itself to its concept resource
: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" .

while in a different configuration context it might return:

:conceptResourceA-version17
    a oslc_config:VersionResource ;
    dcterms:isVersionOf :conceptResourceA .
: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]]:

GRAPH :conceptResourceA-version23 {
    :conceptResourceA-version23
        a oslc_config:VersionResource ;
        dcterms:isVersionOf :conceptResourceA .
    :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" .
}

GRAPH :conceptResourceA-version17 {
    :conceptResourceA-version17
        a oslc_config:VersionResource ;
        dcterms:isVersionOf :conceptResourceA .
    :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.

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.