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 - Compact reosurce discovery
- From: Steve K Speicher <sspeiche@us.ibm.com>
- To: Martin P Pain <martinpain@uk.ibm.com>
- Date: Tue, 22 Apr 2014 10:55:12 -0400
Martin,
> From: Martin P Pain <martinpain@uk.ibm.com>
> To: Samuel Padgett/Durham/IBM@IBMUS
> Cc: Ian Green1 <ian.green@uk.ibm.com>,
John Arwe/Poughkeepsie/IBM@IBMUS,
> oslc-core@lists.oasis-open.org
> Date: 04/22/2014 06:14 AM
> Subject: Re: [oslc-core] JSON-LD of compact resources
- Compact reosurce discovery
> Sent by: <oslc-core@lists.oasis-open.org>
>
> 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.
>
I think you are on the right path (we can support
both and doesn't add much complexity) but mixing client vs server requirements
here.
I agree in principle, we can do both Prefer and Link
approaches. Link provides a consistent separation of resources and
Prefer is an optimization to remove the extra round time. I don't understand
the "red flag", having a triple of C oslc:compacts R seems fine
while having a Link header that says Link: C rel='oslc-compact'. There
is no rule for how we "encode" triples in Link headers, we just
need to be clear on how we are using them.
I'd think client would want more guarantee than MUST
support round trips and MAY support optimization, since the tilt/need is
more towards optimization than Linked Data purity. So I'd say server
MUST support Prefer if you support Resource Preview and server SHOULD provide
Link header.
Thanks,
Steve Speicher
IBM Rational Software
OSLC - Lifecycle integration inspired by the web -> http://open-services.net
>
>
> 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: [image removed] and within IBM on: [image removed]
>
> [image removed]
>
>
>
>
> 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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]