STATUS: Working draft - elaborating on spec outline and needs.
The purpose of this document is to define an outline and plan for the contents of a Core 3.0 specifications. For overarching themes and plans see Core V3 Plan.
Motivators
The outline structure is being driven by a number of objectives. Primarily around defining a base for additional capabilities to build off of. In the same way that domain spec built off of core in V2, the core itself will be made of separately consumable parts. Also, it may be that some of the parts (capabilities) fit into a collection of specifications that are common or apply across multiple domains, but do not fit into a single specification called “Core”. This motivation is to allow for easy composition and decomposition of the needed specification components to build interoperable solutions. Some of these components or capabilities may evolve at different rates.
Document structure will continue to evolve to better meet needs of a consumable specifcation.
Summary of Core V2
- OSLC Defined Resources
- Handling unknown content
- Paging
- Selective properties
- Namespace prefixes
- Service Provider Resources
- Creation Factories
- Query Capabilities
- Delegated UI Dialogs
- UI Previews
- Auth
- Error Responses
- Common Properties/Resources
- Representation Guidance
- Guidance on Links and Relationships
Proposals for V3
Proposed content for V3:
- Resources - a summary of the HTTP and RDF standard techniques and best practices that you should use, and anti-patterns you should avoid, when constructing clients and servers that read and write linked data - Lead: SteveSpeicher
- Partial update - define a SPARQL Update subset as a HTTP PATCH format - Lead: SteveSpeicher
- Containers - defines resources that allow new resources to be created using HTTP POST and existing resources to be found using HTTP GET - Lead: SteveSpeicher
- Paging - defines a mechanism for splitting the information in large containers into pages that can be fetched incrementally
- Validation - defines a mechanism for describing the properties that a particular type of resource must or may have. Semantics defined using SPARQL ASK - Lead: Arthur?
- Query - a simple URL-based query syntax and semantics defined in SPARQL SELECT, binding SPARQL endpoint to Containers - Lead: Arthur?
- Links - updates as needed - Lead: TBD
- Representation - JSON guidance as needed, if not use JSON-LD/RDF. - Lead: SteveSpeicher, MichaelFiedler
- Auth - stronger requirements on OAuth (2.0, 1.0a) and guidance to help with SSO-kind of scenarios - Lead: TBD
- Error Responses - updates as needed - Lead: TBD
- Delegated UI DIalogs - support a few additional use cases - Lead: TBD
- UI Previews - leverage JSON format, updates as needed - Lead: TBD
- Discovery - how a client can learn about what a server can do and if it is the right kind of server - Lead: TBD
- Compatibility with Core V2 - Lead: TBD
Spec organization approach
Reorganization of specifications, both core and domain, to leverage a common profile of core and define common set capabilities with a published domain specific capability. The goals of this reorganization is to be able to be more declaritive/normative in the way we publish specs (possibly using RDF) and be more consistent from domain-to-domain.
Also a plan and process will be developed on how additional Core / common capability specifications can be incrementally added without the need to rev the entire Core set of specs.
Category:Supporting Documents
