oslc-core message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [oslc-core] JSON-LD of compact resources
- From: Samuel Padgett <spadgett@us.ibm.com>
- To: Ian Green1 <ian.green@uk.ibm.com>, John Arwe <johnarwe@us.ibm.com>, Martin P Pain <martinpain@uk.ibm.com>, oslc-core@lists.oasis-open.org
- Date: Fri, 11 Apr 2014 12:40:58 -0400
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
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
|
Samuel Padgett/Durham/IBM@IBMUS |
|
Ian Green1 <ian.green@uk.ibm.com> |
|
John Arwe/Poughkeepsie/IBM@IBMUS, Martin P Pain <martinpain@uk.ibm.com>, oslc-core@lists.oasis-open.org |
|
04/11/2014 09:42 AM |
|
Re: [oslc-core] JSON-LD of compact resources |
|
<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
Ian Green1 ---04/08/2014 11:16:03 AM---Hi Martin I thought there had been agreement that "compact representation" would be
|
Ian Green1 <ian.green@uk.ibm.com> |
|
Martin P Pain <martinpain@uk.ibm.com> |
|
oslc-core@lists.oasis-open.org, John Arwe/Poughkeepsie/IBM@IBMUS |
|
04/08/2014 11:16 AM |
|
Re: [oslc-core] JSON-LD of compact resources |
|
<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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]