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
foaf defined in the
OSLC Core specification, OSLC Auto defines the namespace URI of
http://open-services.net/ns/auto# with a namespace prefix of
This specification defines the root superclasses, properties and values. Servers may define additional subclasses and provide additional properties as needed.
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.
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.
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
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.
|01||2018-05-22||Jad El-khoury||Initial Committee Specification Draft migrated from open-services.net|