OSLC Automation Version 2.1 Part 3: Constraints

OSLC Automation Version 2.1 Part 3: Constraints defines constraints on the OSLC Automation RDF vocabulary terms and resources using OSLC ResourceShapes.

Introduction

RDF vocabularies define the terms and resources for a domain of interest, life-cycle management in the case of OSLC Automation. These vocabularies are often specified in an open manner, without providing information such as property domain and range assertions, cardinalities, etc. This helps keep the vocabulary applicable for a wide range of uses and furthering integration with other vocabularies.

However, it is often desirable to closed down a vocabulary with specific constraints to facilitate using the vocabulary for a specific purpose. This document specifies the constraints for using the OSLC Automation vocabulary in OSLC. Different sets of constraints may be applied to a vocabulary in order to tailor its use, without overly constraining the vocabulary for other usages.

These constraints apply to the core vocabulary defined in OSLC Automation Version 2.1. Part 2: Vocabulary.

Terminology

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.

References

In addition to the namespace URIs and namespace prefixes oslc, rdf, dcterms and foaf defined in the OSLC Core specification, OSLC AM defines the namespace URI of http://open-services.net/ns/am# with a namespace prefix of oslc_am

This specification also uses these namespace prefix definitions:

oslc_rm : http://open-services.net/ns/rm# [[OSLCRM]]
oslc_qm : http://open-services.net/ns/qm# [[OSLCQM]]

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 [[!OSLCCore3]] 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 oslc.properties 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.