HistoryViewLinks to this page 2014 May 9 | 11:57 am

Superseded by OASIS draft spec

Contents


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:

OSLC Core properties used by all Configuration Management resources

Prefixed Name Occurs Read-only Value-type Representation Description
OSLC Core: Common Properties
rdf:type one-or-many unspecified Resource Reference The resource type URIs.
dcterms:contributor zero-or-many unspecified Resource Either Contributor or contributors to resource (reference: Dublin Core). It is likely that the target resource is a foaf:Person but that is not necessarily the case.
dcterms:created zero-or-one True DateTime n/a Timestamp of resource creation (reference: Dublin Core)
dcterms:creator zero-or-many unspecified Resource Either Creator or creators of resource (reference: Dublin Core). It is likely that the target resource is a foaf:Person but that is not necessarily the case.
dcterms:description zero-or-one unspecified XMLLiteral n/a Descriptive text (reference: Dublin Core) about resource represented as rich text in XHTML content. SHOULD include only content that is valid and suitable inside an XHTML <div> element.
dcterms:identifier exactly-one True String n/a A unique identifier for a resource. For versioned resources, this identifier is unique across all versions of all resources, not just unique across the concept resources. This property is assigned by the service provider when a resource is created, and is not necessarily intended for end-user display.
dcterms:modified zero-or-one True DateTime n/a Timestamp of latest resource modification (reference: Dublin Core). Each resource SHOULD have one instance of this property.
dcterms:subject zero-or-many unspecified String n/a Tag or keyword for a resource. Each occurrence of a dcterms:subject property denotes an additional tag for the resource.
dcterms:title exactly-one unspecified XMLLiteral n/a Title (reference: Dublin Core) of the resource represented as rich text in XHTML content.
oslc:serviceProvider zero-or-many True Resource Reference A link to the resource’s OSLC Service Provider. There may be cases when the subject resource is available from a service provider that implements multiple domain specifications, which could result in multiple values for this property.
oslc:instanceShape zero-or-one unspecified Resource Reference The URI of a Resource Shape that describes the possible properties, occurrence, value types, allowed values and labels. This shape information is useful in displaying the subject resource as well as guiding clients in performing modifications. Instance shapes may be specific to the authenticated user associated with the request that retrieved the resource, the current state of the resource and other factors and thus should not be cached.
oslc:shortTitle zero-or-one unspecified XMLLiteral n/a Optional: a shorter form of dcterms:title for the resource represented as rich text in XHTML content. SHOULD include only content that is valid inside an XHTML <span> element.
oslc:shortId zero-or-one unspecified String n/a Optional: a shorter and human-readable form of dcterms:identifier for the resource, such as a number.
oslc:modifiedBy zero-or-many unspecified Resource Either The URI of a resource describing the entity that most recently modified the subject resource. The link target is usually a foaf:Person or foaf:Agent, but could be any type. This is modeled after dcterms:creator, but Dublin Core currently has no equivalent property.
W3C Provenance Properties
prov:wasDerivedFrom, prov:wasRevisionOf zero-or-many unspecified Resource Either Previous versions or revisions of this resource.
prov:wasGeneratedBy zero-or-many unspecified Resource Either A change set or similar activity that generated this resource. It is likely that the target resource is an oslc_config:ChangeSet or an oslc_cm:ChangeRequest but that is not necessarily the case.

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:

Prefixed Name Occurs Read-only Value-type Representation Description
dcterms:isVersionOf exactly-one unspecified Resource Reference The concept resource URI. All versions of the same concept resource have the same value of this property.
oslc_config:versionId zero-or-one unspecified String n/a A short human-readable identifier for the version of a resource. All versioned resources SHOULD have this property; where the property is present, this identifier MUST be unique amongst all currently existing versions of the same concept resource.

Configuration

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

Prefixed Name Occurs Read-only Value-type Representation Description
rdf:type one-or-many unspecified Resource Reference The resource type URIs. A configuration MUST have a resource type of oslc_config:Configuration. A configuration that contains or aggregates other configurations MUST also have a resource type of ldp:Container or one of its subclasses. The members of this container are the aggregated configurations.
rdfs:member or other predicate defined by ldp:containsRelation or ldp:containedByRelation zero-or-many unspecified Resource Reference The member configurations of this configuration.
oslc_config:component one-or-many false Resource Reference The component of which this is a configuration. The component identifies the set of resources (configuration items) in the configuration.
oslc_config:mutable exactly-one true Boolean n/a Whether the set of versioned artifact states selected by this configuration can be changed. Note that this property may not be modified directly, but there are explicit operations to create mutable configurations (streams) from immutable baselines, and vice versa. Other than this flag, 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.
oslc_config:action zero-or-many true Resource Either The referenced resources MUST be of type oslc_config:Action. This property indicates one of the available action that may be performed on this configuration. See Configuration Operations.

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:

Prefixed Name Occurs Read-only Value-type Representation Description
rdf:type one-or-many unspecified Resource Reference The resource type URIs. A component MUST have a resource type of ldp:Container or one of its subclasses. The members of this container are the version resources (configuration items) in this component. Note that a GET an a component in the context of a configuration MUST return the version resource URIs of the members.
rdfs:member or other predicate defined by ldp:containsRelation or ldp:containedByRelation zero-or-many unspecified Resource Reference The member resources (configuration items) in this component. When fetching this property in the context of a configuration of this component, versioned resource members MUST be identified by a URI specific to the version of the resource in that context.

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:

Prefixed Name Occurs Read-only Value-type Representation Description
rdf:type one-or-many unspecified Resource Reference The resource type URIs. A change set MUST have a resource type of oslc_config:ChangeSet, and SHOULD have a resource type of ldp:Container or one of its subclasses. The Linked Data Platform container or aggregate is used to indicate the configuration items that are members of (contents of) the change set. For added and modified resources, it is likely that these membership links use version resource URIs to point to the version of the resource that is the result of the specified change; the version of the resource before the specified change may then be found using the provenance link prov:wasRevisionOf.

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.