Re: [oslc-core] JSON-LD of compact resources - Compact reosurce discovery

[Martin P Pain <martinpain@uk.ibm.com>]

Options #2 and #3 could be combined.
If we introduced (or worked with the authors of http://tools.ietf.org/html/draft-snell-http-prefer-18
to define) something in the Prefer header to mean "give me the contents
of the resource linked by rel X", e.g:

Prefer: rel="http://open-services.net/ns/oslc#Compact"
or
Prefer: return=link; rel="http://open-services.net/ns/oslc#Compact"
or
Prefer: return=representation; rel="http://open-services.net/ns/oslc#Compact"
or something like that

then we could say that providers MUST
provide the Link header, and MAY allow this Prefer header to avoid the
round-trip, if the consumer so requests. The consumers then MUST be able
to follow the Link header, but MAY add the Prefer header to try to avoid
the round-trip (but MUST be able to detect whether or not that preference
was applied, and fall back to the Link header if needed).

The Link header, tome, seems like it
is more technically correct (although perhaps requires an invese of the
"compacts" relation/predicate, which is a red flag). This approach
allows us to the the Link header so we have a well-defined relation from
the resource to its compact - but while also having a means to avoid the
additional round trip (if the provider decides to impeement it - which
is the major downside of allowing these two together).

I don't expect allowing these two together
would add much spec complexity, as we would just define the Link header
approach, and then link off to http://tools.ietf.org/html/draft-snell-http-prefer-18
(probably in a non-normative section) saying that it is possible to use
the Prefer header to avoid the additional round-trip.



Martin Pain
Software Developer - Green Hat
Rational Test Virtualization Server, Rational Test Control Panel
OASIS Open Services for Lifecycle Collaboration - Automation technical
committee chair

E-mail: martinpain@uk.ibm.com Find me on:  and within IBM on:

IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU

<oslc-core@lists.oasis-open.org> wrote on 21/04/2014
15:26:42:

> From: Samuel Padgett <spadgett@us.ibm.com>
> To: Ian Green1/UK/IBM@IBMGB, John Arwe <johnarwe@us.ibm.com>,
Martin
> P Pain/UK/IBM@IBMGB, oslc-core@lists.oasis-open.org, 
> Date: 21/04/2014 15:26
> Subject: Re: [oslc-core] JSON-LD of compact resources
> Sent by: <oslc-core@lists.oasis-open.org>
> 
> I haven't seen any feedback on the three proposals. I was planning
> on updating the Resource Preview draft to use the HTTP Prefer header
> (option 3) for the reasons outlined on the wiki. Let me know if 
> anyone disagrees.
> -- 
> Samuel Padgett | IBM Rational | spadgett@us.ibm.com
> Eclipse Lyo: Enabling tool integration with OSLC
> 
> 
> __________________
> 
> I've added examples of all 3 options to a wiki. Input welcome.
> 
> https://wiki.oasis-open.org/oslc-core/CompactResourceDiscovery
> 
> -- 
> Samuel Padgett | IBM Rational | spadgett@us.ibm.com
> Eclipse Lyo: Enabling tool integration with OSLC
> 
> 
> [image removed] Samuel Padgett---04/11/2014 09:42:59 AM---Ian, On
> discovering the Compact resource, I'm not sure we've made a decision.
I

