Overview

The Open Services for Lifecycle Collaboration (OSLC) initiative is creating a family of web services specifications for products, services and other tools that support all phases of the software and product lifecycle. Each part of the lifecycle or domain has it’s own work group and specification, for example there are Change Management, Quality Management, Estimation & Measurement and more. Each of the domain specifications are built upon this core specification.

This OSLC Core Specification sets out the common features that every OSLC Service can be expected to support using terminology from the World Wide Web Consortium (W3C). New terminology that we introduce can be found in the glossary section below.

An OSLC Service is a resource that describes and links to other resources that enable a client to interact with the service. These resources are shown in the diagram below. An OSLC Service can have Resource Shapes that define the shape of resources managed by the service, Creation Resources for creating new resources in the service and a Query Resource that allows a client to navigate to any resource in the system.

OSLC Core Specification concepts and relationships

OSLC Resources are represented in a variety of formats. RDF/XML is required for all resources, but OSLC Services can also specify JSON, Turtle and Atom representations.

A word about RDF. The resource, property, value data model used for OSLC resources is based on Resource Description Framework (RDF) and OSLC requires RDF representations, but OSLC does not require implementors to provide an RDF triple-store or a SPARQL query-engine.

A word about Atom. Atom Publishing Protocol (APP) and Atom Syndication Format (ASF) formats are referenced in this document, but OSLC is not APP and OSLC implementations do not have to comply with APP.

Design considerations

The core philosophies of OSLC are to build on the powerful and scalable architecture of the World Wide Web and to do the simplest possible things that will work.

Build on the WWW. OSLC build on the architecture of the WWW and follows the REST architectural pattern. This means that OSLC services provide a uniform HTTP interface, OSLC URIs are stable and opaque and, in simple terms, OSLC works like the web.

Keep things simple. Doing the simplest things that will possibly work means a couple of different things in regard to OSLC. It means starting with simple and existing concepts. For example, we model everything as resources with property values. It means limiting the number of other specifications that we reference. Keeping things simple means building on established and well-known specifications, but also carefully limiting the number of other specifications that we reference. This simplicity is intended to make life easier for everybody: OSLC domain work groups, OSLC service implementers and OSLC client developers.

Accommodate different schemas. Because of the breadth of the OSLC domains, spanning lifecycle and platforms, OSLC has to work for systems with very different data schemas or no schemas at all. Flexibility is needed, but some OSLC Services must be able to offer resource shape information so that clients can learn what properties are allowed and required for resource creation, query and reporting.

Accommodate different representations. Different client platforms might require or at least prefer different representations. For example, in the browser a JSON or or Atom format representation might work best. OSLC Services will all support RDF/XML and may support other formats including JSON, Atom and Turtle.

Glossary of terms

This is a guide to some of the terminology used in this document. The following definitions are standard W3C concepts. OSLC uses these concepts without modification – their definitions are summarized here for the convenience of the reader. See http://www.w3c.org.

• Resource: A network data object or service that can be identified by a URI. Resources may be available in multiple representations (e.g. multiple languages, data formats, size, resolutions) or vary in other ways. (HTTP/1.1)

• Representation: An HTTP payload entity, included in an HTTP response, that is subject to content negotiation. There may exist multiple representations. associated with a particular HTTP response status. (HTTP/1.1)

• URI: Uniform Resource Identifiers are simply formatted strings which identify--via name, location, or any other characteristic -- a resource (HTTP/1.1)

Here are the OSLC specific terms used in this specification:

• OSLC Service: a set of resources that enable a web client to create, retrieve, update and delete resources managed by an Automated Lifecycle Management (ALM) product or online service offering.

• OSLC Resource: a resource that is managed by an OSLC Service, may have properties and may link to other resources including those provided by other OSLC Services.

• OSLC Properties: OSLC properties describe the expected characteristics of the property values of OSLC resources. OSLC resources are not guaranteed to conform to the descriptions in OSLC Properties – the latter are only descriptions, Examples of characteristics described in OSLC Properties include their value types, allowed values, cardinality and optionality.

• OSLC Specified Resource: a resource that is either defined by an OSLC specification, defined by an OSLC Resource Shape or both.

• OSLC Resource Shape: defines the set of OSLC Properties expected by a particular application or operation. Examples of such applications or operations include OSLC Creation Resource and Query Resource. Other examples might include applications that display data in tables.

• OSLC Creation Resource. a URI used to create new resources via HTTP POST. An OSLC Service may provide one or more Creation Resources,

• OSLC Query Resource: conceptually a query resource is a family of resources that all share the same base URI and each summarize a set of other resources that match a query criteria. A client performs a query by forming a query resource URI and getting the a representation of those resources.

OSLC Resources

An OSLC Resource is an resource managed by an OSLC Service. An OSLC Resource is typically something like a Change Request, a Requirement or some other Collaborative / Automated Life-Cycle Management (C/ALM) artifact or record. This resource could be stored in a relational database, a flat-file on disk or a source code control system.

Conceptual Model

To keep OSLC simple, we must keep the underlying data model simple. We start with the notion of resources and properties. Because we use this simple model we can define types of OSLC Resources in simple concise prose and can then use a set of simple rules to define how XML, JSON and other representations are generated.

Here are the terms that we will use:

• OSLC Defined Resource: a resource type that is defined in an OSLC specification and by a Resource Shape (see below section on Resource Shapes). An OSLC Defined Resource can exist in three forms:
  • As a first-class resource with a URI
  • As a construct within a resource
  • As a property value

• OSLC Property: defines a property of an OSLC Defined Resource. An OSLC Property has a name, value type, minimum occurs, maximum occurs, allowed values where required and other properties (see Resource Shapes below for properties).

