OSLC Core properties used by all Configuration Management resources
Prefixed Name |
Occurs |
Read-only |
Value-type |
Representation |
Range |
Description |
OSLC Core: Common Properties |
|
|
|
|
|
|
rdf:type |
one-or-many |
unspecified |
Resource |
Reference |
n/a |
The resource type URIs. |
dcterms:contributor |
zero-or-many |
unspecified |
AnyResource |
Either |
any |
Contributor or contributors to resource (reference: Dublin Core). It is likely that the target resource will be an foaf:Person but that is not necessarily the case. |
dcterms:created |
zero-or-one |
True |
DateTime |
n/a |
n/a |
Timestamp of resource creation (reference: Dublin Core) |
dcterms:creator |
zero-or-many |
unspecified |
AnyResource |
Either |
any |
Creator or creators of resource (reference: Dublin Core). It is likely that the target resource will be an foaf:Person but that is not necessarily the case. |
dcterms:description |
zero-or-one |
unspecified |
XMLLiteral |
n/a |
n/a |
Descriptive text (reference: Dublin Core) about resource represented as rich text in XHTML content. SHOULD include only content that is valid and suitable inside an XHTML <div> element. |
dcterms:identifier |
exactly-one |
True |
String |
n/a |
n/a |
A unique identifier for a resource. Assigned by the service provider when a resource is created. Not necessarily intended for end-user display. |
dcterms:modified |
zero-or-one |
True |
DateTime |
n/a |
n/a |
Timestamp of latest resource modification (reference: Dublin Core) |
dcterms:subject |
zero-or-many |
unspecified |
String |
n/a |
n/a |
Tag or keyword for a resource. Each occurrence of a dc:subject property denotes an additional tag for the resource. |
dcterms:title |
exactly-one |
unspecified |
XMLLiteral |
n/a |
n/a |
Title (reference: Dublin Core) of the resource represented as rich text in XHTML content. |
Configuration
Additional properties to be discussed - may include:
- A way to identify different configurations of the same ‘thing’ - same resource set, same component, …
- Sub-configurations (configurations contained in this configuration)
- Dependencies (configurations on which this configuration depends)
- Baselines created from this configuration
- Baselines merged into this configuration
- dcterms:replaces to define predecessor
- Resource set (a Basic Profile Container defining the resources in this configuration)
Note that configurations do not have status, workflow, or lifecycle properties; instead, we expect other resources that define such status to link to configurations. These other resources might be Change Requests, or resources from some as-yet undefined OSLC Lifecycle or Process Domain. The entity commonly termed a baseline is likely to be a configuration with a status link of one or more recognizable values.
Note also that determining the set of resources in a configuration may be an expensive operation, so we do not want to make the configuration resource itself a Basic Profile Container. This allows a GET of the configuration resource itself to be a light-weight operation; clients needing the member list can perform a second GET on the linked BPC resource.
Concept resources and version resources
A GET on the URI of a concept resource will resolve that URI to an appropriate state of (version of) a concept resource for the appropriate configuration context (see later). The returned resource will contain RDF statements about both the version resource and the concept resource; most statements will use the concept resource as the subject, because it is the state of (properties of) the concept resource that are defined by a version resource.
We use the dcterms:isVersionOf
property to relate the version resource itself to its concept resource.
As an example, GET http://example.com/conceptResourceA in one configuration context might return:
:conceptResourceA-version23
dcterms:isVersionOf :conceptResourceA .
:conceptResourceA
a :someType ;
dcterms:title "Concept Resource A" ;
:color "blue" ;
dcterms:description "Concept resource A as it appears in the state with the URI :conceptResourceA-version23" .
while in a different configuration context it might return:
:conceptResourceA-version17
dcterms:isVersionOf :conceptResourceA .
:conceptResourceA
a :someType ;
dcterms:title "Concept Resource A" ;
:color "red" ;
dcterms:description "Concept resource A as it appears in the state with the URI :conceptResourceA-version17" .
TBD: while the Basic Profile indicates that every concept resource should define at least one rdf:type
, it is not clear if we always need to define a separate type for the version resource itself.
Configuration context
A client may request a specific configuration context in one of two ways.
- Adding an
X-OSLC-Configuration-Context
header, passing the URI of a configuration resource as the value:
GET /resources/conceptResourceA HTTP/1.1
X-OSLC-Configuration-Context: http://example.com/configurations/myConfiguration1
- Adding a query string
oslc_cfg.context
and the encoded configuration URI to the end of the request URI:
GET /resources/conceptResourceA?oslc_cfg.context=&3Chttp&3A//example.com/configurations/myConfiguration1&3E HTTP/1.1
Clients may also use version resource URIs, but are discouraged from persisting such URIs in links, since that reduces the flexibility permitted by configuration management.