Operations on Configurations

A configuration provider MUST support the following operations on configuration items (versioned concept resources):

• HEAD: Retrieve information including the version resource URI (if any) about the state of a specified versioned concept resource in the context of a specified configuration.
• GET: Retrieve the state of a specified versioned concept resource in the context of a specified configuration, where this operation returns zero or one version resources matching the required state.
• PUT: Update the state of a specified versioned concept resource in a specified stream; this operation might or might not cause the creation of a new version of the resource.

A configuration provider MAY support the following operations on configuration items:

• POST: Create the first version of a new concept resource, or a new version of an existing resource, in a specified stream
• DELETE: Delete the current mutable version resource in a specified stream

A configuration provider MUST support the following operations on configurations:

• HEAD and OPTIONS: Retrieve information about the configuration, including link headers compliant with the W3C Linked Data Platform specification indicating the non-member resource
• GET: Retrieve the current state of the configuration.
• DELETE a configuration; providers MAY refuse to delete configurations that are part of or referenced by existing baselines.
• The BASELINE, STREAM, and COMPARE actions (see Actions)

A configuration provider MAY support the following operations on configurations:

• Provide notification of changes to a configuration
• Compare a configuration with another configuration; result format TBD.
• Update a stream to correspond to a specified baseline; this is logically equivalent to deleting the stream and recreated it from the given baseline, but may be more efficient.
• Merge a configuration into a stream; this operation updates the configuration to contain the latest revision of each concept resource in either of the two input configurations; handling of configuration specs and conflicts TBD.

A provider of aggregate configurations MUST also support the following operations:

• PUT on a configuration to update the set of contained configurations
• The SYNC action (see Actions)

Actions

Note: track evolving description of actions in other specs, including change management.

Actions are read-only properties of type Resource in a Configuration resource. The URI of such a reference property (“Action URI”) points to the Action resource that handles the actions. A resource can be updated by a HTTP POST to the Action URI. The request body of the HTTP POST MUST contain the URI of the configuration or configurations on which the action is to be performed. The request body MAY contain additional property values that control the action, or that are to be applied to the result of the action. A HTTP GET on the Action URI SHOULD return information about that action.

The Configuration resource representation SHOULD only include the actions that are applicable to the current state of the resource. If an action is attempted and the precondition for that action is not met, the request MUST respond with a 409 Conflict status code.

An attempt to update an action property explicitly in a PUT or PATCH request SHOULD be answered with a 409 Conflict HTTP status code. Their presence in a resource representation used for an update via PUT MUST NOT prevent the resource from being updated.

The Action resource specifies information about an action, such as a title and a description. It also can include a resource shape that can be used to give consumers hints about required field values for this action.

The available actions include:

[TOC]

Namespaces

In addition to the namespace URIs and namespace prefixes oslc, rdf, dcterms and foaf defined in the OSLC Core specification, OSLC Configuration Management defines the namespace URI of http://open-services.net/ns/config# with a namespace prefix of oslc_config.

This specification also uses these namespace prefix definitions:

• prov : http://www.w3.org/ns/prov# (W3C provenance vocabulary)

OSLC Core properties used by all Configuration Management resources

Concept resources and version resources

A GET on the URI of a concept resource resolves that URI to an appropriate state of (version of) a concept resource for the appropriate configuration context (see later). The returned resource may 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 may be done using RDF named graphs.

The dcterms:isVersionOf property relates the version resource itself to its concept resource; this property is mandatory for all versioned resources.

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

    :conceptResourceA-version23
        dcterms:isVersionOf :conceptResourceA .
    :conceptResourceA
        a :someType ;
        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
        dcterms:isVersionOf :conceptResourceA .
    :conceptResourceA
        a :someType ;
        dcterms:title "Concept Resource A" ;
        :color "red" ;
        dcterms:description "Concept resource A as it appears in the state with the URI :conceptResourceA-version17" .