> 
> [image removed] 
> From:
> 
> [image removed] 
> Samuel Padgett/Durham/IBM@IBMUS
> 
> [image removed] 
> To:
> 
> [image removed] 
> Ian Green1 <ian.green@uk.ibm.com>
> 
> [image removed] 
> Cc:
> 
> [image removed] 
> John Arwe/Poughkeepsie/IBM@IBMUS, Martin P Pain 
> <martinpain@uk.ibm.com>, oslc-core@lists.oasis-open.org
> 
> [image removed] 
> Date:
> 
> [image removed] 
> 04/11/2014 09:42 AM
> 
> [image removed] 
> Subject:
> 
> [image removed] 
> Re: [oslc-core] JSON-LD of compact resources
> 
> [image removed] 
> Sent by:
> 
> [image removed] 
> <oslc-core@lists.oasis-open.org>
> 
> 
> 
> 
> Ian,
> 
> On discovering the Compact resource, I'm not sure we've made a 
> decision. I plan to create a wiki page showing the three proposals.
> Briefly, here they are:
> 
> 1) Custom media type a la OSLC 2.0 - application/oslc-compact+json
> 2) Link response header - Link: <http://example.com/bugs/4?compact>;
> rel="compact"
> 3) Prefer request header - Prefer: type=oslc-compact
> 
> How you discover the Compact resource might play into what media 
> types we support.
> 
> I think we all agreed the Compact resource really is a different resource.
> 
> -- 
> Samuel Padgett | IBM Rational | spadgett@us.ibm.com
> Eclipse Lyo: Enabling tool integration with OSLC
> 
> 
> [image removed] Ian Green1 ---04/08/2014 11:16:03 AM---Hi Martin I
> thought there had been agreement that "compact representation"
would be
> 
> [image removed] 
> From:
> 
> [image removed] 
> Ian Green1 <ian.green@uk.ibm.com>
> 
> [image removed] 
> To:
> 
> [image removed] 
> Martin P Pain <martinpain@uk.ibm.com>
> 
> [image removed] 
> Cc:
> 
> [image removed] 
> oslc-core@lists.oasis-open.org, John Arwe/Poughkeepsie/IBM@IBMUS
> 
> [image removed] 
> Date:
> 
> [image removed] 
> 04/08/2014 11:16 AM
> 
> [image removed] 
> Subject:
> 
> [image removed] 
> Re: [oslc-core] JSON-LD of compact resources
> 
> [image removed] 
> Sent by:
> 
> [image removed] 
> <oslc-core@lists.oasis-open.org>
> 
> 
> 
> 
> Hi Martin 
> I thought there had been agreement that "compact representation"
> would be a misnomer in v3.  Rather, there would be a resource
C, 
> (typically) distinct from R, whose representation(s) could be used
> to build a UI preview of R.  The minutes [1] echo this - are
the 
> minutes incorrect? 
> 
> I see the current draft at [2] uses content negotiation to request
> the "compact representation".  Is the current draft
ahead or behind 
> the meeting decisions (or were these not decisions at all?) 
> 
> [1] https://wiki.oasis-open.org/oslc-core/Meetings/Telecon2014.03.20
> [2] http://tools.oasis-open.org/version-control/browse/wsvn/oslc-
> core/specs/resource-preview.html 
> 
> 
> best wishes,
>  -ian
> 
> ian.green@uk.ibm.com (Ian Green1/UK/IBM@IBMGB)
> IBM Rational 
> 
> <oslc-core@lists.oasis-open.org> wrote on 07/04/2014 17:48:46:
> 
> > From: John Arwe <johnarwe@us.ibm.com> 
> > To: oslc-core@lists.oasis-open.org 
> > Date: 07/04/2014 17:48 
> > Subject: Re: [oslc-core] JSON-LD of compact resources 
> > Sent by: <oslc-core@lists.oasis-open.org> 
> > 
> > > 1. Somewhere the consumer gets the URL for the compact resource,
> > > probably through 
> > >     following a link from another resource. 
> > 
> > I'm not sure what a "compact resource" is.  In
the contributed 
> > specs, there is simply "a" resource and it either does/not
have a 
> > compact *representation*. 
> > There have been past discussions to the effect that the "compact
 
> > representation" language is incorrect, and it *should be*
a separate
> > resource ... is that your meaning?  I thought on the call
we agreed 
> > to stick with the base definitions, but maybe I missed something.
> > 
> > > 2. It knows, through a specification it was implemented
against 
> > > (i.e. a resource shape 
> > >     from that spec) that the target of that link
is "likely to be" a
> > > compact representation. 
> > 
> > The client only knows (sticking with contributed-specs language
in 
> > this reply) that the resource identified by the URL it holds
might/
> > not have a compact representation. 
> > Even without that critical distinction, in general I'd be careful
> > about implying anything around resource shapes; in our 
> > implementations it has been 1/n-1 (against resource shapes, i.e.
> > exactly 1 product exposes them out of a dozen-plus). 
> > >    4ai)IF the resource really is a compact representation
then it 
> > 
> > I think that's: If the server returned a compact representation
... 
> > 
> > Which raises a NEW question, if we have >1 compact representation:
> > how does the client know if it got back a compact representation?
 
> > In the contributed document, there is only one media type that
> > covers both "what it is" semantically and "what
syntax does it use".
> > On our espoused path that relation is no longer 1:1, and the
media 
> > type only conveys the syntax (I assert, given what those media
type 
> > registrations say).   
> > 
> > (and flipping this around) If we allow these json media types
*as a 
> > way for a client to ask for a compact representation*, how does
the 
> > server know to send a *compact* representation, vs a JSON or
JSON-LD
> > serialization of what a client would receive on a text/turtle
> > request to the same URL?  I.e. how does the server know
(given that 
> > the URL for the "compact representation" and the not-compact
one are
> > the same) which the client is really after? 
> > 
> > 
> 
> > Best Regards, John
> > 
> > Voice US 845-435-9470  BluePages 
> > Tivoli OSLC Lead - Show me the Scenario 
> 
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with
> number 741598. 
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
PO6 3AU
> 

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU