I've found the diagram in the overview section of this document to be helpful:
We may wish to include something similar in the OASIS docs - I don't recall seeing that anywhere in OASIS anyway.
The spec doesn't technical require that you expose any resources beyond Service Provider Catalog and Service Provider, though of course there's not much use
if indeed you have no other resources. Once you decide to expose other resources then you must comply with the other core specs such as preview, delegated dialogs, attachments and actions depending on whether those resources support those behaviors.
The core document
also has a nice dependence diagram in the introduction which shows that conformance to OASIS OSLC requires conformance to LDP.
Sort of a different angle to your original question, Jim, but I think it's worth discussing regardless.
R&D Fellow, PTC
From: email@example.com [mailto:firstname.lastname@example.org]
On Behalf Of Julie DeMeester
Sent: April-08-15 3:03 PM
To: Jim Amsden
Subject: Re: [oslc-core] OSLC Core in whole and in part
My understanding is that you must meet the core specification and that the other specifications build off of that. I mean, I might see a deviation from the core, but it would be something very
Raytheon Certified Architect
(978) 604-4234 mobile
Amsden ---04/08/2015 02:44:11 PM---During a discussion today, a question was raised about the meaning of the different OSLC Core speci
Jim Amsden <email@example.com>
04/08/2015 02:44 PM
[oslc-core] OSLC Core in whole and in part
During a discussion today, a question was raised about the meaning of the different OSLC Core specifications. It was not clear exactly what OSLC Core is. Is it:
1. All of the specifications - any compliant server would be expected to implement all of the capabilities (including those referenced from LDP).
2. Any of the specifications - a compliant server could advertise only one of the core capabilities, e.g., Resource Preview.
The OSLC Core Overview specification should clarify that compliance to OSLC core means with respect to the component specifications.
Perhaps we should include this as a discussion item for the next meeting?
Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data