RDF vocabularies define the terms and resources for a domain of interest, life-cycle management in the case of OSLC Core. 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 Core 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 Core Version 3.0. Part 7: Vocabulary.
Terminology uses and extends the terminology and capabilities of OSLC Core Overview, W3C Linked Data Platform [[!LDP]], W3C's Architecture of the World Wide Web [[WEBARCH]], Hyper-text Transfer Protocol [[!HTTP11]].
No new terms are defined in this part.
Unlike the rest of the Core specification, these properties change and grow as new common properties are added. The properties that we list here are available for use in OSLC domain specifications when defining OSLC resources, but this does not mean that they are required to be in OSLC resources. OSLC domain specifications decide which properties are allowed and required for resources needed to realize their use cases. The OSLC common properties include properties defined in other standard vocabularies including:
Changes to the OSLC Core Vocabulary MUST be approved by the OASIS OSLC Open Project.
The OSLC Core Vocabulary is assigned the namespace URI of the http://open-services.net/ns/core#.
Domain TCs and other extensions MUST contribute their vocabulary terms in a namespace which is assigned to them as an authority.
OSLC Core, domain and other extensions SHOULD reuse existing vocabulary terms from stable vocabularies such as [[!DC-TERMS]], RDF [[!rdf11-concepts]], RDF Schema [[!rdf-schema]], [[!FOAF]], [[skos-reference]] and OSLC. New vocabulary terms SHOULD only be created when there is no clear existing choice available. See the [[!LDP]] similar clause on reuse.
It is common to collect a series of comments on a lifecycle resource, often referred to as a discussion. For example: tasks, bug reports, requirements, assets and so on, are often collected across various types of resources such as project. A project might reflect the planning of work to deliver a product that realizes the requirements as validated through test cases and bug reports. Discussions allow users to collaborate with each other for more efficient and effective delivery. This Discussion resource definition provides a minimal shape describing the needed properties.
Used in conjunction with Shape: Discussion to provide a minimal resource definition for a collection of comments.
When an OSLC Server incurs an error, it is RECOMMENDED that useful information be provided to clients in the body of the HTTP response.
OSLC Servers SHOULD use the Error resource defined below as the basis for forming error responses.
OSLC Servers SHOULD return an Error resource using the same representation format
requested by the client via the HTTP Accept request header. [[!HTTP11]]
OSLC Clients SHOULD treat the oslc:statusCode as a String that starts with digits, but MAY
contain non-digit text.
Used when servers need a consistent shape to communicate error messages.
Additional details about an error the server had when processing the request.
Resource representations returned via [[!OSLCCore2]] Resource Paging MUST include a resource of type oslc:ResponseInfo, as defined in this section. A response info resource representation describes information about a paged HTTP response body in which it appears.
The shape of an RDF resource is a description of the set of triples it is expected to contain and the integrity constraints those triples are required to satisfy. Applications of shapes include validating RDF data, documenting RDF APIs, and providing meta-data to tools, such as form and query builders, that handle RDF data. OSLC Core uses shapes to:
Constraints on OSLC Core and Domain resources SHOULD be described using ResourceShapes which is included as part of the OSLC Core multi-part specifications. Servers MAY use other constraint languages such as [[SHACL]] to define resource constraints.
The oslc:AttachmentDescriptor resource type is used to describe the binary resource (or non-RDF
Resource) associated with a particular resource. When a client POSTs an attachment content to a server, the
server stores the attachment content and assigns a URI just like any other type of resource creation but it
may also create an oslc:AttachmentDescriptor resource to contain data about the attachment.
There is no restriction on the content of each attachment resource. For example, it could be a photo of a
kitten, an installation manual, a log file, or a source code patch. Since the attachment cannot be expected to
contain additional client or server supplied data, a typical set of properties for each attachment is included
with the oslc:AttachmentDescriptor resource itself. Thus, the object of each
oslc:attachment statement is the binary attachment. Issuing an HTTP HEAD or GET operation on that
binary attachment resource URL should produce an HTTP response with a header value of
Link: rel='describedBy' to indicate the URL of the
oslc:AttachmentDescriptor resource. The properties for the
oslc:AttachmentDescriptor resource are indicated in the table below.
OSLC servers MUST follow the constraints defined here where required, and with the meanings defined here.
OSLC servers MAY provide additional constraints for specific purposes.