Defines the overall approach to Open Services for Lifecycle Collaboration (OSLC) based specifications and capabilities that extend and compliment W3C Linked Data Platform [LDP]. OSLC Core 3.0 constitutes the approach outlined in this document and capabilities referenced in other documents.
This document was last revised or approved by the OASIS OSLC Lifecycle Integration Core (OSLC Core) TC on the above date. The level of approval is also listed above. Check the “Latest version” location noted above for possible later revisions of this document. Any other numbered Versions and other technical work produced by the Technical Committee (TC) are listed at https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=oslc-core#technical.
TC members should send comments on this specification to the TC’s email list. Others should send comments to the TC’s public comment list firstname.lastname@example.org, after subscribing to it by following the instructions at the “Send A Comment” button on the TC’s web page at https://www.oasis-open.org/committees/oslc-core/.
For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the TC’s web page (https://www.oasis-open.org/committees/oslc-core/ipr.php).
Note that any machine-readable content (aka Computer Language Definitions) declared Normative for this Work Product is provided in separate plain text files. In the event of a discrepancy between any such plain text file and display content in the Work Product's prose narrative document(s), the content in the separate plain text file prevails.
OSLC Core Version 3.0. Part 1: Overview. Edited by Jim Amsden. 04 April 2017. OASIS Committee Specification 01. http://docs.oasis-open.org/oslc-core/oslc-core/v3.0/cs01/part1-overview/oslc-core-v3.0-cs01-part1-overview.html. Latest version: http://docs.oasis-open.org/oslc-core/oslc-core/v3.0/oslc-core-v3.0-part1-overview.html.
Copyright © OASIS Open 2017. All Rights Reserved.
All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification.
OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS may include such claims on its website, but disclaims any obligation to do so.
OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.
The name "OASIS" is a trademark of OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please seefor above guidance.
This section is non-normative.
Information Technology (IT) enterprises are constantly addressing demands to do more with less. To meet this demand they need more efficient development processes and supporting tools. This has resulted in demand for better support of integrated system and software processes. Enterprises want solutions (such as software or hardware development tools) from different vendors, open source projects and their own proprietary components to work together. This level of integration, however, can become quite challenging and unmanageable. In order to enable integration between a heterogeneous set of tools and components from various sources, there is a need for a sufficient supporting architecture that is loosely coupled, minimal, and standardized. OSLC is based on World Wide Web and Linked Data principles, such as those defined in the W3C Linked Data Platform [LDP], to create a cohesive set of specifications that can enable products, services, and other distributed network resources to interoperate successfully [LDP].
OSLC is motivated by domain-driven scenarios that inspire standardization of common capabilities across disciplines such as change management, requirements management, and quality management, as well as by cross-domain scenarios such as Application Lifecycle Management (ALM) & DevOps, Product Lifecycle Management (PLM), and Integrated Service Management (ISM). The OSLC approach focuses on software lifecycle management to ensure it meets a core set of scenarios and requirements. Nonetheless, it can be used by tools belonging to any other domains and cross-domain scenarios such as Internet of Things, back office application integration, and customer relationship management.
The OSLC Core specifications provide additional capabilities that expand on the W3C LDP capabilities, as needed, to enable key integration scenarios. These capabilities define the essential and common technical elements of OSLC domain specifications and offers guidance on common concerns for creating, updating, retrieving, and linking to lifecycle resources based on W3C [LDP]. These specifications have emerged from the best practices and other work of other OSLC Member Section (MS)-affiliated Technical Committees (TCs), sometime referred to as OSLC domain TCs. OSLC domain TCs focus on a certain domain or topic. The OSLC Core TC develops technical specifications, creates best practices documents and formulates design principles that can be leveraged by other OSLC MS-affiliated TCs to enable them to focus on domain-specific concerns.
As seen in Fig. 2 OSLC Core 3.0 Overview, there are a number of capabilities developed in different standards organizations, TCs and working groups. The arrows represent either dependencies or extensions to some specifications or capabilities. OSLC MS-affiliated TC developed specifications may depend on OSLC Core 3.0 specifications as scenarios motivate. However, a leading goal is to minimize and eliminate unnecessary dependencies to simplify adoption, which may result in no dependency on OSLC Core 3.0 specifications for some OSLC domains.
This work is an evolution from the OSLC Core 2.0 [OSLCCore2] efforts, taking the experience gained from that effort along with the common foundation on W3C LDP, to produce an updated set of specifications that are simpler, built on layered capabilities and easier to adopt.
Terminology uses and extends the terminology and capabilities of W3C Linked Data Platform [LDP], W3C's Architecture of the World Wide Web [WEBARCH] and Hyper-text Transfer Protocol [HTTP11].
Some industry terms that are often referred to (not exhaustive):
Previous revisions of OSLC-based specifications [OSLCCore2], used terminology that may no longer be relevant, accurate or needed any more. Some of those deprecated terms are:
OSLC Core defines the namespace URI of
http://open-services.net/ns/core# with a namespace prefix of
As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.
The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this specification are to be interpreted as described in [RFC2119].
This section is non-normative.
The primary goal of OSLC is to enable integration of federated, shared information across tools that support different, but related domains. OSLC was initially focused on development of Information Technology (IT) solutions involving processes, activities, work products and supporting tools for Application Lifecycle Management (ALM). However, OSLC capabilities could be applicable to other domains. The specific goals for OSLC Core 3.0 are to build on the existing OSLC Core 2.0 specifications to further facilitate the development and integration of domains and supporting tools that address additional integration needs. Specifically:
The following guiding principles were used to govern the evolution of OSLC and guide the development of the OSLC Core 3.0 specifications.Scenario-driven
Every capability should be linked back to key integration scenarios that motivate its need. These are important not only for knowing that the correct specification content is being developed but also to assist with implementers understanding the intended usage and in developing relevant test cases.Incremental
Specifications should be developed in an incremental fashion that not only validates the technical approaches but also delivers integration value sooner.Loose-coupling
Specifications should support a model where clients have little to no knowledge about server implementation-specific behaviors in order to support key integration scenarios. As a result, clients should be unaffected by any server application software or data model implementation changes. Similarly, client software should be able to be independently changed without changes to server software.Minimalistic
Specification authors should strive to find not only the simplest solution that would work for a given scenario but allows for easy adoption. Authors should avoid solutions that offer additional capabilities which may inhibit adoption of necessary capabilities.Capability Based
A capability is the ability to perform actions to achieve outcomes described by scenarios through the use of specific technologies. Capabilities should be incrementally defined as independent focused specifications and independently discoverable at runtime. Even though there may be some generally agreed upon best practices for capability publication and discovery, each capability should define how it is published and discovered. The Core OSLC capabilities are defined in this specification.Vocabularies
Various OSLC MS-affiliated TCs, or any specification development body that is authoring specifications for specific domains of knowledge, should minimally define vocabularies and the semantics behind the various terms. Some consideration should be given for global reuse when terms are used for cross domain queries and within other domain resource shape definitions. Domain specifications are the definition of an OSLC capability, and how those vocabulary terms are used in LDP interactions by both the clients and servers of that capability. The specification should include defining resource shapes that describe resources based on a set of vocabulary terms, which introduces any domain specific constraints on the vocabulary's usage.
OSLC domain vocabularies should follow the recommended best practices for managing RDF vocabularies described at [LDBestPractices].
This section is non-normative.
In support of the previously stated goals and motivation, it is desired to have a consistent and recommended architecture. The architecture needs to support scenarios requiring a protocol to access, create, update and delete resources. [LDP] is the foundation for this protocol. Resources need to relate, or link, to one another utilizing a consistent, standard and web-scale data model. Resource Description Framework (RDF) [rdf11-concepts] is the foundation for this. The ability to work with these data models over HTTP protocols, is based on [LDP].
Some scenarios require the need to integrate user interface
components: either within a desktop or mobile web-browser, mobile device
application, or rich desktop applications. For these scenarios the
technology is rapidly evolving and changing. Priority should be based
on existing standards such as HTML5, with use of
OSLC Core specification documents elaborate on the conformance requirements leveraging these various technologies and approaches.
As the primary goals have been outlined around lifecycle integration, some scenarios may require exploration of new (or different) approaches and technologies. As with all specification development efforts, the OSLC Core TC will advise, develop and approve such efforts through the established processes for cross-TC and organization coordination.
This section is non-normative.
The following sections and referenced documents define the capabilities for OSLC Core 3.0. These documents comprise the multi-part specification for OSLC Core 3.0. They represent common capabilities that servers MAY provide and that may be discovered and used by clients. Although OSLC Core could be useful on its own, it is intended to specify capabilities that are common across many domains. Servers will generally specify conformance with specific domain specifications, and those domain specifications will describe what parts of OSLC Core are required for conformance. This allows servers to implement the capabilities they need in a standard way without the burden of implementing capabilities that are not required. The purpose of the OSLC Core Discovery capability is to allow clients to determine what capabilities are provided by a server. Any provided capability must meet all the conformance criteria for that capability as defined in the OSLC Core 3.0 specifications.
This implies that any capability that is discoverable is essentially optional, and once discovered, the capability is provided as defined in the applicable OSLC specifications. Servers should support OSLC Discovery, but Discovery itself is also an optional capability as servers could provide other means of informing specific clients of supported OSLC capabilities that could be utilized directly. For example, a server might provide only preview dialogs on specific resources and nothing else.
Constraints on OSLC Core and Domain resources SHOULD be described using OSLC Resource Shape 3.0 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 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 metadata to tools that handle RDF data such as form and query builders.
OSLC Domain specifications SHOULD use the following URI pattern when publishing each individual resource shape:
http://open-services.net/ns/[vocab short name]/shapes/[version]/[shape-name]
For example, for Change Management 3.0, a shape describing the base Change Request resource type might have the shape URI:
http://open-services.net/ns/[vocab short name]/shapes/[SPEC-version]
For example, for Change Management 3.0, there should be a container at:
http://open-services.net/ns/cm/shapes/3.0 with members such as:
http://open-services.net/ns/cm/shapes/3.0/changerequest http://open-services.net/ns/cm/shapes/3.0/somenewshape http://open-services.net/ns/cm/shapes/2.0/unchangedshape
Authentication determines how a user of a client identifies themselves to a server to ensure the user has sufficient privileges to access resources from that server, and provides a mechanism for servers to control access to resources.
Resource Discovery defines a common approach for HTTP/LDP-based servers to be able to publish their RESTful API capabilities and how clients can discover and use them.
This section is non-normative.
OSLC resource representations come in many forms and are subject to standard HTTP and mechanisms for content negotiation.
OSLC domain specifications specify the representations needed for the specific scenarios that they are addressing, and should recognize that different representations are appropriate for different purposes. For example, browser oriented scenarios might be best addressed by JSON or Atom format representations.
OSLC domain specifications are also expected to follow common practices and conventions that are in concert with existing industry standards and which offer consistency across domains. All of the OSLC specifications are built upon the standard RDF data model, allowing OSLC to align with the Linked-Data Platform [LDP]. In addition, all OSLC specifications have adopted the convention to illustrate most examples using Turtle and/or JSON-LD representations and will typically require these representations to enable consistency across OSLC implementations.
Common Vocabulary Terms defines a number of commonly used RDF vocabulary terms and resources (shapes), that have broad applicability across various domains.
Resource Operations specify how clients create, read, update and delete resources managed by servers.
If-Matchheader on a PUT request:
If-Matchheader is missing OSLC Services SHOULD return HTTP Bad Request (400) status code to indicate that the header is required.
If-Matchheader is present OSLC Services MUST behave as described in the HTTP specification, returning an HTTP Precondition Failed (412) error to indicate that the header does not match.
If-Matchheader is present and it matches, but there is some other problem or conflict with the update then OSLC Services MAY return an HTTP Conflict (409) to indicate that problem.
Resource Preview specifies a technique to get a minimal HTML representation of a resource identified by a URL. Applications often use this representation to display a link with an appropriate icon, a label, or display a small or large preview when a user makes some gesture over a link.
Delegated Dialogs allow one application to embed a creation or selection UI into another using HTML
This section is non-normative.
OSLC servers will often manage large amounts of potentially complex link-data entities. Practical use of this information will require some query capability that minimally supports selection of matching elements, filtering of desired properties and ordering. Ideally OSLC Core would rely on existing standard query services such as [RDF-SPARQL-QUERY] that may be integrated with [LDP]. The Linked Data Query Language Community Group is currently working on a Query Language for [LDP]. However, the reality is that many OSLC servers are adapters built on existing data management capabilities that are not built on an RDF foundation and do not provide SPARQL endpoints for query. In order to address the need for standard query capability to enable integration, [OSLCCore2] introduced a Query Capability and a Query Syntax that were intended to be simple enough that they could be implemented on a wide range of existing server architectures. In practice this has proven to be more difficult than anticipated. But the need is still there. OSLC Core 3.0 is built on [LDP] and future OSLC domain servers may provide more consistent access to SPARQL endpoints. Eventually that may lead to the deprecation of OSLC Core 2.0 Query Capability. In the meantime, OSLC Core 2.0 Query Capability is still available for OSLC domain specifications that need it.
Resource Paging specifies a capability for servers to make the state of large resources available as a list of smaller subset resources (pages) whose representation is easier to produce by the server and consume by clients. Resource paging is particularly useful in handling results from the query capability or the contents of an LDP container.
Attachments describes a minimal way to manage attachments related to web resources using LDP-Containers and Non-RDF Source [LDP].
Error responses returned by servers in response to requests are defined in Common Vocabulary Terms, Errors.
This section is non-normative.
OSLC is intended to provide a foundation for (lifecycle) application interoperability. A significant number of OSLC domains, and client and server implementations already exist and are in common use. Interoperability issues between applications on incompatible OSLC versions could result in negative impact to end users. One of the goals of the OSLC initiative is to mitigate or eliminate the need for lock-step version upgrades, where clients or servers target one version of a specification and break when new versions are introduced -- requiring all services to be upgraded simultaneously.
OSLC Core and domain specifications will each be versioned independently, and may specify version numbers. Existing OSLC 2.0 clients and servers use the OSLC-Core-Version header described in OSLC Core 2.0 Specification Versioning to indicate what OSLC version they expect or support. But exposing version numbers in OSLC implementations could lead to interoperability issues. Ultimately each domain will decide its compatibility needs. OSLC Core 3.0 does not introduce any changes that would break existing OSLC 2.0 clients. Because of this, there is no need for OSLC Core 3.0 to require servers or clients to utilize an OSLC-Core-Version header with a value of 3.0.
If an OSLC 2.0 client accesses an OSLC 3.0 server, the 3.0 server will always respond to the client in a manner that is compatible with 2.0. The response may include additional headers and entity request or response body information defined by OSLC Core 3.0, but this information will be simply ignored by the 2.0 clients. There will be no missing or invalid information since OSLC Core 3.0 is designed to be compatible with OSLC Core 2.0.
For OSLC clients that access 2.0 servers:
OSLC Core 3.0 does not address compatibility with versions of OSLC prior to [OSLCCore2]. Servers wishing to support compatibility with versions prior to 2.0 should follow OSLC Core 2.0 Specification Versioning.
This section is non-normative.
The following individuals have participated in the creation of this specification and are gratefully acknowledged:
James Amsden, IBM (Chair)
Nick Crossley, IBM
Jad El-khoury, KTH Royal Institute of Technology
Ian Green, IBM
David Honey, IBM
Jean-Luc Johnson, Airbus Group SAS
Harish Krishnaswamy, Software AG, Inc.
Arnaud LeHors, IBM
Sam Padget, IBM
Martin Pain, IBM
Arthur Ryman, IBM
Martin Sarabura, PTC (Chair)
Steve Speicher, IBM
This section is non-normative.
|01||04 April 2017||Jim Amsden||CS was approved and published.|