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

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

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