Notices

Copyright © OASIS Open 2013-2021. All Rights Reserved.

All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.

This specification is published under the Attribution 4.0 International (CC BY 4.0). Portions of this specification are also provided under the Apache License 2.0.

All contributions made to this project have been made under the OASIS Contributor License Agreement (CLA).

For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Open Projects IPR Statements page.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Open Project or OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Project Specification or OASIS Standard, to notify the OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification.

OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Open Project that produced this specification. OASIS may include such claims on its website, but disclaims any obligation to do so.

OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Open Project Specification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.

The name "OASIS" is a trademark of OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see https://www.oasis-open.org/policies-guidelines/trademark for above guidance.

Table of Contents

1. Introduction

This section is non-normative.

1.1 Typographical Conventions and Use of RFC Terms

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

1.2 References

1.2.1 Normative references

[ABNF]
D. Crocker; P. Overell. Augmented BNF for Syntax Specifications: ABNF. IETF. Internet Standard. URL: https://tools.ietf.org/html/rfc5234
[CORS]
WHATWG contributors. Fetch standard. WHATWG. Living Standard. URL: https://fetch.spec.whatwg.org/commit-snapshots/d070ea245c6eb66cf4196324f063dc6ab608d9e6/#http-cors-protocol
[OSLCCore3]
Jim Amsden. OSLC Core Version 3.0. Part 1: Overview. OASIS. URL: https://docs.oasis-open-projects.org/oslc-op/core/v3.0/oslc-core.html
[OSLCQuery]
Jim Amsden; S. Padgett; S. Speicher; David Honey. OSLC Query Version 3.0. OASIS. URL: https://docs.oasis-open-projects.org/oslc-op/query/v3.0/oslc-query.html
[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. IETF, March 1997. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119
[RFC8174]
B. Leiba. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. IETF, May 2017. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc8174
[URI]
T. Berners-Lee; P. Overell. Uniform Resource Identifier (URI): Generic Syntax. IETF. Internet Standard. URL: https://datatracker.ietf.org/doc/html/rfc3986/#section-1.3

2. Service Discovery

A configuration server SHOULD implement [OSLCCore3] ServiceProvider and Service resources, where an oslc:domain property has the value http://open-services.net/ns/config#. [CONFIG-RES-1]

A global configuration service resource, if provided, SHOULD include the property oslc:usage with the value http://open-services.net/ns/config#globalConfigurationService. [CONFIG-RES-2]

A service with this usage property MUST provide all global configuration capabilities described as mandatory in this specification. [CONFIG-RES-3]

3. Component and Configuration Constraints

This section describes constraints on the resources for components, configurations, and related artifacts.

Configuration Management servers MUST observe these constraints, but MAY provide additional classes, properties, and individuals. [CONFIG-RES-4]

In particular, Configuration Management servers MAY define additional types of configuration, but all configurations MUST also be of one of the types defined here. [CONFIG-RES-5]

3.1 Resource shape for Component

Component Properties
Prefixed Name Occurs Read-only Value-type Representation Range Description
dcterms:contributor Zero-or-many unspecified AnyResource Either foaf:Agent, foaf:Person Contributor or contributors to the resource. The link target is usually a foaf:Person or foaf:Agent, but could be any type.
dcterms:created Zero-or-one true dateTime N/A Unspecified Timestamp of resource creation. Each resource SHOULD have one instance of the dcterms:created property [CONFIG-RES-7].
dcterms:creator Zero-or-many true AnyResource Either foaf:Agent, foaf:Person Creator or creators of the resource. The link target is usually a foaf:Person or foaf:Agent, but could be any type.
dcterms:description Zero-or-one false XMLLiteral N/A Unspecified Descriptive text about the resource, represented as rich text in XHTML content.
dcterms:identifier Zero-or-one true string N/A Unspecified A unique identifier for this resource.
dcterms:modified Zero-or-one true dateTime N/A Unspecified Timestamp of latest resource modification. Each resource SHOULD have one instance of the dcterms:modified property [CONFIG-RES-8].
dcterms:subject Zero-or-many false string N/A Unspecified Tag or keyword for a resource. Each occurrence of a dcterms:subject property denotes an additional tag for the resource.
dcterms:title Zero-or-one false XMLLiteral N/A Unspecified Title of the resource, represented as rich text in XHTML content.
oslc_config:configurations Exactly-one true Resource Reference ldp:Container The Linked Data Platform Container that contains all the configurations (both streams and baselines) of this component. The oslc_config:configurations property on a component is read-only; servers MAY also treat the referenced container as read-only [CONFIG-RES-9]. If it is not read-only, the container MAY have an oslc:resourceShape property referencing a resource shape that describes the container [CONFIG-RES-10]. If a container resource shape is specified, the shape SHOULD have a property describing the membership of the container with a oslc:valueShape referencing a resource shape that describes the shapes of streams and baselines that may be created [CONFIG-RES-11].
oslc:archived Zero-or-one unspecified boolean N/A Unspecified Indicates whether the subject has been marked as archived, no longer an active resource.
oslc:instanceShape Zero-or-one true Resource Either oslc:ResourceShape 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, so instance shapes SHOULD NOT be cached [CONFIG-RES-12].
oslc:modifiedBy Zero-or-many true AnyResource Either foaf:Agent, foaf:Person 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.
oslc:serviceProvider Zero-or-many true Resource Reference oslc:ServiceProvider A link to the resource's OSLC Service Provider. If the subject resource is available from an application that implements multiple domain specifications, there can be multiple values for this property.
oslc:shortId Zero-or-one unspecified string N/A Unspecified A short and human-readable identifier for the resource, such as a number.
oslc:shortTitle Zero-or-one unspecified XMLLiteral N/A Unspecified A short title for the resource, represented as rich text in XHTML content.
rdf:type One-or-many unspecified Resource Reference rdfs:Class A resource type URI. A Component MUST have a resource type of oslc_config:Component [CONFIG-RES-13]. A component MAY be a Linked Data Platform Container, containing the concept resources associated with this component [CONFIG-RES-14]. The members of such an oslc_config:Component container MUST NOT be of type oslc_config:Configuration [CONFIG-RES-15]; sub-configurations are given in the oslc_config:contributions property. No meaning is assigned to a member of type oslc_config:Component; neither client nor server is obligated to perform any recursion through nested Components. Servers MAY treat the rdf:type property for a component as read-only. [CONFIG-RES-16]

3.2 Resource shape for Baseline

Baseline Properties
Prefixed Name Occurs Read-only Value-type Representation Range Description
dcterms:contributor Zero-or-many true AnyResource Either foaf:Agent, foaf:Person Contributor or contributors to the resource. The link target is usually a foaf:Person or foaf:Agent, but could be any type.
dcterms:created Zero-or-one true dateTime N/A Unspecified Timestamp of resource creation. Each resource SHOULD have one instance of the dcterms:created property [CONFIG-RES-18].
dcterms:creator Zero-or-many true AnyResource Either foaf:Agent, foaf:Person Creator or creators of the resource. The link target is usually a foaf:Person or foaf:Agent, but could be any type.
dcterms:description Zero-or-one unspecified XMLLiteral N/A Unspecified Descriptive text about the resource, represented as rich text in XHTML content. The description of a baseline MAY be modifiable [CONFIG-RES-19].
dcterms:identifier Zero-or-one true string N/A Unspecified A unique identifier for this resource.
dcterms:modified Zero-or-one true dateTime N/A Unspecified Timestamp of latest resource modification. Each resource SHOULD have one instance of the dcterms:modified property [CONFIG-RES-20].
dcterms:subject Zero-or-many false string N/A Unspecified Tag or keyword for a resource. Each occurrence of a dcterms:subject property denotes an additional tag for the resource. Tags on baselines MUST be modifiable [CONFIG-RES-21].
dcterms:title Zero-or-one false XMLLiteral N/A Unspecified Title of the resource, represented as rich text in XHTML content. The title of a baseline SHOULD be modifiable [CONFIG-RES-22].
oslc_config:acceptedBy Zero-or-many true Resource Reference rdfs:Class A type of configuration that accepts this configuration as a contribution. A configuration with no value for oslc_config:acceptedBy MUST NOT be used as a contribution to any other configuration [CONFIG-RES-23] - that is, it can only be a root of a configuration hierarchy (or a stand-alone configuration if there is also no value for oslc_config:accepts). Such configurations should be rare.
oslc_config:baselineOfStream Exactly-one true Resource Reference oslc_config:Configuration Indicates the stream of which this is a baseline. Note that the referenced resource might no longer exist (streams are mutable so can be deleted), but this property remains valuable to relate all baselines of the same stream.
oslc_config:branch Zero-or-one true Resource Either Unspecified An indicator of the intended purpose of the baseline.
oslc_config:committed Zero-or-one true dateTime N/A Unspecified Date and time this configuration was committed as a baseline.
oslc_config:committer Zero-or-many true AnyResource Either foaf:Agent, foaf:Person The entity that committed this configuration as a baseline. The link target is usually a foaf:Person or foaf:Agent, but could be any type.
oslc_config:component Exactly-one true Resource Reference oslc_config:Component The component of which this is a configuration, and from which the configuration selects versions of resources in the component. The component is an invariant relating the different configurations of the same 'thing'.
oslc_config:contribution Zero-or-many true AnyResource Inline oslc_config:Contribution A contribution to this baseline. The set of resource versions identified by this baseline is the union of the set determined by the oslc_config:selections resources and each of the sets of resource versions identified by the contributed baselines. The target MUST be of type oslc_config:Contribution [CONFIG-RES-24]. Contribution resources MUST be returned inline with the baseline resource [CONFIG-RES-25]. In the set of Contribution resources for a single parent baseline, there MUST be only one Contribution resource for a given contributed baseline [CONFIG-RES-26].
oslc_config:previousBaseline Zero-or-many true Resource Reference oslc_config:Baseline A reference to the immediately preceding baseline of the same stream. Multiple instances of this property imply the stream was merged from one or more baselines before this baseline was taken. This property MAY be updated by the server to refer to earlier baselines when intermediate baselines are deleted [CONFIG-RES-27].
oslc_config:selections Zero-or-many true Resource Reference oslc_config:Selections A reference to a resource identifying immutable versions of the resources (configuration items) in the configuration. The set of version resources identified is the union of the sets in all the selections resources. Since selections properties are not ordered, there is no defined meaning to a selection that appears in two or more different selections properties; servers MAY treat such multiple occurrences of selections as an error [CONFIG-RES-28].
oslc_config:streams Exactly-one true Resource Reference ldp:Container The Linked Data Platform Container that contains all the streams derived from this baseline. A new stream derived from this baseline is created by a POST to this container; a previousBaseline property of the new stream MUST be set to refer to this baseline [CONFIG-RES-29]. Note that the streams property itself is immutable, but the container referenced by the property is not. The container MAY have an oslc:resourceShape property referencing a resource shape that describes the container [CONFIG-RES-30]. If a container resource shape is specified, it should have a property describing the membership of the container with a `oslc:valueShape` referencing a resource shape that describes the shapes of streams that may be created [CONFIG-RES-31].
oslc:archived Zero-or-one unspecified boolean N/A Unspecified Indicates whether the subject has been marked as archived, no longer an active resource.
oslc:instanceShape Zero-or-one true Resource Either oslc:ResourceShape 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, so instance shapes SHOULD NOT be cached [CONFIG-RES-32].
oslc:modifiedBy Zero-or-many true AnyResource Either foaf:Agent, foaf:Person 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.
oslc:release Zero-or-many false Resource Reference Unspecified A link to a resource indicating a target release for the artifacts selected by this configuration.
oslc:serviceProvider Zero-or-many true Resource Reference oslc:ServiceProvider A link to the resource's OSLC Service Provider. If the subject resource is available from an application that implements multiple domain specifications, there can be multiple values for this property.
oslc:shortId Zero-or-one unspecified string N/A Unspecified A short and human-readable identifier for the resource, such as a number.
oslc:shortTitle Zero-or-one unspecified XMLLiteral N/A Unspecified A short title for the resource, represented as rich text in XHTML content.
prov:wasDerivedFrom Zero-or-many true Resource Reference oslc_config:Configuration A stream or baseline from which this stream was first copied. This property can be absent for streams created as new empty streams. Multiple instances of this property imply the stream was initially formed from a merge from one or more baselines. The prov:wasDerivedFrom property is undefined for baselines; it MAY be absent, or it MAY have the same value as oslc_config:baselineOfStream [CONFIG-RES-33]. If this property is present on multiple change sets overriding the same base configuration, it implies a partial ordering of those change sets, identifying change sets derived from earlier change sets on the same base. Servers SHOULD treat this property as read-only after initial creation [CONFIG-RES-34].
rdf:type One-or-many unspecified Resource Reference rdfs:Class A resource type URI. A baseline MUST have at least the resource type oslc_config:Baseline [CONFIG-RES-35]. Clients can infer a resource type of oslc_config:Configuration, but there is no requirement for servers to materialize this triple in the RDF representation. Other types MAY be added, including types that are used in oslc_config:accepts and oslc_config:acceptedBy properties [CONFIG-RES-36] to define which matching configurations may be added as contributions to this configuration, or to which this configuration may be added as a contribution. Servers MAY treat the rdf:type property of a baseline as read-only [CONFIG-RES-37].

3.3 Resource shape for Stream

Stream Properties
Prefixed Name Occurs Read-only Value-type Representation Range Description
dcterms:contributor Zero-or-many unspecified AnyResource Either foaf:Agent, foaf:Person Contributor or contributors to the resource. The link target is usually a foaf:Person or foaf:Agent, but could be any type.
dcterms:created Zero-or-one true dateTime N/A Unspecified Timestamp of resource creation. Each resource SHOULD have one instance of the dcterms:created property [CONFIG-RES-38].
dcterms:creator Zero-or-many true AnyResource Either foaf:Agent, foaf:Person Creator or creators of the resource. The link target is usually a foaf:Person or foaf:Agent, but could be any type.
dcterms:description Zero-or-one false XMLLiteral N/A Unspecified Descriptive text about the resource, represented as rich text in XHTML content.
dcterms:identifier Zero-or-one true string N/A Unspecified A unique identifier for this resource.
dcterms:modified Zero-or-one true dateTime N/A Unspecified Timestamp of latest resource modification. Each resource SHOULD have one instance of the dcterms:modified property [CONFIG-RES-39].
dcterms:subject Zero-or-many false string N/A Unspecified Tag or keyword for a resource. Each occurrence of a dcterms:subject property denotes an additional tag for the resource.
dcterms:title Zero-or-one false XMLLiteral N/A Unspecified Title of the resource, represented as rich text in XHTML content.
oslc_config:acceptedBy Zero-or-many true Resource Reference rdfs:Class A type of configuration that accepts this configuration as a contribution. A configuration with no value for oslc_config:acceptedBy MUST NOT be used as a contribution to any other configuration [CONFIG-RES-40] - that is, it can only be a root of a configuration hierarchy (or a stand-alone configuration if there is also no value for oslc_config:accepts). Such configurations should be rare.
oslc_config:accepts Zero-or-many true Resource Reference rdfs:Class A type of configuration that is acceptable as a contribution to this stream. A configuration with no value for this predicate accepts no contributions - that is, it can only be a leaf in a configuration hierarchy.
oslc_config:baselines Exactly-one true Resource Reference ldp:Container The Linked Data Platform Container that contains all the baselines of this stream. A new baseline of this stream is created by a POST to this container. Note that the baselines property itself is immutable, but the container referenced by the property is not. The container MAY have an oslc:resourceShape property referencing a resource shape that describes the container [CONFIG-RES-41]. If a container resource shape is specified, it SHOULD have a property describing the membership of the container with a oslc:valueShape referencing a resource shape that describes the additional properties that may be specified for baselines [CONFIG-RES-42].
oslc_config:branch Zero-or-one false Resource Either Unspecified An indicator of the intended purpose of the configuration.
oslc_config:component Exactly-one true Resource Reference oslc_config:Component The component of which this is a configuration, and from which the configuration selects versions of resources in the component. The component is an invariant relating the different configurations of the same 'thing'.
oslc_config:contribution Zero-or-many false AnyResource Inline oslc_config:Contribution A contribution to this configuration. The set of resource versions identified by this configuration is the union of the set determined by the oslc_config:selections resources and each of the sets of resource versions identified by the contributed configurations. A user can request an update to a configuration to change the set of contributions; servers MAY deny such requests if any added contributions do not match this configuration [CONFIG-RES-43]. The target MUST be of type oslc_config:Contribution [CONFIG-RES-44]. Contribution resources MUST be returned inline with the configuration resource [CONFIG-RES-45]. In the set of Contribution resources for a single parent configuration, there MUST be only one Contribution resource for a given contributed configuration [CONFIG-RES-46].
oslc_config:previousBaseline Zero-or-many true Resource Reference oslc_config:Baseline A reference to the immediately preceding baseline of this stream. Multiple instances of this property imply the stream was merged from one or more baselines, and no baseline of the merged result has yet been taken. If the property is absent, no baseline of this stream has been taken.
oslc_config:selections Zero-or-many unspecified Resource Reference oslc_config:Selections A reference to a resource identifying versions of the resources (configuration items) in the configuration. The set of version resources identified is the union of the sets in all the selections resources. Since selections properties are not ordered, there is no defined meaning to a selection that appears in two or more different selections properties; servers MAY treat such multiple occurrences of selections as an error [CONFIG-RES-47]. Servers MAY treat this property as read-only [CONFIG-RES-48].
oslc:archived Zero-or-one unspecified boolean N/A Unspecified Indicates whether the subject has been marked as archived, no longer an active resource.
oslc:instanceShape Zero-or-one true Resource Either oslc:ResourceShape 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, so instance shapes SHOULD NOT be cached [CONFIG-RES-49].
oslc:modifiedBy Zero-or-many true AnyResource Either foaf:Agent, foaf:Person 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.
oslc:release Zero-or-many false Resource Reference Unspecified A link to a resource indicating a target release for the artifacts selected by this configuration.
oslc:serviceProvider Zero-or-many true Resource Reference oslc:ServiceProvider A link to the resource's OSLC Service Provider. If the subject resource is available from an application that implements multiple domain specifications, there can be multiple values for this property.
oslc:shortId Zero-or-one unspecified string N/A Unspecified A short and human-readable identifier for the resource, such as a number.
oslc:shortTitle Zero-or-one unspecified XMLLiteral N/A Unspecified A short title for the resource, represented as rich text in XHTML content.
prov:wasDerivedFrom Zero-or-many true Resource Reference oslc_config:Configuration A stream or baseline from which this stream was first copied. This property can be absent for streams created as new empty streams. Multiple instances of this property imply the stream was initially formed from a merge from one or more baselines. The prov:wasDerivedFrom property is undefined for baselines; it MAY be absent, or it MAY have the same value as oslc_config:baselineOfStream [CONFIG-RES-50]. If this property is present on multiple change sets overriding the same base configuration, it implies a partial ordering of those change sets, identifying change sets derived from earlier change sets on the same base. Servers SHOULD treat this property as read-only after initial creation [CONFIG-RES-51].
rdf:type One-or-many unspecified Resource Reference rdfs:Class A resource type URI. A stream MUST have at least the resource type oslc_config:Stream [CONFIG-RES-52]. Clients can infer a resource type of oslc_config:Configuration, but there is no requirement for servers to materialize this triple in the RDF representation. Other types MAY be added, including types that are used in oslc_config:accepts and oslc_config:acceptedBy properties to define which matching configurations may be added as contributions to this configuration, or to which this configuration may be added as a contribution [CONFIG-RES-53]. Servers MAY treat this property as read-only [CONFIG-RES-54].

3.4 Resource shape for ChangeSet

ChangeSet Properties
Prefixed Name Occurs Read-only Value-type Representation Range Description
dcterms:contributor Zero-or-many unspecified AnyResource Either foaf:Agent, foaf:Person Contributor or contributors to the resource. The link target is usually a foaf:Person or foaf:Agent, but could be any type.
dcterms:created Zero-or-one true dateTime N/A Unspecified Timestamp of resource creation. Each resource SHOULD have one instance of the dcterms:created property [CONFIG-RES-57].
dcterms:creator Zero-or-many true AnyResource Either foaf:Agent, foaf:Person Creator or creators of the resource. The link target is usually a foaf:Person or foaf:Agent, but could be any type.
dcterms:description Zero-or-one false XMLLiteral N/A Unspecified Descriptive text about the resource, represented as rich text in XHTML content.
dcterms:identifier Zero-or-one true string N/A Unspecified A unique identifier for this resource.
dcterms:modified Zero-or-one true dateTime N/A Unspecified Timestamp of latest resource modification. Each resource SHOULD have one instance of the dcterms:modified property [CONFIG-RES-58].
dcterms:subject Zero-or-many false string N/A Unspecified Tag or keyword for a resource. Each occurrence of a dcterms:subject property denotes an additional tag for the resource.
dcterms:title Zero-or-one false XMLLiteral N/A Unspecified Title of the resource, represented as rich text in XHTML content.
oslc_config:acceptedBy Zero-or-many true Resource Reference rdfs:Class A type of configuration that accepts this configuration as a contribution. A configuration with no value for oslc_config:acceptedBy MUST NOT be used as a contribution to any other configuration [CONFIG-RES-59] - that is, it can only be a root of a configuration hierarchy (or a stand-alone configuration if there is also no value for oslc_config:accepts). Such configurations should be rare.
oslc_config:accepts Zero-or-many true Resource Reference rdfs:Class A type of configuration that is acceptable as a contribution to this stream. A configuration with no value for this predicate accepts no contributions - that is, it can only be a leaf in a configuration hierarchy.
oslc_config:branch Zero-or-one false Resource Either Unspecified An indicator of the intended purpose of the configuration.
oslc_config:component Exactly-one true Resource Reference oslc_config:Component The component of which this is a configuration, and from which the configuration selects versions of resources in the component. The component is an invariant relating the different configurations of the same 'thing'.
oslc_config:contribution Zero-or-many unspecified AnyResource Inline oslc_config:Contribution A contribution to this change set configuration. Servers MAY support contributions to change sets [CONFIG-RES-60], and if so, this property behaves just as that for streams.
oslc_config:overrides Exactly-one unspecified Resource Reference oslc_config:Configuration A reference to a configuration modified or overridden by this change set configuration.
oslc_config:selections Zero-or-many unspecified Resource Reference oslc_config:ChangeSetSelections A reference to a resource identifying versions of the resources (configuration items) in the configuration; these selections override, reduce, or extend the selections in the configuration identified by the oslc_config:overrides property. Servers MAY treat this property as read-only [CONFIG-RES-61].
oslc:archived Zero-or-one unspecified boolean N/A Unspecified Indicates whether the subject has been marked as archived, no longer an active resource.
oslc:instanceShape Zero-or-one true Resource Either oslc:ResourceShape 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, so instance shapes SHOULD NOT be cached [CONFIG-RES-62].
oslc:modifiedBy Zero-or-many true AnyResource Either foaf:Agent, foaf:Person 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.
oslc:release Zero-or-many false Resource Reference Unspecified A link to a resource indicating a target release for the artifacts selected by this configuration.
oslc:serviceProvider Zero-or-many true Resource Reference oslc:ServiceProvider A link to the resource's OSLC Service Provider. If the subject resource is available from an application that implements multiple domain specifications, there can be multiple values for this property.
oslc:shortId Zero-or-one unspecified string N/A Unspecified A short and human-readable identifier for the resource, such as a number.
oslc:shortTitle Zero-or-one unspecified XMLLiteral N/A Unspecified A short title for the resource, represented as rich text in XHTML content.
rdf:type One-or-many unspecified Resource Reference rdfs:Class A resource type URI. A change set configuration MUST have at least the resource type oslc_config:ChangeSet [CONFIG-RES-63]. Clients may infer a resource type of oslc_config:Configuration, but there is no requirement for servers to materialize this triple in the RDF representation. Other types may be added, including types that are used in oslc_config:accepts properties to define which matching configurations to which this configuration may be added as a contribution. Servers MAY treat this property as read-only [CONFIG-RES-64].

3.5 Resource shape for Contribution

Contribution Properties
Prefixed Name Occurs Read-only Value-type Representation Range Description
dcterms:modified Zero-or-one true dateTime N/A Unspecified Timestamp of latest resource modification. Each resource SHOULD have one instance of the dcterms:modified property [CONFIG-RES-65].
oslc_config:configuration Exactly-one unspecified Resource Reference oslc_config:Configuration The contributed configuration. This property is read-only for contributions to a baseline, and modifiable for contributions to a stream. On a PUT or POST of a Stream resource and its Contributions, this contributed configuration SHOULD be unique amongst the set of configurations contributed to a given parent configuration [CONFIG-RES-66]. a server MAY collapse multiple contributions for the same configuration to a single contribution [CONFIG-RES-67]. During such a reduction of multiple Contribution resources to a single Contribution resource, this specification does not define the contributionOrder value in the merged result.
oslc_config:contributionOrder Exactly-one unspecified string N/A Unspecified An indication of the order of the contribution, relative to other contributions. Contributions are sorted lexicographically on the Unicode code points of this value to resolve component skew. To ensure predictable sorting regardless of implementation and locale, the oslc_config:contributionOrder string SHOULD be restricted to ASCII characters [CONFIG-RES-68]. Servers MUST support at least 64 characters in this string [CONFIG-RES-69]. This property is read-only for contributions to a baseline, and modifiable for contributions to a stream.
oslc_config:overrides Exactly-one unspecified Resource Reference oslc_config:Configuration A reference to a configuration overridden by the configuration of this contribution.
rdf:type Zero-or-many true Resource Reference rdfs:Class A resource type URI. Clients can infer a resource type of oslc_config:Contribution, but there is no requirement for servers to materialize this triple in the RDF representation.

3.6 Resource shape for Selections

Selections Properties
Prefixed Name Occurs Read-only Value-type Representation Range Description
oslc_config:selects Zero-or-many unspecified Resource Reference Unspecified If the selection type is not oslc_config:UnboundSelections, the target resource MUST be a version resource [CONFIG-RES-70]. If the selection type is oslc_config:UnboundSelections, the target is a concept URI for a concept resource that should be in the configuration, but for which no version is determined by this selection. Unbound selections can be bound to specific versions by mechanisms not defined by this specification (such as effectivity parameters, variability parameters, etc.), or may be left unbound, in which case the configuration may represent an incomplete or abstract view of a system. Selected resources MUST NOT be of type oslc_config:Configuration [CONFIG-RES-71]; sub-configurations are given in the oslc_config:contributions property. No meaning is assigned to a selected resource of type oslc_config:Component. This property is read-only for selections of a baseline, but MAY be modifiable for selections of a stream [CONFIG-RES-72].
rdf:type One-or-many unspecified Resource Reference rdfs:Class A resource type URI. A Selections resource MUST have at least the resource type oslc_config:Selections [CONFIG-RES-73]. Selections resources MAY also have the type oslc_config:UnboundSelections [CONFIG-RES-74].

3.7 Resource shape for ChangeSet Selections

ChangeSetSelections Properties
Prefixed Name Occurs Read-only Value-type Representation Range Description
oslc_config:selects Zero-or-many unspecified Resource Reference Unspecified A selected version resource. Selected resources MUST NOT be of type oslc_config:Configuration [CONFIG-RES-75]; sub-configurations are given in the oslc_config:contributions property. No meaning is assigned to a selected resource of type oslc_config:Component. This property MAY be modifiable for selections of a change set [CONFIG-RES-76]. If the subject has the type oslc_config:RemoveAll, all selections in the overriden configuration are to be ignored; all selections are in this and other oslc_selects properties of the change set. Any target concept or version resources (depending on the presence or absence of the type oslc_config:UnboundSelections) indicated in this selection resource are selected in this configuration. Otherwise, if the subject has the type oslc_config:Removals, the indicated target concepts or versions are explicitly removed from the set of versions selected by the configuration overridden by this configuration. Otherwise, if the subject has only the type oslc_config:Selections, the indicated target concept or version resources are selected by this configuration; a change set selection overrides (replaces) the concepts or versions selected by a matching concept resource in the overridden configuration's selection, and adds additional selections for concept resources that are not mentioned in the overridden configuration's selection. Since selections properties are not ordered, there is no defined meaning to a selection that appears in two or more different selections properties of any types, or to a change set that include both a oslc_config:RemoveAll and a oslc_config:Removals selection; servers MAY treat occurrences of potentially conflicting selections as an error [CONFIG-RES-77].
rdf:type One-or-many unspecified Resource Reference rdfs:Class A resource type URI. A change set Selections resource MUST have at least the resource type oslc_config:Selections [CONFIG-RES-78]. Change set selections resources MAY also have the types oslc_config:ChangeSetSelections, oslc_config:UnboundSelections, oslc_config:Removals, or oslc_config:RemoveAll [CONFIG-RES-79].

4. Configuration context

Since concept resource URIs for versioned resources do not inherently identify a specific version of that resource, a client SHOULD provide a configuration context within which the concept resource is resolved to a specific version [CONFIG-RES-80].

A client requests a specific configuration context in one of two ways:

The Configuration-Context header is a URI that MUST conform to the following ABNF grammar [ABNF]: 

        SP = " "
        HTAB = %x09
        WSP = SP / HTAB

        header = config-context
        config-context = "Configuration-Context:" *WSP URI

Where the term URI is defined in [URI].

[CONFIG-RES-81]

Syntax of the query string for configuration context:

?oslc_config.context=uri_ref_esc

The uri_ref_esc is an angle bracket-delimited URI reference in which > and \ are \-escaped, as defined in [OSLCCore3].

A server MUST support both these methods of passing configuration context. [CONFIG-RES-82]

If a request contains both a header and a query string, the server MUST use the query string. Servers MUST reject requests that contain two or more different configuration contexts passed in query strings. [CONFIG-RES-83]

Where the Configuration-Context header is used on a request, a server SHOULD include in the response a header Vary=Configuration-Context so that different configuration contexts do not use a previously cached response. [CONFIG-RES-84]

Configuration Management servers SHOULD use the Access-Control-Allow-Headers header [CORS] to allow the use of the Configuration-Context header in OSLC requests. [CONFIG-RES-85]

A request SHOULD contain only a single occurrence of the Configuration-Context header, and MUST NOT contain multiple Configuration-Context headers referencing different values. A server SHOULD treat multiple identical Configuration-Context headers as it would a single header, and MUST treat multiple Configuration-Context headers with different configuration values as an error. [CONFIG-RES-86]

If a configuration context is passed on a request using the version URI for a versioned resource, a server MUST ignore the configuration context, even if that configuration context does not select that versioned resource. [CONFIG-RES-88]

Note

The client is responsible for providing the correct configuration context to each request issued by that client at least where the relevant resource might be a versioned resource. If a resource returned from such a request contains links, the client should not assume the server has returned version-specific or configuration-specific links, and the client should continue to provide the correct configuration context to fetch those related resources. Only in cases where the client knows that a resource is not versioned may the configuration context be omitted. As noted later, the compact rendering returned for UI Previews is an exception to this rule.

Note: Implicitly defined configuration contexts

While navigating between resources, resources or links of certain types may indicate that a different context is to be used when following links from that resource. Any such semantics should be defined by the specifications for such resource and link types; none are defined by this specification.

4.1 Default configuration

If a configuration context is not provided or implied, the server MAY provide a default configuration, or the request MAY fail. [CONFIG-RES-89]

An oslc_config:defaultConfiguration property with an rdf:nil value implies there is no default configuration, so requests with no context MUST fail. [CONFIG-RES-91]

Servers MAY support a PUT on oslc_config:ConfigurationsSettings resource as a way to set the default configuration. Servers MAY provide other ways for users to set the default configuration. [CONFIG-RES-92]

Note: Default configuration may be implicit

The absence of the oslc_config:defaultConfiguration has no implication as to the presence or absence of a default configuration.

5. Supported Operations on Components

A configuration server MUST support the following operations on components: [CONFIG-RES-93]

A configuration server SHOULD support, and a global configuration server MUST support, the following operations on Linked Data Platform Containers: [CONFIG-RES-94]

Servers SHOULD support the Prefer header for GET on LDPCs specifying PreferMinimalContainer: [CONFIG-RES-97]

Example 3
Prefer: return=representation; include="http://www.w3.org/ns/ldp#PreferMinimalContainer"

allowing a client to retrieve properties about the LDPC, including any oslc:resourceShape properties, without needing to retrieve all membership triples.

Servers MAY support OSLC selective properties on a GET, allowing a client to specify exactly which properties of those LDPCs are to be returned. [CONFIG-RES-98]

A configuration server SHOULD support, and a global configuration server MUST support one or more component creation factories declared in one or more OSLC service providers. [CONFIG-RES-99]

A configuration server SHOULD support one or more query capabilities for components. [CONFIG-RES-100]

6. Supported Operations on Configurations

A configuration server MUST support the following operations on configurations: [CONFIG-RES-101]

A configuration server SHOULD support, and a global configuration server MUST support, the following operations on configurations: [CONFIG-RES-102]

A configuration server MAY support PATCH on a configuration to update the tags and/or the set of contributed configurations. [CONFIG-RES-104]

Since baselines are normally linked into a provenance chain using the oslc_config:previousBaseline property, servers MAY leave a stub resource (one with a minimal set of properties) behind instead of truly deleting a baseline [CONFIG-RES-105]. Servers SHOULD add the property oslc:archived=TRUE on a reduced form of a partially deleted baseline [CONFIG-RES-106].

A configuration server SHOULD support one or more query capabilities for configurations. [CONFIG-RES-107]

7. Supported Operations on Selections

A configuration server MUST support the following operations on selections resources: [CONFIG-RES-108]

Note

Servers may treat selections resources as read-only.

8. Supported Operations on Versioned Resources in a Configuration Context

A configuration server MUST support the following operations on configuration items (versioned concept resources) in the context of a global configuration, or in the context of a configuration from this server: [CONFIG-RES-109]

A configuration server MAY support the following operations on configuration items in the context of a global configuration, or in the context of a configuration from this server: [CONFIG-RES-112]

9. Creation of Baselines and Streams

When a new component is created by POSTing to the Component Container, an empty baseline for that component SHOULD be created automatically, and MUST be added to the oslc_config:configurations container for that component. The empty baseline has no contributions, no selections, and no branch. [CONFIG-RES-114]

9.1 Creation of Streams

A new stream is created by POSTing to the oslc_config:streams container for a baseline. By default, the new stream inherits (MUST copy) the component, contributions, and selections of the baseline, but does not inherit (MUST NOT copy) the branch property. Other properties MAY be inherited (copied) from the baseline, or MAY be set to server defaults. The POSTed data MAY include any of the following properties; if these properties are supported by the server, then the POSTed values for these properties MUST completely replace any default or inherited values: [CONFIG-RES-115]

The server MUST set the oslc_config:previousBaseline property of the new stream, and SHOULD set the prov:wasDerivedFrom property of the new stream, to reference the baseline owning the oslc_config:streams container. [CONFIG-RES-116]

A server MAY support one or more configuration creation factories declared in one or more OSLC service providers that create a stream for the component specified in the configuration's POSTED RDF body. [CONFIG-RES-117]

9.2 Creation of Baselines

A new baseline of a stream is created by POSTing to the oslc_config:baselines container for that stream. If the server determines that a suitable baseline already exists, the server MAY return a 303 with a Location header referring to that existing baseline; for an existing baseline to be suitable it MUST be for the same component, MUST have the same oslc_config:branch value, if any, MUST select the same version resources, each contribution MUST be a suitable baseline for the corresponding stream contribution, and there must be no additional or missing contributions. [CONFIG-RES-118]

Where a new baseline is created, that new baseline inherits (MUST copy) the following properties of the stream: [CONFIG-RES-119]

Other properties MAY be inherited (copied) from the stream, or MAY be set to server defaults. The POSTed data MAY include any of the following properties; if these properties are supported by the server, then the POSTed values for these properties MUST completely replace any default or inherited values: [CONFIG-RES-120]

The server MUST set the oslc_config:baselineOfStream property of the new baseline to reference the stream owning the oslc_config:baselines container. [CONFIG-RES-122]

Since all contributions to a baseline must themselves be baselines, creation of a baseline requires that a server MUST first create or obtain baselines for the current state of all stream contributions, recursively downward through the contribution graph. See Long Operations. [CONFIG-RES-123]

9.3 Concerns common to streams and baselines

* A server MAY adjust the name properties of a configuration to maintain any name uniqueness constraints; a server SHOULD NOT fail creation of a baseline or stream just because the requested name is not unique. [CONFIG-RES-124]

The server MAY ignore any additional properties, or MAY return an error if those properties are considered incompatible with the creation request. [CONFIG-RES-125]

Any properties required on new streams or baselines not defined by this standard MUST be described in resource shapes referenced by oslc:resourceShape properties on the container. [CONFIG-RES-126]

Servers SHOULD support the Prefer header for GET on those LDPCs specifying PreferMinimalContainer: [CONFIG-RES-127]

Example 4
Prefer: return=representation; include="http://www.w3.org/ns/ldp#PreferMinimalContainer"

allowing a client to retrieve properties about the LDPC, including any oslc:resourceShape properties, without needing to retrieve all membership triples. Servers MAY support OSLC selective properties on a GET [CONFIG-RES-128], allowing a client to specify exactly which properties of those LDPCs are to be returned.

10. Contributions and Overrides

Global configurations, and possible other types of configuration, support aggregation of multiple configurations, using the oslc_config:Contribution resource. Changes to contributions are made using PUT. For change sets, and possibly other use cases, a configuration or contribution can override another configuration contributed to the overall hierarchy. An override relationship may be specified at the configuration level (for change sets that apply to a specific base configuration) or at the contribution level (allowing a hierarchy where some contributions may override others without modifying the properties of potentially shared configurations).

11. Version Resolution

When a request is made for a versioned resource in the context of a configuration:

  1. if there is no version of that resource in any of the selections in the contributions to the context configuration, nor in any of the selections in their recursive contributions, the request MUST fail with a 404 Resource not found (note that this includes unbound selections from a selection with type oslc_config:UnboundSelections) [CONFIG-RES-133]
  2. if there is exactly one version of that resource in the union of the selections in the recursive contributions, the request MUST return that one version [CONFIG-RES-134]
  3. if there is more than one version of that resource in the union of the selections in the recursive contributions, the behavior is implementation-defined, but SHOULD be well-defined in that the successive requests in the same configurations with the same selections SHOULD resolve to the same version. A server MAY perform an ordered search using the oslc_config:contributionOrder property, and MAY have a way to indicate multiple possible version resolutions [CONFIG-RES-135].
    Note

    The oslc_config:contributionOrder property is defined as a string rather than an integer to make it easier for servers to insert new contributions into an existing set without having to adjust the order value of existing contributions.

During this version resolution, overrides for entire configurations MUST be taken into account. If a contribution is marked as an override and the overriding configuration is earlier in the ordered set of all recursive contributions than the overridden configuration, the overridden configuration and all its contributions MUST be ignored in their entirety. Servers MAY report an error if an overriding configuration is later in the ordered set of all recursive contributions than the overridden configuration. [CONFIG-RES-136]

Overrides from change set configurations MUST also be taken into account. If a change set removes a selection for a versioned resource in the overridden configuration, and no other selection is provided for that resource in some other configuration, then the request MUST fail with a 404 Resource not found. If a change set replaces a selection for a versioned resource in the overridden configuration, and no other selection is provided for that resource in some other configuration, the request MUST return the version in the change set selection. [CONFIG-RES-137]

Implementations SHOULD provide documentation on their version resolution behavior. [CONFIG-RES-138]

12. Change Sets

This section is non-normative.

Some systems use change sets to group related changes, or changes to multiple resources that must be kept together. Change sets may be represented using a configuration of type oslc_config:ChangeSet - a special type of stream. Each oslc_config:ChangeSet resource is related to exactly one base configuration (either a stream or a baseline), using the oslc_config:overrides property. A oslc_config:ChangeSet has either a complete set of replacements for the versions selected by that base configuration, or a set of changes - a delta. The configuration defined by a change set thus identifies both the 'before' state (the base configuration that is overridden by this change set), and the 'after' state defined by the change set configuration itself.

Systems that allow multiple change sets to be applied to a single base configuration should represent each such internal change set as an oslc_config:ChangeSet resource using the same value of oslc_config:overrides; the property prov:wasDerivedFrom should be used to provide a complete or partial ordering of such change sets. Servers may also synthesize a combined oslc_config:ChangeSet resource representing the overall effect of multiple internal change sets.

When a change set is based on a stream (the oslc_config:overrides property on an instance of an oslc_config:ChangeSet refers to a configuration of type oslc_config:Stream), then the 'before' state is mutable, and may not represent the state at the time the change set was created. Servers can avoid this lack of precision by ensuring either that all changes made to a stream are captured in a change set based off that stream, or that the stream's oslc_config:selections properties accurately represent the sets of changes delivered to that stream before any of the change sets based on that stream (those change sets probably representing changes still pending for the stream).

Since the shape for a change set allows only a single value for oslc_config:overrides, systems that allow a single change set to be applied to multiple base configurations need to represent that internal change set by multiple oslc_config:ChangeSet resources. These copies may be associated with each other using properties such as http://purl.org/datanode/ns#isCopyOf, dcterms:relation, or similar.

13. Delegated UIs

All configuration servers MUST provide a delegated user interface dialog for selection of configurations. A global configuration server MUST provide, and a local configuration server MAY provide, a delegated user interface dialog for creation of configurations. [CONFIG-RES-139]

In order to provide a good user experience when selecting configurations to be used as contributions to a parent configuration, the UI Consumer SHOULD provide the URI of the parent configuration as a parameter to the Delegated UI Dialog, using the parameter oslc_config.parentConfiguration. UI Providers SHOULD use the types and oslc_config:accepts property values of that resource to filter the list of potential contributions shown in the selection dialog. [CONFIG-RES-140]

Syntax:

?oslc_config.parentConfiguration=uri_ref_esc

Example:

Example 5
?oslc_config.parentConfiguration=%3Chttps://example.com/configurations/globalConfig12%3E

Tools providing versioned resources using configuration management systems SHOULD provide delegated user interface dialogs for selection of versioned resources in the context of a configuration, and MAY provide delegated user interface dialogs for creation of versioned resources in the context of a configuration. [CONFIG-RES-141]

14. Compact Rendering

Configuration servers SHOULD implement [OSLCCore3] UI Previews and compact rendering. [CONFIG-RES-142]

Where implemented, clients MUST pass any required configuration context on the initial request for a compact resource, and the configuration server MUST return a compact resource honoring that configuration context. [CONFIG-RES-143]

Moreover, the icon reference, the large preview reference, the small preview reference, and any image or intra-page references directly embedded in the large and small HTML preview documents in that compact resource MUST correspond to the given configuration context, so the client need not pass a configuration context to render the icon or the HTML preview. [CONFIG-RES-144]

A reference corresponds to a given configuration if it is the URI of a non-versioned resource, the version URI for a versioned resource selected by the given configuration, or a concept resource URI with a configuration query string that resolves to the versioned resource selected by the given configuration.

15. Tracked Resource Sets

A configuration server SHOULD provide one or more Tracked Resource Sets for configurations, contributions, and components. A configuration server MAY publish selections and versioned resources in a Tracked Resource Set (TRS); URIs for versioned resources in the base and change log of the TRS MUST be version resource URIs. [CONFIG-RES-145]

16. Query Support

Configuration servers MAY support [OSLCQuery] for configurations and components. If OSLC Query is provided, queries for the following properties using oslc.where and oslc.select SHOULD be supported: [CONFIG-RES-146]

Query for other properties MAY be supported. [CONFIG-RES-147]

For example, this is a query for baselines of a given stream https://example.com/configs/stream123, with tag 'stellar', created after July 1st 2014:

Example 6
https://example.com/configs?oslc.where=oslc_config:baselineOfStream=<https://example.com/configs/stream123> and
     dc_terms:modified>="2014-07-01T00:00:00" and dcterms_subject="stellar"

Since some of those character must be encoded, the request would be issued as:

Example 7
https://example.com/configs?oslc.where=oslc_config%3AbaselineOfStream%3D%3Chttps%3A%2F%2Fexample.com%2Fconfigs%2Fstream123%3E%20and
     %20dc_terms%3Amodified%3E%3D%222014-07-01T00%3A00%3A00%22%20and%20dcterms_subject%3D%22stellar%22

Servers that support query capabilities on versioned resources MUST support the use of a configuration context to limit the query results to the versions selected by that configuration context, or to unversioned resources. The configuration context MUST support reference of a global configuration, or a configuration from this server. [CONFIG-RES-148]

17. Matching Contributions

Certain types of streams accept only certain other types of configurations as contributions. A global stream MUST accept any suitable configuration (baseline or stream) from an arbitrary configuration server [CONFIG-RES-149], while a stream from some non-global server might accept only configurations from the same server. For a non-global server, some configurations may be acceptable as contributions to global streams, while other non-global configurations are valid only as a contribution to a broader scoped stream from that same server.

The acceptability of a configuration as a child contribution to a parent stream is governed by the oslc_config:acceptedBy property on the child configuration and the oslc_config:accepts property on the parent stream. A configuration is a match, and thus acceptable as a contribution, if and only if:

  1. The parent has an oslc_config:accepts property whose value matches one of the types of the child configuration, AND
  2. The child has an oslc_config:acceptedBy property whose value matches one of the types of the parent configuration.

A configuration type matches another type if they are the same type, or if the parent type is oslc_config:Configuration and the child type is either oslc_config:Baseline or oslc_config:Stream. No other form of inference is required, but servers MAY use inference through properties such as owl:sameAs and rdfs:subClassOf to extend the definition of matching configuration types [CONFIG-RES-150].

A configuration is marked as a global configuration by adding an oslc_config:accepts property with the value oslc_config:Configuration. Any configuration that is suitable to be a contribution to a global configuration (including global configurations themselves) MUST have an oslc_config:acceptedBy property with the value oslc_config:Configuration [CONFIG-RES-151]. A stream is marked as not accepting any kind of contribution (that is, it may only appear as a leaf in the configuration tree) by not having any oslc_config:accepts property. A configuration is marked as ineligible as any form of contribution (that is, it may only appear as a root in the configuration tree) by not having any oslc_config:acceptedBy property.

A stream with an oslc_config:accepts property with the value oslc_config:Baseline accepts only baselines in changes to its set of contributions. A server MAY use this to indicate a stream being used to stage the progressive construction of a baseline [CONFIG-RES-152], where any initial stream contributions are gradually replaced by baselines as they become available.

Since baselines are immutable, their contributions (if any) are immutable, derived from the streams from which those baselines were created, so the oslc_config:accepts property is not meaningful and may be omitted.

Configuration servers MAY define their own types of configuration, and use those types in oslc_config:acceptedBy and oslc_config:accepts properties to define the allowed contributions. [CONFIG-RES-153]

Servers MAY treat the oslc_config:accepts and oslc_config:acceptedBy as server-generated read-only properties, not modifiable by a client. [CONFIG-RES-154]

Servers MAY perform validation of oslc_config:acceptscode> and oslc_config:acceptedBy. If a server performs such validation, it MAY limit validation to new contributions being added or defined for the first time. [CONFIG-RES-155]

18. Long Operations

Some operations (for example, creating a baseline from a large hierarchy of streams) can take a long time to complete.

Servers MAY use the standard HTTP response 202 Request Accepted to indicate that a request has been accepted, but may not yet be complete. [CONFIG-RES-156]

The content and location header of this 202 response MUST be that of an oslc_config:Activity resource, indicating the progress or result of that activity. Clients SHOULD poll the Activity resource periodically until the state indicates it has finished. [CONFIG-RES-157]

Each Activity resource MUST be persisted by a server (including over a restart) for a minimum of 24 hours after completion of the long operation as a whole, or until explicitly deleted by a client. [CONFIG-RES-158]

Clients SHOULD delete each Activity created by a long-running operation soon after the client has seen the completion of the activity, or when the client is no longer interested in the result. Servers MAY deny clients access to delete Activity resources including but not limited to activities still in progress, or activities not created by that client, or MAY require clients to have a specific role or permission to delete activities. [CONFIG-RES-159]

Activity Properties
Prefixed Name Occurs Read-only Value-type Representation Range Description
dcterms:created Zero-or-one true dateTime N/A Unspecified Timestamp of resource creation. Each resource SHOULD have one instance of the dcterms:created property [CONFIG-RES-160].
dcterms:creator Zero-or-many true AnyResource Either foaf:Agent, foaf:Person Creator or creators of the resource. The link target is usually a foaf:Person or foaf:Agent, but could be any type.
dcterms:modified Zero-or-one true dateTime N/A Unspecified Timestamp of the last change of status. If this property is missing, the time of creation can be taken to be the same as the last change of status.
dcterms:references Zero-or-one true AnyResource Either Unspecified A reference to a resource providing more details about the progress or result of the activity. For successful or partially successful operations, the dcterms:references property MUST be present, providing a link to the primary resource created or affected by the operation [CONFIG-RES-161]. For completely unsuccessful activities, this property may be missing. For activities still in progress, this MAY be a reference to a resource providing further information; which MAY be provided inline [CONFIG-RES-162].
dcterms:title Exactly-one true XMLLiteral N/A Unspecified A name for the activity, or current phase of the activity.
oslc_auto:progress Zero-or-one true integer N/A Unspecified The percentage (0-100) of completion, if known.
oslc_auto:state Exactly-one true Resource Reference Unspecified The state of the activity, as defined by OSLC Automation states.
oslc_auto:verdict Exactly-one true Resource Reference Unspecified The result of the activity, as defined by OSLC Automation verdicts.
oslc_config:progressMessage Zero-or-one true XMLLiteral N/A Unspecified Descriptive text about the progress of the activity, represented as rich text in XHTML content.
oslc:error Zero-or-many true AnyResource Either oslc:Error A warning or error issued by the activity. Instances of this property MAY appear at any time during the execution of the activity, or MAY be returned only after the activity is complete [CONFIG-RES-163].
rdf:type One-or-many true Resource Reference rdfs:Class A resource type URI. An Activity MUST have a resource type of oslc_config:Activity, and MAY have other types [CONFIG-RES-164].

19. Conformance

Implementations of this specification need to satisfy the following conformance clauses.

Clause Number Requirement
CONFIG-RES-1 A configuration server SHOULD implement [OSLCCore3] ServiceProvider and Service resources, where an oslc:domain property has the value http://open-services.net/ns/config#.
CONFIG-RES-2 A global configuration service resource, if provided, SHOULD include the property oslc:usage with the value http://open-services.net/ns/config#globalConfigurationService.
CONFIG-RES-3 A service with this usage property MUST provide all global configuration capabilities described as mandatory in this specification.
CONFIG-RES-4 Configuration Management servers MUST observe these constraints, but MAY provide additional classes, properties, and individuals.
CONFIG-RES-5 In particular, Configuration Management servers MAY define additional types of configuration, but all configurations MUST also be of one of the types defined here.
CONFIG-RES-6 A component itself MAY be a versioned resource
CONFIG-RES-7 Each resource SHOULD have one instance of the dcterms:created property
CONFIG-RES-8 Each resource SHOULD have one instance of the dcterms:modified property
CONFIG-RES-9 The oslc_config:configurations property on a component is read-only; servers MAY also treat the referenced container as read-only
CONFIG-RES-10 the container MAY have an oslc:resourceShape property referencing a resource shape that describes the container
CONFIG-RES-11 If a container resource shape is specified, the shape SHOULD have a property describing the membership of the container with a oslc:valueShape referencing a resource shape that describes the shapes of streams and baselines that may be created
CONFIG-RES-12 instance shapes SHOULD NOT be cached
CONFIG-RES-13 A Component MUST have a resource type of oslc_config:Component
CONFIG-RES-14 A component MAY be a Linked Data Platform Container, containing the concept resources associated with this component
CONFIG-RES-15 The members of such an oslc_config:Component container MUST NOT be of type oslc_config:Configuration
CONFIG-RES-16 Servers MAY treat the rdf:type property for a component as read-only.
CONFIG-RES-17 Properties of a baseline defined in this specification MUST be read-only unless stated otherwise
CONFIG-RES-18 Each resource SHOULD have one instance of the dcterms:created property
CONFIG-RES-19 The description of a baseline MAY be modifiable
CONFIG-RES-20 Each resource SHOULD have one instance of the dcterms:modified property
CONFIG-RES-21 Tags on baselines MUST be modifiable
CONFIG-RES-22 The title of a baseline SHOULD be modifiable
CONFIG-RES-23 A configuration with no value for oslc_config:acceptedBy MUST NOT be used as a contribution to any other configuration
CONFIG-RES-24 The target MUST be of type oslc_config:Contribution
CONFIG-RES-25 Contribution resources MUST be returned inline with the baseline resource
CONFIG-RES-26 In the set of Contribution resources for a single parent baseline, there MUST be only one Contribution resource for a given contributed baseline
CONFIG-RES-27 This property MAY be updated by the server to refer to earlier baselines when intermediate baselines are deleted
CONFIG-RES-28 servers MAY treat such multiple occurrences of selections as an error
CONFIG-RES-29 a previousBaseline property of the new stream MUST be set to refer to this baseline
CONFIG-RES-30 The container MAY have an oslc:resourceShape property referencing a resource shape that describes the container
CONFIG-RES-31 If a container resource shape is specified, it should have a property describing the membership of the container with a `oslc:valueShape` referencing a resource shape that describes the shapes of streams that may be created
CONFIG-RES-32 instance shapes SHOULD NOT be cached
CONFIG-RES-33 The prov:wasDerivedFrom property is undefined for baselines; it MAY be absent, or it MAY have the same value as oslc_config:baselineOfStream
CONFIG-RES-34 Servers SHOULD treat this property as read-only after initial creation
CONFIG-RES-35 A baseline MUST have at least the resource type oslc_config:Baseline
CONFIG-RES-36 Other types MAY be added, including types that are used in oslc_config:accepts and oslc_config:acceptedBy properties
CONFIG-RES-37 Servers MAY treat the rdf:type property of a baseline as read-only
CONFIG-RES-38 Each resource SHOULD have one instance of the dcterms:created property
CONFIG-RES-39 Each resource SHOULD have one instance of the dcterms:modified property
CONFIG-RES-40 A configuration with no value for oslc_config:acceptedBy MUST NOT be used as a contribution to any other configuration
CONFIG-RES-41 The container MAY have an oslc:resourceShape property referencing a resource shape that describes the container
CONFIG-RES-42 If a container resource shape is specified, it SHOULD have a property describing the membership of the container with a oslc:valueShape referencing a resource shape that describes the additional properties that may be specified for baselines
CONFIG-RES-43 servers MAY deny such requests if any added contributions do not match this configuration
CONFIG-RES-44 The target MUST be of type oslc_config:Contribution
CONFIG-RES-45 Contribution resources MUST be returned inline with the configuration resource
CONFIG-RES-46 there MUST be only one Contribution resource for a given contributed configuration
CONFIG-RES-47 servers MAY treat such multiple occurrences of selections as an error
CONFIG-RES-48 Servers MAY treat this property as read-only
CONFIG-RES-49 instance shapes SHOULD NOT be cached
CONFIG-RES-50 The prov:wasDerivedFrom property is undefined for baselines; it MAY be absent, or it MAY have the same value as oslc_config:baselineOfStream
CONFIG-RES-51 Servers SHOULD treat this property as read-only after initial creation
CONFIG-RES-52 A stream MUST have at least the resource type oslc_config:Stream
CONFIG-RES-53 Other types MAY be added, including types that are used in oslc_config:accepts and oslc_config:acceptedBy properties to define which matching configurations may be added as contributions to this configuration, or to which this configuration may be added as a contribution
CONFIG-RES-54 Servers MAY treat this property as read-only
CONFIG-RES-55 Servers MAY refuse to construct a baseline of a change set configuration
CONFIG-RES-56 servers MAY treat this as an error
CONFIG-RES-57 Each resource SHOULD have one instance of the dcterms:created property
CONFIG-RES-58 Each resource SHOULD have one instance of the dcterms:modified property
CONFIG-RES-59 A configuration with no value for oslc_config:acceptedBy MUST NOT be used as a contribution to any other configuration
CONFIG-RES-60 Servers MAY support contributions to change sets
CONFIG-RES-61 Servers MAY treat this property as read-only
CONFIG-RES-62 instance shapes SHOULD NOT be cached
CONFIG-RES-63 A change set configuration MUST have at least the resource type oslc_config:ChangeSet
CONFIG-RES-64 Servers MAY treat this property as read-only
CONFIG-RES-65 Each resource SHOULD have one instance of the dcterms:modified property
CONFIG-RES-66 On a PUT or POST of a Stream resource and its Contributions, this contributed configuration SHOULD be unique amongst the set of configurations contributed to a given parent configuration
CONFIG-RES-67 a server MAY collapse multiple contributions for the same configuration to a single contribution
CONFIG-RES-68 the oslc_config:contributionOrder string SHOULD be restricted to ASCII characters
CONFIG-RES-69 Servers MUST support at least 64 characters in this string
CONFIG-RES-70 If the selection type is not oslc_config:UnboundSelections, the target resource MUST be a version resource
CONFIG-RES-71 Selected resources MUST NOT be of type oslc_config:Configuration
CONFIG-RES-72 This property is read-only for selections of a baseline, but MAY be modifiable for selections of a stream
CONFIG-RES-73 A Selections resource MUST have at least the resource type oslc_config:Selections
CONFIG-RES-74 Selections resources MAY also have the type oslc_config:UnboundSelections
CONFIG-RES-75 Selected resources MUST NOT be of type oslc_config:Configuration
CONFIG-RES-76 This property MAY be modifiable for selections of a change set
CONFIG-RES-77 servers MAY treat occurrences of potentially conflicting selections as an error
CONFIG-RES-78 A change set Selections resource MUST have at least the resource type oslc_config:Selections
CONFIG-RES-79 Change set selections resources MAY also have the types oslc_config:ChangeSetSelections, oslc_config:UnboundSelections, oslc_config:Removals, or oslc_config:RemoveAll
CONFIG-RES-80 a client SHOULD provide a configuration context within which the concept resource is resolved to a specific version
CONFIG-RES-81

The Configuration-Context header is a URI that MUST conform to the following ABNF grammar [ABNF]: 

        SP = " "
        HTAB = %x09
        WSP = SP / HTAB

        header = config-context
        config-context = "Configuration-Context:" *WSP URI

Where the term URI is defined in [URI].

CONFIG-RES-82 A server MUST support both these methods of passing configuration context.
CONFIG-RES-83 If a request contains both a header and a query string, the server MUST use the query string. Servers MUST reject requests that contain two or more different configuration contexts passed in query strings.
CONFIG-RES-84 Where the Configuration-Context header is used on a request, a server SHOULD include in the response a header Vary=Configuration-Context so that different configuration contexts do not use a previously cached response.
CONFIG-RES-85 Configuration Management servers SHOULD use the Access-Control-Allow-Headers header [CORS] to allow the use of the Configuration-Context header in OSLC requests.
CONFIG-RES-86 A request SHOULD contain only a single occurrence of the Configuration-Context header, and MUST NOT contain multiple Configuration-Context headers referencing different values. A server SHOULD treat multiple identical Configuration-Context headers as it would a single header, and MUST treat multiple Configuration-Context headers with different configuration values as an error.
CONFIG-RES-87 If a configuration context is passed on a request for a non-versioned resource, the server MUST NOT treat that as an error, and MAY use that context to resolve references to embedded or related resources.
CONFIG-RES-88 If a configuration context is passed on a request using the version URI for a versioned resource, a server MUST ignore the configuration context, even if that configuration context does not select that versioned resource.
CONFIG-RES-89 If a configuration context is not provided or implied, the server MAY provide a default configuration, or the request MAY fail.
CONFIG-RES-90 A server MAY include an oslc_config:configurationSettings link in the OSLC Service resource, referencing an oslc_config:ConfigurationsSettings resource. That resource MAY contain at most one oslc_config:defaultConfiguration property whose value is the URI of the default configuration to be used by that service.
CONFIG-RES-91 An oslc_config:defaultConfiguration property with an rdf:nil value implies there is no default configuration, so requests with no context MUST fail.
CONFIG-RES-92 Servers MAY support a PUT on oslc_config:ConfigurationsSettings resource as a way to set the default configuration. Servers MAY provide other ways for users to set the default configuration.
CONFIG-RES-93 A configuration server MUST support the following operations on components:
CONFIG-RES-94 A configuration server SHOULD support, and a global configuration server MUST support, the following operations on Linked Data Platform Containers:
CONFIG-RES-95 POST to the component LDPC to create a new component. A successful response MUST contain a Location header providing the URI of the newly created component.
CONFIG-RES-96 POST to the configuration LDPC for a component to create a new stream for that component, optionally specifying an initial baseline; if an initial baseline is not specified, a real or notional empty baseline is implied as the starting point for the stream. A successful response MUST contain a Location header providing the URI of the newly created component.
CONFIG-RES-97 Servers SHOULD support the Prefer header for GET on LDPCs specifying PreferMinimalContainer:
CONFIG-RES-98 Servers MAY support OSLC selective properties on a GET, allowing a client to specify exactly which properties of those LDPCs are to be returned.
CONFIG-RES-99 A configuration server SHOULD support, and a global configuration server MUST support one or more component creation factories declared in one or more OSLC service providers.
CONFIG-RES-100 A configuration server SHOULD support one or more query capabilities for components.
CONFIG-RES-101 A configuration server MUST support the following operations on configurations:
CONFIG-RES-102 A configuration server SHOULD support, and a global configuration server MUST support, the following operations on configurations:
CONFIG-RES-103 servers MAY refuse to delete configurations that are part of or referenced by existing baselines
CONFIG-RES-104 A configuration server MAY support PATCH on a configuration to update the tags and/or the set of contributed configurations.
CONFIG-RES-105 servers MAY leave a stub resource (one with a minimal set of properties) behind instead of truly deleting a baseline
CONFIG-RES-106 Servers SHOULD add the property oslc:archived=TRUE on a reduced form of a partially deleted baseline
CONFIG-RES-107 A configuration server SHOULD support one or more query capabilities for configurations.
CONFIG-RES-108 A configuration server MUST support the following operations on selections resources:
CONFIG-RES-109 A configuration server MUST support the following operations on configuration items (versioned concept resources) in the context of a global configuration, or in the context of a configuration from this server:
CONFIG-RES-110 An attempt to GET a version resource URI in a configuration context where a different version of that concept resource MUST ignore the configuration context and return the specified version resource if it exists.
CONFIG-RES-111 this operation MAY cause the creation of a new version of the resource
CONFIG-RES-112 A configuration server MAY support the following operations on configuration items in the context of a global configuration, or in the context of a configuration from this server:
CONFIG-RES-113 POST to a component in the context of a stream or change set, resulting in the creation of the first version of a new concept resource, or a new version of an existing resource. A successful response MUST include a Location header specifying the URI of the newly created resource.
CONFIG-RES-114 When a new component is created by POSTing to the Component Container, an empty baseline for that component SHOULD be created automatically, and MUST be added to the oslc_config:configurations container for that component. The empty baseline has no contributions, no selections, and no branch.
CONFIG-RES-115 A new stream is created by POSTing to the oslc_config:streams container for a baseline. By default, the new stream inherits (MUST copy) the component, contributions, and selections of the baseline, but does not inherit (MUST NOT copy) the branch property. Other properties MAY be inherited (copied) from the baseline, or MAY be set to server defaults. The POSTed data MAY include any of the following properties; if these properties are supported by the server, then the POSTed values for these properties MUST completely replace any default or inherited values:
CONFIG-RES-116 The server MUST set the oslc_config:previousBaseline property of the new stream, and SHOULD set the prov:wasDerivedFrom property of the new stream, to reference the baseline owning the oslc_config:streams container.
CONFIG-RES-117 A server MAY support one or more configuration creation factories declared in one or more OSLC service providers that create a stream for the component specified in the configuration's POSTED RDF body.
CONFIG-RES-118 A new baseline of a stream is created by POSTing to the oslc_config:baselines container for that stream. If the server determines that a suitable baseline already exists, the server MAY return a 303 with a Location header referring to that existing baseline; for an existing baseline to be suitable it MUST be for the same component, MUST have the same oslc_config:branch value, if any, MUST select the same version resources, each contribution MUST be a suitable baseline for the corresponding stream contribution, and there must be no additional or missing contributions.
CONFIG-RES-119 Where a new baseline is created, that new baseline inherits (MUST copy) the following properties of the stream:
CONFIG-RES-120 Other properties MAY be inherited (copied) from the stream, or MAY be set to server defaults. The POSTed data MAY include any of the following properties; if these properties are supported by the server, then the POSTed values for these properties MUST completely replace any default or inherited values:
CONFIG-RES-121 When creating a new baseline from a stream, after copying all previous values of the previousBaseline to the new baseline, the server MUST replace all those previousBaseline properties on the stream by a single reference to the newly created baseline. The chain of previousBaseline links thus shows the history of baselines of a stream.
CONFIG-RES-122 The server MUST set the oslc_config:baselineOfStream property of the new baseline to reference the stream owning the oslc_config:baselines container.
CONFIG-RES-123 Since all contributions to a baseline must themselves be baselines, creation of a baseline requires that a server MUST first create or obtain baselines for the current state of all stream contributions, recursively downward through the contribution graph. See Long Operations.
CONFIG-RES-124 * A server MAY adjust the name properties of a configuration to maintain any name uniqueness constraints; a server SHOULD NOT fail creation of a baseline or stream just because the requested name is not unique.
CONFIG-RES-125 The server MAY ignore any additional properties, or MAY return an error if those properties are considered incompatible with the creation request.
CONFIG-RES-126 Any properties required on new streams or baselines not defined by this standard MUST be described in resource shapes referenced by oslc:resourceShape properties on the container.
CONFIG-RES-127 Servers SHOULD support the Prefer header for GET on those LDPCs specifying PreferMinimalContainer:
CONFIG-RES-128 Servers MAY support OSLC selective properties on a GET
CONFIG-RES-129 When adding a contribution, if the configuration being added has an oslc_config:overrides relationship, that relationship MUST be copied to the contribution.
CONFIG-RES-130 If the configuration being added has no OSLC overrides - it is a reusable configuration - a client MAY include an oslc_config:overrides relationship in a PUT to the contribution resource.
CONFIG-RES-131 Servers MAY require an overriding configuration to be for the same component as the overridden contribution.
CONFIG-RES-132 Servers MAY report an error if the configuration identified in the oslc_config:overrides property does not exist in the hierarchy for the context configuration.
CONFIG-RES-133 if there is no version of that resource in any of the selections in the contributions to the context configuration, nor in any of the selections in their recursive contributions, the request MUST fail with a 404 Resource not found (note that this includes unbound selections from a selection with type oslc_config:UnboundSelections)
CONFIG-RES-134 if there is exactly one version of that resource in the union of the selections in the recursive contributions, the request MUST return that one version
CONFIG-RES-135 the behavior is implementation-defined, but SHOULD be well-defined in that the successive requests in the same configurations with the same selections SHOULD resolve to the same version. A server MAY perform an ordered search using the oslc_config:contributionOrder property, and MAY have a way to indicate multiple possible version resolutions
CONFIG-RES-136 During this version resolution, overrides for entire configurations MUST be taken into account. If a contribution is marked as an override and the overriding configuration is earlier in the ordered set of all recursive contributions than the overridden configuration, the overridden configuration and all its contributions MUST be ignored in their entirety. Servers MAY report an error if an overriding configuration is later in the ordered set of all recursive contributions than the overridden configuration.
CONFIG-RES-137 Overrides from change set configurations MUST also be taken into account. If a change set removes a selection for a versioned resource in the overridden configuration, and no other selection is provided for that resource in some other configuration, then the request MUST fail with a 404 Resource not found. If a change set replaces a selection for a versioned resource in the overridden configuration, and no other selection is provided for that resource in some other configuration, the request MUST return the version in the change set selection.
CONFIG-RES-138 Implementations SHOULD provide documentation on their version resolution behavior.
CONFIG-RES-139 All configuration servers MUST provide a delegated user interface dialog for selection of configurations. A global configuration server MUST provide, and a local configuration server MAY provide, a delegated user interface dialog for creation of configurations.
CONFIG-RES-140 In order to provide a good user experience when selecting configurations to be used as contributions to a parent configuration, the UI Consumer SHOULD provide the URI of the parent configuration as a parameter to the Delegated UI Dialog, using the parameter oslc_config.parentConfiguration. UI Providers SHOULD use the types and oslc_config:accepts property values of that resource to filter the list of potential contributions shown in the selection dialog.
CONFIG-RES-141 Tools providing versioned resources using configuration management systems SHOULD provide delegated user interface dialogs for selection of versioned resources in the context of a configuration, and MAY provide delegated user interface dialogs for creation of versioned resources in the context of a configuration.
CONFIG-RES-142 Configuration servers SHOULD implement [OSLCCore3] UI Previews and compact rendering.
CONFIG-RES-143 Where implemented, clients MUST pass any required configuration context on the initial request for a compact resource, and the configuration server MUST return a compact resource honoring that configuration context.
CONFIG-RES-144 Moreover, the icon reference, the large preview reference, the small preview reference, and any image or intra-page references directly embedded in the large and small HTML preview documents in that compact resource MUST correspond to the given configuration context, so the client need not pass a configuration context to render the icon or the HTML preview.
CONFIG-RES-145 A configuration server SHOULD provide one or more Tracked Resource Sets for configurations, contributions, and components. A configuration server MAY publish selections and versioned resources in a Tracked Resource Set (TRS); URIs for versioned resources in the base and change log of the TRS MUST be version resource URIs.
CONFIG-RES-146 Configuration servers MAY support [OSLCQuery] for configurations and components. If OSLC Query is provided, queries for the following properties using oslc.where and oslc.select SHOULD be supported:
CONFIG-RES-147 Query for other properties MAY be supported.
CONFIG-RES-148 Servers that support query capabilities on versioned resources MUST support the use of a configuration context to limit the query results to the versions selected by that configuration context, or to unversioned resources. The configuration context MUST support reference of a global configuration, or a configuration from this server.
CONFIG-RES-149 A global stream MUST accept any suitable configuration (baseline or stream) from an arbitrary configuration server
CONFIG-RES-150 servers MAY use inference through properties such as owl:sameAs and rdfs:subClassOf to extend the definition of matching configuration types
CONFIG-RES-151 Any configuration that is suitable to be a contribution to a global configuration (including global configurations themselves) MUST have an oslc_config:acceptedBy property with the value oslc_config:Configuration
CONFIG-RES-152 A server MAY use this to indicate a stream being used to stage the progressive construction of a baseline
CONFIG-RES-153 Configuration servers MAY define their own types of configuration, and use those types in oslc_config:acceptedBy and oslc_config:accepts properties to define the allowed contributions.
CONFIG-RES-154 Servers MAY treat the oslc_config:accepts and oslc_config:acceptedBy as server-generated read-only properties, not modifiable by a client.
CONFIG-RES-155 Servers MAY perform validation of oslc_config:acceptscode> and oslc_config:acceptedBy. If a server performs such validation, it MAY limit validation to new contributions being added or defined for the first time.
CONFIG-RES-156 Servers MAY use the standard HTTP response 202 Request Accepted to indicate that a request has been accepted, but may not yet be complete.
CONFIG-RES-157 The content and location header of this 202 response MUST be that of an oslc_config:Activity resource, indicating the progress or result of that activity. Clients SHOULD poll the Activity resource periodically until the state indicates it has finished.
CONFIG-RES-158 Each Activity resource MUST be persisted by a server (including over a restart) for a minimum of 24 hours after completion of the long operation as a whole, or until explicitly deleted by a client.
CONFIG-RES-159 Clients SHOULD delete each Activity created by a long-running operation soon after the client has seen the completion of the activity, or when the client is no longer interested in the result. Servers MAY deny clients access to delete Activity resources including but not limited to activities still in progress, or activities not created by that client, or MAY require clients to have a specific role or permission to delete activities.
CONFIG-RES-160 Each resource SHOULD have one instance of the dcterms:created property
CONFIG-RES-161 the dcterms:references property MUST be present, providing a link to the primary resource created or affected by the operation
CONFIG-RES-162 For activities still in progress, this MAY be a reference to a resource providing further information; which MAY be provided inline
CONFIG-RES-163 Instances of this property MAY appear at any time during the execution of the activity, or MAY be returned only after the activity is complete
CONFIG-RES-164 An Activity MUST have a resource type of oslc_config:Activity, and MAY have other types