History   View   Links to this page Revision from: 2012 October 16 | 07:41 am
This is the revision from 2012 October 16 at 07:41 am   View the current live version of the article.

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. This should be discussed with the Core workgroup.

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.