While the Linked Data Platform indicates that every concept resource should define at least one rdf:type, current practice does not require a type property on the version resource.

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 = {
    :conceptResourceA-version23
        dcterms:isVersionOf :conceptResourceA .
    :conceptResourceA
        a :someType ;
        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 = {
    :conceptResourceA-version17
        dcterms:isVersionOf :conceptResourceA .
    :conceptResourceA
        a :someType ;
        dcterms:title "Concept Resource A" ;
        :color "red" ;
        dcterms:description "Concept resource A as it appears in the state with the URI :conceptResourceA-version17" .
}.

Configuration Item

Resources of any type may appear as configuration items - resource that appear as members of configurations or change sets. Configuration items MAY have any of the common properties shown above, and MAY have any other properties. Configuration items that represent versions of a concept resource MUST have the dcterms:isVersionOf property referencing that concept resource. Configuration items that are versioned resources have the following additional properties:

Configuration

A configuration is a Linked Data Platform Container resource with the common properties, plus the following:

Component

A component is a Linked Data Platform Container identifying a set of resources that are configured together as a unit. The granularity of a component varies between providers, but typically it contains the set of resources of some type being used in some project, or a subdivision of such a set. A component has the common properties, plus the following:

A component itself MAY be a versioned resource, indicated by the presence of the dcterms:isVersionOf property referencing the component concept resource.

Configuration context

The initial configuration context is to be established by the user and the system in an appropriate manner - possibly stored in a preference, picked up from an initial resource, selected from a dialog, etc.

While navigating between resources, resources of certain types MAY indicate that a different context is to be used when followings links from that resource. TBD. For example, if a member of the current configuration context is itself a configuration, that sub-configuration MUST be used as the context for resources contained in that sub-configuration. Alternatively, the RELM 1.0 RDF Specification shows use of the vvc:foreignConfiguration predicate to indicate a switch in the configuration context. We need a standard way to express the resource types and predicates to be used for this purpose.

A client may request a specific configuration context in one of four ways. TBD: we need to simplify this. URIs for resources-in-a-configuration-context, whatever their form, should be obtained from providers in some standard manner: clients should never need to construct such URIs themselves - for example, using string manipulation to append a query string.

• When performing a GET on a concept URI, add an X-OSLC-Configuration-Context header, passing the URI of a configuration resource as the value:

    GET /resources/conceptResourceA HTTP/1.1
    X-OSLC-Configuration-Context: http://example.com/configurations/myConfiguration1

• When performing a GET on a concept URI, add a query string oslc_config.context and the encoded configuration URI to the end of the request URI:

    GET /resources/conceptResourceA?oslc_config.context=&3Chttp&3A//example.com/configurations/myConfiguration1&3E HTTP/1.1

• When performing a GET on a configuration URI, add an X-OSLC-Concept-Resource header, passing the URI of a concept resource as the value:

    GET /configurations/myConfiguration1 HTTP/1.1
    X-OSLC-Concept-Resource: http://example.com/resources/conceptResourceA

• When performing a GET on a configuration URI, add a query string oslc_config.concept_resource and the encoded concept resource URI to the end of the request URI:

    GET /configurations/myConfiguration1?oslc_config.concept_resource=&3Chttp&3A//example.com/resources/conceptResourceA&3E HTTP/1.1

Links should be created using the appropriate URI form for the given type of link - a URI for a version resource for links from change sets and most link types from change requests, and a URI for a concept resource for traceability links between versioned resources, or (rarely) a URI for a concept resource plus a configuration context for a link to the current version of the resource in that named context.

Version skew

In large or complex systems, it is often the case that two or more different versions of the same artifact or component are used in different places in that system. This often surfaces at the granularity of components or sub-configurations in larger aggregate or composite configurations, where two different components in turn use two different versions of a shared sub-component.

In situations with version skew, a GET request for a concept resource in the context of the top-level aggregate or composite configuration is ambiguous, and MUST fail with a 409 Conflict HTTP status code. The client may reissue the request with a more specific configuration context. Providers MAY allow other methods for disambiguating requests in the presence of version skew, such as some form of path or location information.

Change set

A change set is a resource with any of the above-listed standard properties, plus the following:

Creation Factories

A configuration provider MUST provide a creation factory for new configurations. A configuration provider MAY provide a creation factory for configuration items, but this specification does not determine the semantics of or required properties for configuration item factories.

Delegated UIs

A configuration provider SHOULD delegated user interface dialogs for creation and selection of configurations. A configuration provider MAY also provide delegated dialogs for creation and selection of configuration items.

• Baseline: a term for a configuration that identifies an immutable set of resources with immutable states. Baselines often have other identifying properties or associations, such as particular workflow or approval states. A baseline resource might be mutable. In some domains and tools, it may take time to construct the baseline during which the set of member resources might be changeable, but the member resources are immutable. At some lifecycle stage, the baseline might undergo validation and approval at which point the collection becomes immutable.

• Branch: a branch identifies a set of version resources (revisions) that form a parallel variant of a concept resource - for example, a set of versions of a product for a particular geography or market. The term is also used to identify the point in the version history at which that new branch was created, and the parent version from which the new branch was derived. Finally, as a verb, branch is also used to describe the action of creating the initial parallel version.

• Change set: a resource that identifies a set of related changes to one or more other resources. Not all systems support explicit creation and management of change sets. The use cases and scenarios defined by this work group require change set resources as an intermediate resource between OSLC change requests and configuration items when using the defined link predicate oslc_cm:tracksChangeSet, and as part of the representation of baseline comparisons, but a provider may construct these change set resources implicitly, dynamically, or in other manners as required. Note that OSLC change requests may also have other links pointing directly to configuration items.

• Concept resource: All the major “Artifacts” or “Entities” in OSLC domains and equivalent linked data providers are concept resources. Examples are defects, tasks, products, projects, users, tests cases, designs, requirements, plans, and so on. Like all resources, concept resources have URLs. In most cases, URLs of concept resources are used throughout a system. “Entities” are addressed in HTTP messages via their concept resource URLs. In many cases, links are established by using the URL of a concept resource. A concept resource may have versions; see Version resource.

• Configuration: a resource that identifies a set of revisions, versions, and/or states of some other resources, possibly including other configurations. In some systems, a configuration identifies an exact set of resources selected by the entity that created the configuration, as well as their versions; in other systems, a configuration may identify the state of a fixed set of resources, not limited to a client-determined set. The implication is that a client cannot rely on being able to create a configuration that ‘contains’ only a client-specified set of resources. In some systems, a configuration may have configurations as members; such a configuration is a composite configuration and its member configurations are sub-configurations.

• Configuration item: this is a common term in configuration management, referenced in ISO9001-1003, MIL-STD-498 and elsewhere. It encompasses any type of resource whose state may be recorded by a configuration - that is, a type of resource that may be ‘in’ a configuration. A configuration may be (but is not required to be) a configuration item.

• Configuration management: the practices of managing configurations, their contents, their lifecycles - in particular, identifying and controlling changes to configurations.

• Configuration space: Typically, resources belong to some service provider, and are stored in some container. These service provider and container boundaries often imply constraints on which set of resources can comprise any single configuration. A configuration space identifies the set of versioned concept resources that may be members of the same configurations. A versioned concept resource is associated with just one configuration space.

• Configuration specification: A set of rules that specify versions of resources to be selected in a configuration using this specification.

• Context: A context, or configuration context, is the description or specification of a configuration; that configuration might or might not yet exist (since we need a way to specify a configuration to be created). One way to identify a context is to use the URI of a configuration resource. Some providers may allow other mechanisms for specifying context. A context might also be identified by a combination of a configuration specification and a configuration space. The term “effectivity” is used in some disciplines to indicate the extent of some configuration context, such as a period of time, or a range of serial numbers, etc.

• Dimension: Different versions and variants of a single concept resource may be viewed as existing in an n-dimensional variability space, where time is one dimension and other feature or capability lines of variation define the other dimensions. A provider is not required to implement variability dimensions in this manner, but it may be useful to label configurations in terms of the points in this variability space. A branch in this view corresponds to a fixed set of dimension values other than time.

• Effectivity: Defines the extent of applicability of some configuration specification, and thus is part of the definition of a configuration context.

• Global configuration: A configuration that aggregates configurations, possibly from multiple different providers. For example, a global configuration would be used to aggregate configurations from Rational Team Concert SCM, Git SCM, Rational Design Manager VVC, and other such providers. Global configurations can record baselines from tools from multiple vendors across the entire lifecycle.

• Resource: In this context, we refer to an information resource - data that resides on a computer, not an actual physical entity.

• Revision: In the software configuration world, this term is often used for a version of an resource that is designed to replace an earlier version, such as a new version of a source file or a revised requirement. In the hardware world, the term revision often has a more precise meaning with implications about the scale of a change. To avoid confusion, the OSLC Configuration Management specification should avoid the term.

• Stream: a term for a configuration that identifies a mutable set of resources, with mutable states and/or different versions. Streams typically serve as areas for ongoing development; baselines are typically formed by taking a snapshot of (recording the current state of) a stream and the configuration items in that stream.

• Variant: A variant of a resource (configuration item) is a version that may exist at the same time as one or more other variants, and is identified by a specific set of characteristics, features, or capabilities that distinguish it from other variants of the same resource. For example, the Coupe Si, Sedan Si, and Hybrid may be variants of a vehicle product. From the point of view of configuration management, a variant may be treated in the same manner as time-based versions, just differing along other non-time-based dimensions.

• Variation point: A choice point within a resource where a selection defines one of the characteristics that distinguish one product from another within a product line. In software configuration management, a variation point is often indicated using techniques such as the #ifdef construct in C; in the hardware or electronics world, it might be indicated in the build instructions, substituting one of several possible components at a given location, or by the omission of an optional component,

• Version resource: A version resource defines a particular version of the state of a concept resource. A version resource is a version of one and only one concept resource - though note that through redirection or some other form of mapping, a GET on a concept resource URI might resolve to a different concept resource, or a version of a different concept resource. Since a version resource is a resource, it has its own URI; there are use cases for links that always identify a specific version resource, and this may be done by linking to the version resource URI rather than the concept resource URI.

• Version skew: the situation where two different versions of the same concept resource are used in different places in some context or related set of contexts. For some providers, a single configuration by itself cannot support version skew, while some providers might be able to represent version skew within a single configuration by adding additional information about the location of an instance of a resource within the configuration. In general, composite configurations (configurations that aggregate other sub-configurations) can express version skew, since the aggregated collection of configurations might contain two or more different configurations of the same concept resources.

• Workspace: A projection of the version resources in a stream to some container (such as a filesystem directory) that allows work to be performed on those resources.

• Other possible terms: merge, option, view, recipe

[TOC]

Charter

See the Configuration Management Charter page.

Terminology

See the [[Configuration Management Terminology]] page, and the [[Configuration Management Resource Definitions]] page. This specification references the emerging work of W3C Linked Data Platform.

See also some legacy [[Baseline properties]] proposed by the Core workgroup.

Issues

See [[Configuration Management Issues]] for a list of open issues.

Scenarios

See [[Configuration Management Scenarios]] for scenarios.

Meetings

See [[Configuration Management Meetings]] for details on meeting minutes.

Specifications

A draft specification is currently under construction at OASIS, using as seed documents the material in the pages [[Configuration Management Terminology]], [[Configuration Management Resource Definitions]], and [[Configuration Operations]].

Working Documents

The last two documents are legacy proposals from the Core workgroup: one involves resource rewriting to create new resources that are specific to versions or snapshots of individual resources across multiple service providers, and the other creates snapshot states for a set of resources from a single service provider. Neither of these is necessarily the approach to be used by this workgroup, but they are referenced so we can see what ground has already been covered.

Related Documents and Information

RELM 1.0 RDF Specification, as an example of RDF handling versions, variants, and version skew
PROV Model Primer
Provenance WG homepage
PROV-O: The PROV Ontology
HSUV example in Rational Engineering Lifecycle Manager

Mailing List

Configuration Management mailing list

Minutes of previous meetings

Attendance not recorded

Nick reported the transfer of all new work on the Configuration Management spec to OASIS, under the newly-formed OASIS OSLC CCM TC.

No more regular meetings of this OSLC group will be held - but the mailing list may still be used for discussion of use cases, scenarios, and other topics not involving IP.

Present: Nick, David, Sampath

Nick described contributor cache issue - how does contributor find the relevant contribution to a GC when asked to find a version of their resource in a GC? Read resources and use OSLC defined structure to search the contributions to find their own? Could be slow. Add a REST API to ask the GC provider for the relevant GC? And then cache the result? Latter then would require subscription or notification scheme. Attendees did not like the latter, pointing out all the standard arguments about async behavior, cache consistency, etc. Premature optimization?

We then discussed possible makeup of OASIS TC, and how meetings might work when multiple domain topics were to be discussed. Spend first 30 minutes on Change Mgt, then 30 minutes on Config Mgt, so users could attend the relevant part? Take attendance twice for voting rights purposes? Also discussed workload for group chair, and Nick’s concerns that he not have enough time to take on that role.

Attending: Nick Crossley, David Honey, Sampath, Steve Speicher, Peter Hack, Gray, Laura Hart (Lockheed Martin), Mike Loeffler (GM),

Current status: no significant changes to wiki since last meeting. Coding for straw man implementation progresses.

Steve forwarded call for participation in CCM TC to oslc configuration management mailing list. Steve then described OASIS TC formation process and how voting rights are acquired. First meeting on Feb 4, so must join by Jan 28th to get initial voting rights.

Mike not sure when (if) GM will become OASIS member, but he would like to participate in some form. Steve mentioned possibility of forming user groups to accept non-IP contributions such as discussion of use cases.

Laura: similar situation for LM.

Nick: will polish up current wiki material into real draft spec, for submission to OASIS as a seed document.

No regular meetings are scheduled, since active work has transitioned to OASIS.

Minutes of previous meetings

Minutes of previous meetings

Present: Nick, Steve, Peter, David

Nick described the changes to the resource definition and actions pages. Nick justified the two different containers by arguing that we needed an efficient way to get the configuration members of a configuration, separately from a container that included the non-configuration members. The configuration members are obtained from the configuration as an LDPC in itself, and the non-configuration members (possibly in addition to the configuration members) are obtained from the linked component LDPC.

Nick also described the new way of performing operations on configurations using the Actions approach, copied from the OSLC CM 3.0 draft. We agreed this technique was not final, and we need to coordinate the Change Management, Configuration Management, and Automation workgroups, ensuring we ned up with a consistent approach.

Nick also pointed out the inconsistency between the Configuration Management approach to lifecycle states (use a link from some resource not defined by the Configuration Management spec) and the Change Management approach (a set of predefined values for a state property embedded in the ChangeRequest resource); we agreed this needed resolution at some time.

Finally, we discussed the impact of OASIS on timing, namespaces, ability to control the spec and its timing, etc.

No regular meetings are scheduled, since active work has transitioned to OASIS.

Minutes of previous meetings

Minutes of previous meetings

[TOC]

Charter

See the Configuration Management Charter page.

Terminology

See the [[Configuration Management Terminology]] page, and the [[Configuration Management Resource Definitions]] page. This specification references the emerging work of W3C Linked Data Platform.

See also some legacy [[Baseline properties]] proposed by the Core workgroup.

Issues

See [[Configuration Management Issues]] for a list of open issues.

Scenarios

See [[Configuration Management Scenarios]] for scenarios.

Meetings

See [[Configuration Management Meetings]] for details on meeting minutes.

Specifications

A draft specification is currently under construction at OASIS, using as seed documents the material in the pages [[Configuration Management Terminology]], [[Configuration Management Resource Definitions]], and [[Configuration Operations]].

Working Documents

The last two documents are legacy proposals from the Core workgroup: one involves resource rewriting to create new resources that are specific to versions or snapshots of individual resources across multiple service providers, and the other creates snapshot states for a set of resources from a single service provider. Neither of these is necessarily the approach to be used by this workgroup, but they are referenced so we can see what ground has already been covered.

Related Documents and Information

RELM 1.0 RDF Specification, as an example of RDF handling versions, variants, and version skew
PROV Model Primer
Provenance WG homepage
PROV-O: The PROV Ontology
HSUV example in Rational Engineering Lifecycle Manager

Mailing List

Configuration Management mailing list

[TOC]

Charter

See the Configuration Management Charter page.

Terminology

See the [[Configuration Management Terminology]] page, and the [[Configuration Management Resource Definitions]] page. This specification references the emerging work of W3C Linked Data Platform.

See also some legacy [[Baseline properties]] proposed by the Core workgroup.

Issues

See [[Configuration Management Issues]] for a list of open issues.

Scenarios

See [[Configuration Management Scenarios]] for scenarios.

Meetings

See [[Configuration Management Meetings]] for details on meeting minutes.

Specifications

A draft specification is currently under construction at OASIS, using as seed documents the material in the pages [[Configuration Management Terminology]], [[Configuration Management Resource Definitions]], and [[Configuration Operations]].

Working Documents

The last two documents are legacy proposals from the Core workgroup: one involves resource rewriting to create new resources that are specific to versions or snapshots of individual resources across multiple service providers, and the other creates snapshot states for a set of resources from a single service provider. Neither of these is necessarily the approach to be used by this workgroup, but they are referenced so we can see what ground has already been covered.

Related Documents and Information

RELM 1.0 RDF Specification, as an example of RDF handling versions, variants, and version skew
PROV Model Primer
Provenance WG homepage
PROV-O: The PROV Ontology
HSUV example in Rational Engineering Lifecycle Manager

Mailing List

Configuration Management mailing list

Namespaces

In addition to the namespace URIs and namespace prefixes oslc, rdf, dcterms and foaf defined in the OSLC Core specification, OSLC Configuration Management defines the namespace URI of http://open-services.net/ns/config# with a namespace prefix of oslc_config.

This specification also uses these namespace prefix definitions:

• prov : http://www.w3.org/ns/prov# (W3C provenance vocabulary)

OSLC Core properties used by all Configuration Management resources

Concept resources and version resources

A GET on the URI of a concept resource resolves that URI to an appropriate state of (version of) a concept resource for the appropriate configuration context (see later). The returned resource may 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 may be done using RDF named graphs.

The dcterms:isVersionOf property relates the version resource itself to its concept resource; this property is mandatory for all versioned resources.

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

    :conceptResourceA-version23
        dcterms:isVersionOf :conceptResourceA .
    :conceptResourceA
        a :someType ;
        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
        dcterms:isVersionOf :conceptResourceA .
    :conceptResourceA
        a :someType ;
        dcterms:title "Concept Resource A" ;
        :color "red" ;
        dcterms:description "Concept resource A as it appears in the state with the URI :conceptResourceA-version17" .

While the Linked Data Platform indicates that every concept resource should define at least one rdf:type, current practice does not require a type property on the version resource.

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 = {
    :conceptResourceA-version23
        dcterms:isVersionOf :conceptResourceA .
    :conceptResourceA
        a :someType ;
        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 = {
    :conceptResourceA-version17
        dcterms:isVersionOf :conceptResourceA .
    :conceptResourceA
        a :someType ;
        dcterms:title "Concept Resource A" ;
        :color "red" ;
        dcterms:description "Concept resource A as it appears in the state with the URI :conceptResourceA-version17" .
}.

Configuration Item

Resources of any type may appear as configuration items - resource that appear as members of configurations or change sets. Configuration items MAY have any of the common properties shown above, and MAY have any other properties. Configuration items that represent versions of a concept resource MUST have the dcterms:isVersionOf property referencing that concept resource. Configuration items that are versioned resources have the following additional properties:

Configuration

A configuration is a Linked Data Platform Container resource with the common properties, plus the following:

Component

A component is a Linked Data Platform Container identifying a set of resources that are configured together as a unit. The granularity of a component varies between providers, but typically it contains the set of resources of some type being used in some project, or a subdivision of such a set. A component has the common properties, plus the following:

A component itself MAY be a versioned resource, indicated by the presence of the dcterms:isVersionOf property referencing the component concept resource.

Configuration context

The initial configuration context is to be established by the user and the system in an appropriate manner - possibly stored in a preference, picked up from an initial resource, selected from a dialog, etc.

While navigating between resources, resources of certain types MAY indicate that a different context is to be used when followings links from that resource. TBD. For example, if a member of the current configuration context is itself a configuration, that sub-configuration MUST be used as the context for resources contained in that sub-configuration. Alternatively, the RELM 1.0 RDF Specification shows use of the vvc:foreignConfiguration predicate to indicate a switch in the configuration context. We need a standard way to express the resource types and predicates to be used for this purpose.

A client may request a specific configuration context in one of four ways. TBD: we need to simplify this. URIs for resources-in-a-configuration-context, whatever their form, should be obtained from providers in some standard manner: clients should never need to construct such URIs themselves - for example, using string manipulation to append a query string.

• When performing a GET on a concept URI, add an X-OSLC-Configuration-Context header, passing the URI of a configuration resource as the value:

    GET /resources/conceptResourceA HTTP/1.1
    X-OSLC-Configuration-Context: http://example.com/configurations/myConfiguration1

• When performing a GET on a concept URI, add a query string oslc_config.context and the encoded configuration URI to the end of the request URI:

    GET /resources/conceptResourceA?oslc_config.context=&3Chttp&3A//example.com/configurations/myConfiguration1&3E HTTP/1.1

• When performing a GET on a configuration URI, add an X-OSLC-Concept-Resource header, passing the URI of a concept resource as the value:

    GET /configurations/myConfiguration1 HTTP/1.1
    X-OSLC-Concept-Resource: http://example.com/resources/conceptResourceA

• When performing a GET on a configuration URI, add a query string oslc_config.concept_resource and the encoded concept resource URI to the end of the request URI:

    GET /configurations/myConfiguration1?oslc_config.concept_resource=&3Chttp&3A//example.com/resources/conceptResourceA&3E HTTP/1.1

Links should be created using the appropriate URI form for the given type of link - a URI for a version resource for links from change sets and most link types from change requests, and a URI for a concept resource for traceability links between versioned resources, or (rarely) a URI for a concept resource plus a configuration context for a link to the current version of the resource in that named context.

Version skew

In large or complex systems, it is often the case that two or more different versions of the same artifact or component are used in different places in that system. This often surfaces at the granularity of components or sub-configurations in larger aggregate or composite configurations, where two different components in turn use two different versions of a shared sub-component.

In situations with version skew, a GET request for a concept resource in the context of the top-level aggregate or composite configuration is ambiguous, and MUST fail with a 409 Conflict HTTP status code. The client may reissue the request with a more specific configuration context. Providers MAY allow other methods for disambiguating requests in the presence of version skew, such as some form of path or location information.

Change set

A change set is a resource with any of the above-listed standard properties, plus the following:

Creation Factories

A configuration provider MUST provide a creation factory for new configurations. A configuration provider MAY provide a creation factory for configuration items, but this specification does not determine the semantics of or required properties for configuration item factories.

Delegated UIs

A configuration provider SHOULD delegated user interface dialogs for creation and selection of configurations. A configuration provider MAY also provide delegated dialogs for creation and selection of configuration items.

Namespaces

In addition to the namespace URIs and namespace prefixes oslc, rdf, dcterms and foaf defined in the OSLC Core specification, OSLC Configuration Management defines the namespace URI of [[http://open-services.net/ns/config#]] with a namespace prefix of oslc_config.

OSLC Core properties used by all Configuration Management resources

Concept resources and version resources

A GET on the URI of a concept resource resolves that URI to an appropriate state of (version of) a concept resource for the appropriate configuration context (see later). The returned resource may 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 may be done using RDF named graphs.

The dcterms:isVersionOf property relates the version resource itself to its concept resource; this property is mandatory for all versioned resources.

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

    :conceptResourceA-version23
        dcterms:isVersionOf :conceptResourceA .
    :conceptResourceA
        a :someType ;
        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
        dcterms:isVersionOf :conceptResourceA .
    :conceptResourceA
        a :someType ;
        dcterms:title "Concept Resource A" ;
        :color "red" ;
        dcterms:description "Concept resource A as it appears in the state with the URI :conceptResourceA-version17" .

While the Linked Data Platform indicates that every concept resource should define at least one rdf:type, current practice does not require a type property on the version resource.

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 = {
    :conceptResourceA-version23
        dcterms:isVersionOf :conceptResourceA .
    :conceptResourceA
        a :someType ;
        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 = {
    :conceptResourceA-version17
        dcterms:isVersionOf :conceptResourceA .
    :conceptResourceA
        a :someType ;
        dcterms:title "Concept Resource A" ;
        :color "red" ;
        dcterms:description "Concept resource A as it appears in the state with the URI :conceptResourceA-version17" .
}.

Configuration Item

Resources of any type may appear as configuration items - resource that appear as members of configurations or change sets. Configuration items MAY have any of the common properties shown above, and MAY have any other properties. Configuration items that represent versions of a concept resource MUST have the dcterms:isVersionOf property referencing that concept resource. Configuration items that are versioned resources have the following additional properties:

Configuration

A configuration is a Linked Data Platform Container resource with the common properties, plus the following:

Component

A component is a Linked Data Platform Container identifying a set of resources that are configured together as a unit. The granularity of a component varies between providers, but typically it contains the set of resources of some type being used in some project, or a subdivision of such a set. A component has the common properties, plus the following:

A component itself MAY be a versioned resource, indicated by the presence of the dcterms:isVersionOf property referencing the component concept resource.

Configuration context

The initial configuration context is to be established by the user and the system in an appropriate manner - possibly stored in a preference, picked up from an initial resource, selected from a dialog, etc.

While navigating between resources, resources of certain types MAY indicate that a different context is to be used when followings links from that resource. TBD. For example, if a member of the current configuration context is itself a configuration, that sub-configuration MUST be used as the context for resources contained in that sub-configuration. Alternatively, the RELM 1.0 RDF Specification shows use of the vvc:foreignConfiguration predicate to indicate a switch in the configuration context. We need a standard way to express the resource types and predicates to be used for this purpose.

A client may request a specific configuration context in one of four ways. TBD: we need to simplify this. URIs for resources-in-a-configuration-context, whatever their form, should be obtained from providers in some standard manner: clients should never need to construct such URIs themselves - for example, using string manipulation to append a query string.

• When performing a GET on a concept URI, add an X-OSLC-Configuration-Context header, passing the URI of a configuration resource as the value:

    GET /resources/conceptResourceA HTTP/1.1
    X-OSLC-Configuration-Context: http://example.com/configurations/myConfiguration1

• When performing a GET on a concept URI, add a query string oslc_config.context and the encoded configuration URI to the end of the request URI:

    GET /resources/conceptResourceA?oslc_config.context=&3Chttp&3A//example.com/configurations/myConfiguration1&3E HTTP/1.1

• When performing a GET on a configuration URI, add an X-OSLC-Concept-Resource header, passing the URI of a concept resource as the value:

    GET /configurations/myConfiguration1 HTTP/1.1
    X-OSLC-Concept-Resource: http://example.com/resources/conceptResourceA

• When performing a GET on a configuration URI, add a query string oslc_config.concept_resource and the encoded concept resource URI to the end of the request URI:

    GET /configurations/myConfiguration1?oslc_config.concept_resource=&3Chttp&3A//example.com/resources/conceptResourceA&3E HTTP/1.1

Links should be created using the appropriate URI form for the given type of link - a URI for a version resource for links from change sets and most link types from change requests, and a URI for a concept resource for traceability links between versioned resources, or (rarely) a URI for a concept resource plus a configuration context for a link to the current version of the resource in that named context.

Version skew

In large or complex systems, it is often the case that two or more different versions of the same artifact or component are used in different places in that system. This often surfaces at the granularity of components or sub-configurations in larger aggregate or composite configurations, where two different components in turn use two different versions of a shared sub-component.

In situations with version skew, a GET request for a concept resource in the context of the top-level aggregate or composite configuration is ambiguous, and MUST fail with a 409 Conflict HTTP status code. The client may reissue the request with a more specific configuration context. Providers MAY allow other methods for disambiguating requests in the presence of version skew, such as some form of path or location information.

Change set

A change set is a resource with any of the above-listed standard properties, plus the following:

Creation Factories

A configuration provider MUST provide a creation factory for new configurations. A configuration provider MAY provide a creation factory for configuration items, but this specification does not determine the semantics of or required properties for configuration item factories.

Delegated UIs

A configuration provider SHOULD delegated user interface dialogs for creation and selection of configurations. A configuration provider MAY also provide delegated dialogs for creation and selection of configuration items.

OSLC Core properties used by all Configuration Management resources

Concept resources and version resources

A GET on the URI of a concept resource resolves that URI to an appropriate state of (version of) a concept resource for the appropriate configuration context (see later). The returned resource may 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 may be done using RDF named graphs.

The dcterms:isVersionOf property relates the version resource itself to its concept resource; this property is mandatory for all versioned resources.

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

    :conceptResourceA-version23
        dcterms:isVersionOf :conceptResourceA .
    :conceptResourceA
        a :someType ;
        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
        dcterms:isVersionOf :conceptResourceA .
    :conceptResourceA
        a :someType ;
        dcterms:title "Concept Resource A" ;
        :color "red" ;
        dcterms:description "Concept resource A as it appears in the state with the URI :conceptResourceA-version17" .

While the Linked Data Platform indicates that every concept resource should define at least one rdf:type, current practice does not require a type property on the version resource.

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 = {
    :conceptResourceA-version23
        dcterms:isVersionOf :conceptResourceA .
    :conceptResourceA
        a :someType ;
        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 = {
    :conceptResourceA-version17
        dcterms:isVersionOf :conceptResourceA .
    :conceptResourceA
        a :someType ;
        dcterms:title "Concept Resource A" ;
        :color "red" ;
        dcterms:description "Concept resource A as it appears in the state with the URI :conceptResourceA-version17" .
}.

Configuration Item

Resources of any type may appear as configuration items - resource that appear as members of configurations or change sets. Configuration items MAY have any of the common properties shown above, and MAY have any other properties. Configuration items that represent versions of a concept resource MUST have the dcterms:isVersionOf property referencing that concept resource. Configuration items that are versioned resources have the following additional properties:

Configuration

A configuration is a Linked Data Platform Container resource with the common properties, plus the following:

Component

A component is a Linked Data Platform Container identifying a set of resources that are configured together as a unit. The granularity of a component varies between providers, but typically it contains the set of resources of some type being used in some project, or a subdivision of such a set. A component has the common properties, plus the following:

A component itself MAY be a versioned resource, indicated by the presence of the dcterms:isVersionOf property referencing the component concept resource.

Configuration context

The initial configuration context is to be established by the user and the system in an appropriate manner - possibly stored in a preference, picked up from an initial resource, selected from a dialog, etc.

While navigating between resources, resources of certain types MAY indicate that a different context is to be used when followings links from that resource. TBD. For example, if a member of the current configuration context is itself a configuration, that sub-configuration MUST be used as the context for resources contained in that sub-configuration. Alternatively, the RELM 1.0 RDF Specification shows use of the vvc:foreignConfiguration predicate to indicate a switch in the configuration context. We need a standard way to express the resource types and predicates to be used for this purpose.

A client may request a specific configuration context in one of four ways. TBD: we need to simplify this. URIs for resources-in-a-configuration-context, whatever their form, should be obtained from providers in some standard manner: clients should never need to construct such URIs themselves - for example, using string manipulation to append a query string.

• When performing a GET on a concept URI, add an X-OSLC-Configuration-Context header, passing the URI of a configuration resource as the value:

    GET /resources/conceptResourceA HTTP/1.1
    X-OSLC-Configuration-Context: http://example.com/configurations/myConfiguration1

• When performing a GET on a concept URI, add a query string oslc_config.context and the encoded configuration URI to the end of the request URI:

    GET /resources/conceptResourceA?oslc_config.context=&3Chttp&3A//example.com/configurations/myConfiguration1&3E HTTP/1.1

• When performing a GET on a configuration URI, add an X-OSLC-Concept-Resource header, passing the URI of a concept resource as the value:

    GET /configurations/myConfiguration1 HTTP/1.1
    X-OSLC-Concept-Resource: http://example.com/resources/conceptResourceA

• When performing a GET on a configuration URI, add a query string oslc_config.concept_resource and the encoded concept resource URI to the end of the request URI:

    GET /configurations/myConfiguration1?oslc_config.concept_resource=&3Chttp&3A//example.com/resources/conceptResourceA&3E HTTP/1.1

Links should be created using the appropriate URI form for the given type of link - a URI for a version resource for links from change sets and most link types from change requests, and a URI for a concept resource for traceability links between versioned resources, or (rarely) a URI for a concept resource plus a configuration context for a link to the current version of the resource in that named context.

Version skew

In large or complex systems, it is often the case that two or more different versions of the same artifact or component are used in different places in that system. This often surfaces at the granularity of components or sub-configurations in larger aggregate or composite configurations, where two different components in turn use two different versions of a shared sub-component.

In situations with version skew, a GET request for a concept resource in the context of the top-level aggregate or composite configuration is ambiguous, and MUST fail with a 409 Conflict HTTP status code. The client may reissue the request with a more specific configuration context. Providers MAY allow other methods for disambiguating requests in the presence of version skew, such as some form of path or location information.

Change set

A change set is a resource with any of the above-listed standard properties, plus the following:

Creation Factories

A configuration provider MUST provide a creation factory for new configurations. A configuration provider MAY provide a creation factory for configuration items, but this specification does not determine the semantics of or required properties for configuration item factories.

Delegated UIs

A configuration provider SHOULD delegated user interface dialogs for creation and selection of configurations. A configuration provider MAY also provide delegated dialogs for creation and selection of configuration items.

New Members

We welcome new members! Remember to sign the participation agreement forms, and please fill out your bio and optionally provide a photo - see the page Nick Crossley for a very short example.

Charter

See the Configuration Management Charter page.

Terminology

See the [[Configuration Management Terminology]] page, and the [[Configuration Management Resource Definitions]] page. This specification references the emerging work of W3C Linked Data Platform.

See also some legacy [[Baseline properties]] proposed by the Core workgroup.

Milestones

Issues

See [[Configuration Management Issues]] for a list of open issues.

Scenarios

See [[Configuration Management Scenarios]] for scenarios.

Meetings

See [[Configuration Management Meetings]] for details on meeting logistics, agendas, and minutes.

Specifications

A draft specification is currently under construction, formed from the contents of the material in the pages [[Configuration Management Terminology]], [[Configuration Management Resource Definitions]], and [[Configuration Operations]].

Working Documents

The last two documents are legacy proposals from the Core workgroup: one involves resource rewriting to create new resources that are specific to versions or snapshots of individual resources across multiple service providers, and the other creates snapshot states for a set of resources from a single service provider. Neither of these is necessarily the approach to be used by this workgroup, but they are referenced so we can see what ground has already been covered.

Related Documents and Information

RELM 1.0 RDF Specification, as an example of RDF handling versions, variants, and version skew
PROV Model Primer
Provenance WG homepage
PROV-O: The PROV Ontology
HSUV example in Rational Engineering Lifecycle Manager

Mailing List

Configuration Management mailing list

OSLC Core properties used by all Configuration Management resources

Concept resources and version resources

A GET on the URI of a concept resource resolves that URI to an appropriate state of (version of) a concept resource for the appropriate configuration context (see later). The returned resource may 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 may be done using RDF named graphs.

The dcterms:isVersionOf property relates the version resource itself to its concept resource; this property is mandatory for all versioned resources.

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

    :conceptResourceA-version23
        dcterms:isVersionOf :conceptResourceA .
    :conceptResourceA
        a :someType ;
        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
        dcterms:isVersionOf :conceptResourceA .
    :conceptResourceA
        a :someType ;
        dcterms:title "Concept Resource A" ;
        :color "red" ;
        dcterms:description "Concept resource A as it appears in the state with the URI :conceptResourceA-version17" .

While the Linked Data Platform indicates that every concept resource should define at least one rdf:type, current practice does not require a type property on the version resource.

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 = {
    :conceptResourceA-version23
        dcterms:isVersionOf :conceptResourceA .
    :conceptResourceA
        a :someType ;
        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 = {
    :conceptResourceA-version17
        dcterms:isVersionOf :conceptResourceA .
    :conceptResourceA
        a :someType ;
        dcterms:title "Concept Resource A" ;
        :color "red" ;
        dcterms:description "Concept resource A as it appears in the state with the URI :conceptResourceA-version17" .
}.

Configuration Item

Resources of any type may appear as configuration items - resource that appear as members of configurations or change sets. Configuration items MAY have any of the common properties shown above, and MAY have any other properties. Configuration items that represent versions of a concept resource MUST have the dcterms:isVersionOf property referencing that concept resource. Configuration items that are versioned resources have the following additional properties:

Configuration

A configuration is a Linked Data Platform Container resource with the common properties, plus the following:

Component

A component is a Linked Data Platform Container identifying a set of resources that are configured together as a unit. The granularity of a component varies between providers, but typically it contains the set of resources of some type being used in some project, or a subdivision of such a set. A component has the common properties, plus the following:

A component itself MAY be a versioned resource, indicated by the presence of the dcterms:isVersionOf property referencing the component concept resource.

Configuration context

The initial configuration context is to be established by the user and the system in an appropriate manner - possibly stored in a preference, picked up from an initial resource, selected from a dialog, etc.

While navigating between resources, resources of certain types MAY indicate that a different context is to be used when followings links from that resource. TBD. For example, if a member of the current configuration context is itself a configuration, that sub-configuration MUST be used as the context for resources contained in that sub-configuration. Alternatively, the RELM 1.0 RDF Specification shows use of the vvc:foreignConfiguration predicate to indicate a switch in the configuration context. We need a standard way to express the resource types and predicates to be used for this purpose.

A client may request a specific configuration context in one of four ways. TBD: we need to simplify this. URIs for resources-in-a-configuration-context, whatever their form, should be obtained from providers in some standard manner: clients should never need to construct such URIs themselves - for example, using string manipulation to append a query string.

• When performing a GET on a concept URI, add an X-OSLC-Configuration-Context header, passing the URI of a configuration resource as the value:

    GET /resources/conceptResourceA HTTP/1.1
    X-OSLC-Configuration-Context: http://example.com/configurations/myConfiguration1

• When performing a GET on a concept URI, add a query string oslc_config.context and the encoded configuration URI to the end of the request URI:

    GET /resources/conceptResourceA?oslc_config.context=&3Chttp&3A//example.com/configurations/myConfiguration1&3E HTTP/1.1

• When performing a GET on a configuration URI, add an X-OSLC-Concept-Resource header, passing the URI of a concept resource as the value:

    GET /configurations/myConfiguration1 HTTP/1.1
    X-OSLC-Concept-Resource: http://example.com/resources/conceptResourceA

• When performing a GET on a configuration URI, add a query string oslc_config.concept_resource and the encoded concept resource URI to the end of the request URI:

    GET /configurations/myConfiguration1?oslc_config.concept_resource=&3Chttp&3A//example.com/resources/conceptResourceA&3E HTTP/1.1

Links should be created using the appropriate URI form for the given type of link - a URI for a version resource for links from change sets and most link types from change requests, and a URI for a concept resource for traceability links between versioned resources, or (rarely) a URI for a concept resource plus a configuration context for a link to the current version of the resource in that named context.

Version skew

In large or complex systems, it is often the case that two or more different versions of the same artifact or component are used in different places in that system. This often surfaces at the granularity of components or sub-configurations in larger aggregate or composite configurations, where two different components in turn use two different versions of a shared sub-component.

In situations with version skew, a GET request for a concept resource in the context of the top-level aggregate or composite configuration is ambiguous, and MUST fail with a 409 Conflict HTTP status code. The client may reissue the request with a more specific configuration context. Providers MAY allow other methods for disambiguating requests in the presence of version skew, such as some form of path or location information.

Change set

A change set is a resource with any of the above-listed standard properties, plus the following:

Creation Factories

A configuration provider MUST provide a creation factory for new configurations. A configuration provider MAY provide a creation factory for configuration items, but this specification does not determine the semantics of or required properties for configuration item factories.

Delegated UIs

A configuration provider SHOULD delegated user interface dialogs for creation and selection of configurations. A configuration provider MAY also provide delegated dialogs for creation and selection of configuration items.

OSLC Core properties used by all Configuration Management resources

Concept resources and version resources

A GET on the URI of a concept resource resolves that URI to an appropriate state of (version of) a concept resource for the appropriate configuration context (see later). The returned resource may 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 may be done using RDF named graphs.

The dcterms:isVersionOf property relates the version resource itself to its concept resource; this property is mandatory for all versioned resources.

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

    :conceptResourceA-version23
        dcterms:isVersionOf :conceptResourceA .
    :conceptResourceA
        a :someType ;
        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
        dcterms:isVersionOf :conceptResourceA .
    :conceptResourceA
        a :someType ;
        dcterms:title "Concept Resource A" ;
        :color "red" ;
        dcterms:description "Concept resource A as it appears in the state with the URI :conceptResourceA-version17" .

While the Linked Data Platform indicates that every concept resource should define at least one rdf:type, current practice does not require a type property on the version resource.

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 = {
    :conceptResourceA-version23
        dcterms:isVersionOf :conceptResourceA .
    :conceptResourceA
        a :someType ;
        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 = {
    :conceptResourceA-version17
        dcterms:isVersionOf :conceptResourceA .
    :conceptResourceA
        a :someType ;
        dcterms:title "Concept Resource A" ;
        :color "red" ;
        dcterms:description "Concept resource A as it appears in the state with the URI :conceptResourceA-version17" .
}.

Configuration Item

Resources of any type may appear as configuration items - resource that appear as members of configurations or change sets. Configuration items MAY have any of the common properties shown above, and MAY have any other properties. Configuration items that represent versions of a concept resource MUST have the dcterms:isVersionOf property referencing that concept resource. Configuration items that are versioned resources have the following additional properties:

Configuration

A configuration is a Linked Data Platform Container resource with the common properties, plus the following:

Component

A component is a Linked Data Platform Container identifying a set of resources that are configured together as a unit. The granularity of a component varies between providers, but typically it contains the set of resources of some type being used in some project, or a subdivision of such a set. A component has the common properties, plus the following:

A component itself MAY be a versioned resource, indicated by the presence of the dcterms:isVersionOf property referencing the component concept resource.

Configuration context

The initial configuration context is to be established by the user and the system in an appropriate manner - possibly stored in a preference, picked up from an initial resource, selected from a dialog, etc.

While navigating between resources, resources of certain types MAY indicate that a different context is to be used when followings links from that resource. TBD. For example, if a member of the current configuration context is itself a configuration, that sub-configuration MUST be used as the context for resources contained in that sub-configuration. Alternatively, the RELM 1.0 RDF Specification shows use of the vvc:foreignConfiguration predicate to indicate a switch in the configuration context. We need a standard way to express the resource types and predicates to be used for this purpose.

A client may request a specific configuration context in one of four ways. TBD: we need to simplify this. URIs for resources-in-a-configuration-context, whatever their form, should be obtained from providers in some standard manner: clients should never need to construct such URIs themselves - for example, using string manipulation to append a query string.

• When performing a GET on a concept URI, add an X-OSLC-Configuration-Context header, passing the URI of a configuration resource as the value:

    GET /resources/conceptResourceA HTTP/1.1
    X-OSLC-Configuration-Context: http://example.com/configurations/myConfiguration1

• When performing a GET on a concept URI, add a query string oslc_config.context and the encoded configuration URI to the end of the request URI:

    GET /resources/conceptResourceA?oslc_config.context=&3Chttp&3A//example.com/configurations/myConfiguration1&3E HTTP/1.1

• When performing a GET on a configuration URI, add an X-OSLC-Concept-Resource header, passing the URI of a concept resource as the value:

    GET /configurations/myConfiguration1 HTTP/1.1
    X-OSLC-Concept-Resource: http://example.com/resources/conceptResourceA

• When performing a GET on a configuration URI, add a query string oslc_config.concept_resource and the encoded concept resource URI to the end of the request URI:

    GET /configurations/myConfiguration1?oslc_config.concept_resource=&3Chttp&3A//example.com/resources/conceptResourceA&3E HTTP/1.1

Links should be created using the appropriate URI form for the given type of link - a URI for a version resource for links from change sets and most link types from change requests, and a URI for a concept resource for traceability links between versioned resources, or (rarely) a URI for a concept resource plus a configuration context for a link to the current version of the resource in that named context.

Version skew

In large or complex systems, it is often the case that two or more different versions of the same artifact or component are used in different places in that system. This often surfaces at the granularity of components or sub-configurations in larger aggregate or composite configurations, where two different components in turn use two different versions of a shared sub-component.

In situations with version skew, a GET request for a concept resource in the context of the top-level aggregate or composite configuration is ambiguous, and MUST fail with a 409 Conflict HTTP status code. The client may reissue the request with a more specific configuration context. Providers MAY allow other methods for disambiguating requests in the presence of version skew, such as some form of path or location information.

Change set

A change set is a resource with any of the above-listed standard properties, plus the following:

Creation Factories

A configuration provider MUST provide a creation factory for new configurations. A configuration provider MAY provide a creation factory for configuration items, but this specification does not determine the semantics of or required properties for configuration item factories.

Delegated UIs

A configuration provider SHOULD delegated user interface dialogs for creation and selection of configurations. A configuration provider MAY also provide delegated dialogs for creation and selection of configuration items.

OSLC Core properties used by all Configuration Management resources

Concept resources and version resources

A GET on the URI of a concept resource resolves that URI to an appropriate state of (version of) a concept resource for the appropriate configuration context (see later). The returned resource may 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 may be done using RDF named graphs.

The dcterms:isVersionOf property relates the version resource itself to its concept resource; this property is mandatory for all versioned resources.

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

    :conceptResourceA-version23
        dcterms:isVersionOf :conceptResourceA .
    :conceptResourceA
        a :someType ;
        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
        dcterms:isVersionOf :conceptResourceA .
    :conceptResourceA
        a :someType ;
        dcterms:title "Concept Resource A" ;
        :color "red" ;
        dcterms:description "Concept resource A as it appears in the state with the URI :conceptResourceA-version17" .

While the Linked Data Platform indicates that every concept resource should define at least one rdf:type, current practice does not require a type property on the version resource.

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 = {
    :conceptResourceA-version23
        dcterms:isVersionOf :conceptResourceA .
    :conceptResourceA
        a :someType ;
        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 = {
    :conceptResourceA-version17
        dcterms:isVersionOf :conceptResourceA .
    :conceptResourceA
        a :someType ;
        dcterms:title "Concept Resource A" ;
        :color "red" ;
        dcterms:description "Concept resource A as it appears in the state with the URI :conceptResourceA-version17" .
}.

Configuration Item

Resources of any type may appear as configuration items - resource that appear as members of configurations or change sets. Configuration items MAY have any of the common properties shown above, and MAY have any other properties. Configuration items that represent versions of a concept resource MUST have the dcterms:isVersionOf property referencing that concept resource.

Configuration

A configuration is a Linked Data Platform Container resource with the common properties, plus the following:

Component

A component is a Linked Data Platform Container identifying a set of resources that are configured together as a unit. The granularity of a component varies between providers, but typically it contains the set of resources of some type being used in some project, or a subdivision of such a set. A component has the common properties, plus the following:

A component itself MAY be a versioned resource, indicated by the presence of the dcterms:isVersionOf property referencing the component concept resource.

Configuration context

The initial configuration context is to be established by the user and the system in an appropriate manner - possibly stored in a preference, picked up from an initial resource, selected from a dialog, etc.

While navigating between resources, resources of certain types MAY indicate that a different context is to be used when followings links from that resource. TBD. For example, if a member of the current configuration context is itself a configuration, that sub-configuration MUST be used as the context for resources contained in that sub-configuration. Alternatively, the RELM 1.0 RDF Specification shows use of the vvc:foreignConfiguration predicate to indicate a switch in the configuration context. We need a standard way to express the resource types and predicates to be used for this purpose.

A client may request a specific configuration context in one of four ways. TBD: we need to simplify this. URIs for resources-in-a-configuration-context, whatever their form, should be obtained from providers in some standard manner: clients should never need to construct such URIs themselves - for example, using string manipulation to append a query string.

• When performing a GET on a concept URI, add an X-OSLC-Configuration-Context header, passing the URI of a configuration resource as the value:

    GET /resources/conceptResourceA HTTP/1.1
    X-OSLC-Configuration-Context: http://example.com/configurations/myConfiguration1

• When performing a GET on a concept URI, add a query string oslc_config.context and the encoded configuration URI to the end of the request URI:

    GET /resources/conceptResourceA?oslc_config.context=&3Chttp&3A//example.com/configurations/myConfiguration1&3E HTTP/1.1

• When performing a GET on a configuration URI, add an X-OSLC-Concept-Resource header, passing the URI of a concept resource as the value:

    GET /configurations/myConfiguration1 HTTP/1.1
    X-OSLC-Concept-Resource: http://example.com/resources/conceptResourceA

• When performing a GET on a configuration URI, add a query string oslc_config.concept_resource and the encoded concept resource URI to the end of the request URI:

    GET /configurations/myConfiguration1?oslc_config.concept_resource=&3Chttp&3A//example.com/resources/conceptResourceA&3E HTTP/1.1

Links should be created using the appropriate URI form for the given type of link - a URI for a version resource for links from change sets and most link types from change requests, and a URI for a concept resource for traceability links between versioned resources, or (rarely) a URI for a concept resource plus a configuration context for a link to the current version of the resource in that named context.

Version skew

In large or complex systems, it is often the case that two or more different versions of the same artifact or component are used in different places in that system. This often surfaces at the granularity of components or sub-configurations in larger aggregate or composite configurations, where two different components in turn use two different versions of a shared sub-component.

In situations with version skew, a GET request for a concept resource in the context of the top-level aggregate or composite configuration is ambiguous, and MUST fail with a 409 Conflict HTTP status code. The client may reissue the request with a more specific configuration context. Providers MAY allow other methods for disambiguating requests in the presence of version skew, such as some form of path or location information.

Change set

A change set is a resource with any of the above-listed standard properties, plus the following:

Creation Factories

A configuration provider MUST provide a creation factory for new configurations. A configuration provider MAY provide a creation factory for configuration items, but this specification does not determine the semantics of or required properties for configuration item factories.

Delegated UIs

A configuration provider SHOULD delegated user interface dialogs for creation and selection of configurations. A configuration provider MAY also provide delegated dialogs for creation and selection of configuration items.