This Core specification will define resources using the terminology above and will provide Resource Shapes (see Appendix A) for each OSLC Defined Resource that is specified.

URI Query Parameters

OSLC Resource URIs MAY include this property:

• oslc:properties - (optional) Add this query parameter to the URI of an OSLC Resource to obtain the URI for a resource with a subset of the resource’s properties. The value of this property must be a comma separated list of property names. This parameter may only be used once in a URI.

Resource Creation

OSLC Services SHOULD support HTTP POST for creation of resources. Refer to the Creation Resources section for information on how resource creation works for OSLC Resources and other content. The section on Resource Shape Resources explains how an OSLC Client can learn which OSLC Property values are allowed and/or required for OSLC Resource creation.

Resource Removal

OSLC Services SHOULD support HTTP DELETE for removing of resources. Resource Update

OSLC Services SHOULD support HTTP PUT for update of resources. To update an OSLC Resource in an OSLC Service, a client fetches a representation of that resource via HTTP GET. The client updates the representation and then uses HTTP PUT to send he new representation to the resource’s URI.

Resource Shape Resources

In some cases, to create resources and to query those that already exist within an OSLC Service, an OSLC client needs a way to learn which properties are commonly used in and/or required by the service. To meet this need, OSLC defines the notion of a Resource Shape Resource. OSLC Services MAY provide one or more Resource Shape Resources.

Conceptual Model

A Resource Shape is an OSLC Resource that defines one shape of OSLC Resource by listing the properties that are commonly used in and/or required in the shape. Here we specify an OSLC Resource and an OSLC Item: Resource Shape and Property.

Resource: Resource Shape

A Resource Shape Resource describes one type of resource and provides these properties:

• rdf:type (URI): a Resource Shape Resource MUST include one occurrence of this property with value http://open-services.net/xmlns/oslc/2.0#ResourceShape and MAY include other instances. TBD: reference standard
• dc:title (String): a Resource Shape Resource SHOULD include a title
• oslc:Property (Resource or URI): a Resource Shape SHOULD include one or more occurrences of oslc:Property.
• A Resource Shape Resource MAY include other property values

A Resource Shape SHOULD contain Property Resources.

Resource: Property

A Property describes one OSLC Property and provides these properties.

• oslc:predicate (String) - a Property MUST include a predicate value, e.g. “dc:title” dc:title (String): a Property SHOULD include a title
• oslc:datatype (URI) - a Property MUST define one datatype. May be String, Integer, Number, Boolean, URI or a Resource type.
• oslc:minOccurs (integer, optional, default 0) - minimum number of instances allowed
• oslc:maxOccurs (integer, optional, default is no limit) - maximum number of instances allowed
• oslc:allowedValue (String, optional, multiple allowed) - value allowed for property
• oslc:defaultValue (String, optional) - default value for property TBD: May be problematic. Really need this?
• oslc:maxSize (integer, optional, default is no limit) - maximum length of string property in characters
• oslc:readOnly (boolean, optional, default is false) - true if property is read-only.
• A Property MAY include other property values.

Common Properties

These are common properties that are available for use in any OSLC Resource. Those who are defining new OSLC Services are strongly encouraged to use the common properties here rather than creating new properties.

Dublin Core Properties

TBD: complete this list of common DC OSLC properties

RDF Properties

TBD: complete this list of common RDF OSLC properties

OSLC Properties

TBD: complete this list of common OSLC properties

Predicate

Query Resources

An OSLC Service’s Query Resource provides a way for clients to navigate to all resources managed by the system.

Conceptual Model

Conceptually a Query Resource is member of family of resources that all share the same base URI and each summarize a set of other resources that match a query criteria. To perform a query a client forms a query URI by adding query parameters to the Query Resource URI and then using HTTP GET to retrieve search results Query Resource.

Resource: Query

Each Query in the family represents a set of resources that meet query criteria encoded into its URI. A Query resource can have the following properties:

rdf:type (URI): a Query Resource MUST include one rdf:type property with value of http://open-services.net/xmlns/oslc/2.0#Query and MAY include other instances of the rdf:type property with other values.

dc:title (String): a Query Resource SHOULD include a meaningful and non-empty title.

A Query MAY include other property values

In addition to properties, a Query resource also includes query results, a sequence of resources each with a URI and a subset of its own properties.

Forming a Query Resource URI

To find resources an OSLC client forms a Query Resource URI and then uses HTTP GET to retrieve properties of resources that match the criteria specified in the HTTP Query Parameters of the URI.

To form a Query Resource URI, a client combines the base Query Resource URI and adds query parameters that indicate the query criteria and optionally the properties desired in the results. You can find examples of Query Resource URIs below.

Query Parameters

oslc:query - (required) Specifies the query criteria to be reflected in the resource

oslc:properties - (optional) Specifies the OSLC Properties to be included in the resource

oslc:searchTerms - (optional) Including this parameter indicates that each item in the resulting query results should include oslc:score property (with value 0-100) and items should be sorted in descending order of score.

Query Syntax

The following sections describe the syntax to be used when forming the oslc:query parameter of a Query Resource URI. The syntax is simple. A query is a list of terms separated by “and” operators and each term can be a simple boolean expression with normal mathematical comparison operators or a containment test (i.e. value must be in a specified list of values).

TBD: incorporate Query Syntax here

Service Resources

OSLC services are available via a single URI that will return a Service Resource which specifies the other URIs that a client needs to interact with the service.

Conceptual Model

A Service resource provides the following properties:

creationResource (URI, multi-value) - a Service MAY have one or more creation resources.

queryResource (URI, single value) - a Service MAY have one or more query resources.

resourceShapeResource (URI, multi-value) - a Service MAY have one or more Resource Shape Resources.

A Service Resource MAY provide other property values.