Re: [oslc-core] 'Compacts' link and use of 'Prefer' request header

[Steve K Speicher <sspeiche@us.ibm.com>]

For completeness, I referenced a mysterious new HTTP status code, namely 
209 [1].  It is currently being proposed and its fate is unknown.  It has 
promise and a good amount of supporters.

[1] - http://www.w3.org/2014/02/2xx/draft-prudhommeaux-http-status-209.xml

Thanks,
Steve Speicher
IBM Rational Software
OSLC - Lifecycle integration inspired by the web -> 
http://open-services.net

<oslc-core@lists.oasis-open.org> wrote on 03/20/2014 07:51:47 AM:

> From: Steve K Speicher/Raleigh/IBM@IBMUS
> To: oslc-core@lists.oasis-open.org
> Date: 03/20/2014 07:52 AM
> Subject: Re: [oslc-core] 'Compacts' link and use of 'Prefer' request 
header
> Sent by: <oslc-core@lists.oasis-open.org>
> 
> > From: Martin P Pain <martinpain@uk.ibm.com>
> > To: oslc-core@lists.oasis-open.org
> > Date: 03/20/2014 06:52 AM
> > Subject: [oslc-core] 'Compacts' link and use of 'Prefer' request 
header
> > Sent by: <oslc-core@lists.oasis-open.org>
> > 
> > I won't be available for the beginning of today's Core meeting (due to 

> the 
> > clock change causing a conflict for me), but I have some comments to 
> contribute: 
> > 
> > 1. Version 18 of the draft for the 'Prefer' request header [1] states 
> > "implementors ... SHOULD NOT use the Prefer header mechanism for 
content 
> 
> > negotiation". It seems to me that we would be using this for content 
> > negotiation. (Not that I have a better suggestion, it still sounds 
> better to
> > me than using Content-Type). 
> > 
> 
> That is true if what we are doing is considered the same resource.  I 
> believe what we are saying is there are 2 resources, and always have, 
THE 
> resource and the related Compact resource.
> 
> > 2. Secondly, I've come across the idea in other RDF/semantic web 
> writings of
> > using one URI to identify a resource and a different URI to identify 
the 
> 
> > document (informational resource(?)) that describes it (if the main 
> resource
> > is not itself the information resource describing itself) . e.g. this 
is 
> 
> > mentioned in [2]. This is something I noticed did not seem to be 
> addressed 
> > or mentioned in OSLC 2.0, in particular with the compact 
representation. 
> 
> > If we add this 'compacts' link then I presume it would link from the 
URI 
> for
> > the informational resource for the compact document to the URI for the 

> > resource that has been "compacted"? 
> > 
> 
> See above statement, though perhaps it would be valuable to make sure a) 

> we all agree with this and b) be clear about it upfront in the spec.
> 
> > e.g. in response to this GET request: 
> > 
> >   GET /resource1 HTTP/1.1 
> >   Host: example.com 
> >   Accept: text/turtle 
> >   Prefer: compact 
> > 
> > There would be something like this response: 
> > 
> >   HTTP/1.1 200 OK 
> >   Content-Type: text/turtle 
> >   Vary: Prefer, Accept 
> >   Content-Location: /resource1.compact.ttl 
> > 
> >   @prefix oslc: <...>. 
> >   @prefix dcterms: <...>. 
> > 
> >   <http://example.org/resource1.compact.ttl> 
> >     oslc:compacts <http://example.org/resource1>; 
> >     . 
> > 
> >   <http://example.org/resource1> 
> >     dcterms:title "Resource 1"; 
> >     oslc:shortTitle "1"; 
> >     oslc:icon "http://example.org/resource.png";; 
> >   . 
> > 
> > 
> > Is my understanding of what is being suggested correct? (If not, what 
is 
> the
> > subject & object of the 'compacts' link ).
> > 
> 
> This not what I believe is what is being proposed, more along the lines 
> of:
> 
>   @prefix oslc: <...>. 
>   @prefix dcterms: <...>. 
> 
>   <http://example.org/resource1.compact.ttl> 
>     a oslc:Compact;
>     dcterms:title "Resource 1"; 
>     oslc:shortTitle "1"; 
>     oslc:icon "http://example.org/resource.png"; ;
>     oslc:compacts <http://example.org/resource1> .
> 
> This is doing an implicit "redirect" response though and can be thought 
of 
> as some form of conneg I guess.  If we had the proposed 209 response 
code, 
> we might suggest it be used here.  Though mandating, or evening 
> suggesting, a 303 would kill the proposal as it would introduce another 
> roundtrip.
> 
> Does it need to be more complicated than this?
> 
> Thanks,
> Steve Speicher
> IBM Rational Software
> 
> 
> > [1] http://tools.ietf.org/html/draft-snell-http-prefer-18#page-6 
> > [2] Section 2.3 "Making URIs defererenceable" in: Heath, T., Bizer, C. 

> (2011) 
> > Linked Data: Evolving the Web into a Global Data Space. Morgan & 
> Claypool. 
> > Retrieved from http://linkeddatabook.com/editions/1.0/#htoc11
> > 
> > Martin Pain
> > Software Developer - Green Hat
> > Rational Test Virtualization Server, Rational Test Control Panel
> > Open Services for Lifecycle Collaboration - Automation WG joint 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
> > 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
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that 
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>