This specification defines a vocabulary and resource shapes for the OSLC Automation domain.


This specification defines a vocabulary and resource shapes for the OSLC Automation resources.


Terminology is based on OSLC Core Overview [[!OSLCCore3]], W3C Linked Data Platform [[!LDP]], W3C's Architecture of the World Wide Web [[WEBARCH]], Hyper-text Transfer Protocol [[!HTTP11]]. Terminology for this specification is defined in part 1 of the multi-part specification.


In addition to the namespace URIs and namespace prefixes oslc, rdf, dcterms and foaf defined in the OSLC Core specification, OSLC Auto defines the namespace URI of with a namespace prefix of oslc_auto

Automation Vocabulary Terms

This specification defines the root superclasses, properties and values. Servers may define additional subclasses and provide additional properties as needed.

Automation Resource Definitions

The Automation resource properties are not limited to the ones defined in this specification; service providers may provide additional properties. It is recommended that any additional properties exist in their own unique namespace and not use the namespaces defined in this specification.

A list of properties is defined for each type of resource. Most of these properties are identified in [[!OSLCCore2AppendixA]] Any exceptions are noted. Relationship properties refer to other resources. These resources may be in any OSLC domain (including Automation).

The diagram below shows the relationships between Automation Resources.

Diagram of OSLC Automation relationships

For all resource types defined in this specification, all required properties (those defined with an occurrence of exactly-one or one-or-many) MUST exist for each resource and must be provided when requested. All other properties are optional, and might not exist on some or any resources; those that do not exist will not be present in the returned representation even if requested, while those that do exist MUST be provided if requested. Providers MAY define additional provider-specific properties; providers SHOULD use their own namespaces for such properties, or use standard Dublin Core or RDF namespaces and properties where appropriate.

If no specific set of properties is requested, all properties are returned - both those defined in this specification as well as any provider-specific ones. See [[!OSLCCore2]] Selective Property Values in OSLC Core Specification.

Consumers of OSLC Automation services should note that some resources may have a very large number of related resources, and that some resources may be very large and/or expensive to compute. For this reason, consumers are strongly encouraged to use the parameter to limit the properties returned from a request to the subset required. See [[!OSLCCore2]] Selective Property Values in OSLC Core Specification.

Resource: AutomationPlan

Resource: AutomationRequest

Resource: AutomationResult

Resource: ParameterInstance

Resource: Dialog

Relationship labels

When an RM relationship property is to be presented in a user interface, it may be helpful to provide an informative and useful textual label for that relationship instance. (This in addition to the relationship property URI and the object resource URI, which are also candidates for presentation to a user.) To this end, OSLC Servers MAY suppport a dcterms:title link property in RM resource representations where a relationship property is permitted, using the anchor approach outlined in the OSLC Core Links Guidance.

Servers and Clients should be aware that the dcterms:title of a link is unrelated to the dcterms:title of the object resource. Indeed, links may carry other properties with names in common to the object of the link, but there is no specified relationship between these property values.

Change History

Revision Date Editor Changes Made
01 2018-05-22 Jad El-khoury Initial Committee Specification Draft migrated from