History   View   Links to this page Revision from: 2013 November 26 | 09:16 am
This is the revision from 2013 November 26 at 09:16 am   View the current live version of the article.
OSLC_logo.png

Open Services for Lifecycle Collaboration
Core Specifications Version 3.0

Status: Drafting

NOTE: Core 3.0 is targeted to be a collection of compatible specifications endorsed by the Core WG. Active development is occurring on these specification and may change without warning.

This Version

Latest Version

PreviousVersion

Authors

Contributors

Contents

Notation and Conventions

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC2119. Domain name examples use RFC2606.

Introduction

OSLC Core 3.0 is a collection of specifications that are intended to be independently adopted with minimal interdependencies. In support of these specifications, possible additional specifications and extensions of existing ones, as well as material not directly specification there are supporting documents such as guidance.

Specifications

Name Description Status Target SDO Notes
Resources Definitions and Operations Summary of the HTTP and RDF standard techniques and best practices that used, and anti-patterns avoided, when constructing clients and servers that read and write linked data. W3C LDP Draft W3C Lead: SteveSpeicher, John Arwe
Partial update A partial update (HTTP PATCH) model and representation for web resources. Working Draft W3C Lead: SteveSpeicher
Containers The resource that allow new resources to be created using HTTP POST and existing resources to be found using HTTP GET. W3C LDP Draft W3C Lead: SteveSpeicher, John Arwe
Paging A mechanism for splitting the information in large containers into pages whose representation can be requested incrementally. W3C LDP Draft W3C Lead: SteveSpeicher, John Arwe
Shapes and Validation A mechanism for describing the properties that a particular type of resource must or may have. Semantics defined using SPARQL ASK. Considering also how ‘flipped triples’ are handled. Investigating W3C Lead: Arthur From V2
Tracked Resource Set The Tracked Resource Set protocol allows a server to expose a set of resources in a way that allows clients to discover the exact set of resources in the set, to track all additions to and removals from the set, and to track state changes to all resources in the set. Finalizing draft W3C Lead: Steve Speicher, Vivek Garg
Consider submission for W3C rechartering 1H2014
Filtering URL-based query syntax and semantics defined in SPARQL SELECT, binding SPARQL endpoint to Containers. Not started Hold then OASIS Lead: Arthur, Anamitra From V2 No immediate need, will make the decision when need arrises. There has been some discussion from W3C LDP members on this need.
Representation Resource representation guidance on Turtle, JSON and RDF/XML. Investigating N/A (nothing to transition) Lead: SteveSpeicher, MichaelFiedler.
Use standard RDF formats, no work planned for 3.0
Authentication and Security Requirements and recommendation on authentication models such as OAuth (2.0, 1.0a) and SSO-kind of scenarios. Investigating N/A (nothing to transition) Lead: TBD Joe Ross? From V2 Just recommend existing standards such as OpenID Connect and OAuth 2.0
Error Responses Resource definition (vocabulary) that can be used as the basis for forming an error response. Not started OASIS, W3C Lead: SteveSpeicher, MichaelFiedler From V2
Delegated UI Dialogs Technique where one provider can embed a creation or selection UI from another server using a combination of an HTML <iframe> and JavaScript code. Drafting OASIS Lead: TBD Sam P, Ken P?.
Minimal changes planned From V2
UI Previews Technique to show a user in-context information when displaying a link to a resource, and to show more information when the user’s mouse lingers over the link. Drafting OASIS Lead: TBD Sam P, Ken P?.
(minimal changes planned, perhaps add json) From V2
Discovery how a client can learn about what a server can do and if it is the right kind of server Investigating OASIS Lead: SteveSpeicher, Anamitra? NickCrossley? From V2
Compatibility with Core V2 Considerations around V3 compatibility with V2 Ongoing OASIS Lead: John Arwe
Common vocabulary General purpose and commonly used properties that apply cross-domain and may not be found in other vocabularies Investigating OASIS Lead: SteveSpeicher
From V2
Discussion Resource Resource definition for a sequence of comments pertaining to the linked to resource. Not started OASIS Lead: SteveSpeicher, JimConallen.
Since we have a minimal definition from V2, has minimal implementations but no real issues…just republish with improvements From V2
Vocabulary Annotation Vocabulary Annotations to help with to improve the user experience, for example, when building SPARQL queries Drafted OASIS? Lead: ArthurRyman
LD Actions Ways to expose actions on resources, such as state transitions Drafting OASIS? Lead: JohnArwe, MartinPain

Supporting Documents

Guidance, best practices, etc.

Name Description Status Target SDO Notes
Terminology A glossary of terminology used throughout the specifications (for English normative specification text). Investigating OASIS Lead: SteveSpeicher.
Derived or directly referenced from W3C LDP
Links Rules and guidance around usage of links and statements on links. Working Draft OASIS Lead: Jim Conallen
Updates as needed from previous link guidance
Vocabulary guidance Evolution of RDF vocabularies and shapes Investigating OASIS Lead: SteveSpeicher
URI Naming Guidance Handling of vocabularies at http://open-services.net and namespace assignments Investigating OASIS Lead: SteveSpeicher

Appendix A: Notices and References

Contributors

  • SteveSpeicher (IBM, OSLC-Core Lead)
  • John Arwe (IBM, OSLC-Core)
  • Arthur Ryman (IBM, OSLC-Core)
  • Nick Crossley (IBM, OSLC-Core)
  • Ian Green (IBM, OSLC-Core)
  • Michael Fiedler (IBM, OSLC-Core)
  • Samuel Padgett (IBM, OSLC-Core)
  • Paul McMahan (IBM, OSLC-Core)

Reporting Issues on the Specification

The working group participants who author and maintain this working draft specification, monitor a distribution list where issues or questions can be raised, see Core Mailing List

Also the issues found with this specification and their resolution can be found at Core 2.0 Issues.

License and Intellectual Property

We make this specification available under the terms and conditions set forth in the site Terms of Use, IP Policy, and the Workgroup Participation Agreement for this Workgroup.

References

Category:Specifications

Categories