OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

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


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


Inactive hide details for Samuel Padgett---04/11/2014 09:42:59 AM---Ian, On discovering the Compact resource, I'm not sure we'vSamuel Padgett---04/11/2014 09:42:59 AM---Ian, On discovering the Compact resource, I'm not sure we've made a decision. I


    From:

Samuel Padgett/Durham/IBM@IBMUS

    To:

Ian Green1 <ian.green@uk.ibm.com>

    Cc:

John Arwe/Poughkeepsie/IBM@IBMUS, Martin P Pain <martinpain@uk.ibm.com>, oslc-core@lists.oasis-open.org

    Date:

04/11/2014 09:42 AM

    Subject:

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

    Sent by:

<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



Inactive hide details for Ian Green1 ---04/08/2014 11:16:03 AM---Hi Martin I thought there had been agreement that "compact repIan Green1 ---04/08/2014 11:16:03 AM---Hi Martin I thought there had been agreement that "compact representation" would be
    From:

Ian Green1 <ian.green@uk.ibm.com>
    To:

Martin P Pain <martinpain@uk.ibm.com>
    Cc:

oslc-core@lists.oasis-open.org, John Arwe/Poughkeepsie/IBM@IBMUS
    Date:

04/08/2014 11:16 AM
    Subject:

Re: [oslc-core] JSON-LD of compact resources
    Sent by:

<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]