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 will resolve that URI to an appropriate state of (version of) a concept resource for the appropriate configuration context (see later). The returned resource will contain RDF statements about both the version resource and the concept resource; most statements will use the concept resource as the subject, because it is the state of (properties of) the concept resource that are defined by a version resource.

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

TBD: while the Linked Data Platform indicates that every concept resource should define at least one rdf:type, it is not clear if we always need to define a separate type for the version resource itself. This should be discussed with the Core workgroup.

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.

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 entity commonly termed a baseline is a configuration linked from a resource with some appropriate status resource.

TBD: * Dependencies (configurations on which this configuration depends) * Baselines created from this configuration * Baselines merged into this configuration

Configuration context

A client may request a specific configuration context in one of two ways.

• Adding 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

• Adding 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

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: