Revision: Configuration Management Resource Definitions

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.

We use the dcterms:isVersionOf property to relate the version resource itself to its concept resource.

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 resource with any of the above-listed standard properties, plus the following:

A configuration MAY be a versioned resource, in which case it has a dcterms:isVersionOf predicate identifying the concept resource. All configurations with the same object value for dcterms:isVersionOf are versions of the same concept resource - perhaps the same system or component.

Configurations MAY be members of other configurations. In the case of global configurations (configurations that aggregate configurations from multiple providers), configurations are the only permitted members.

Note that configurations do not have status, workflow, or lifecycle properties; instead, we expect other resources that define such status to link to configurations. These other resources might be Change Requests, or resources from some as-yet undefined OSLC Lifecycle or Process Domain.

The structures commonly known as streams and baselines are represented by configurations linked from a resource with appropriate status values.

See Configuration Operations.

TBD:

• Dependencies (configurations on which this configuration depends)
• Dimension values for labeling

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

Clients may also use version resource URIs, but are discouraged from persisting such URIs in links, since that reduces the flexibility permitted by configuration management.

Change set

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