W3C home > Mailing lists > Public > public-ldp-comments@w3.org > December 2013

Re: Comments on LDP TR http://www.w3.org/TR/2013/WD-ldp-20130730/ ( LC-2836)

From: Arnaud Le Hors <lehors@us.ibm.com>
Date: Thu, 12 Dec 2013 13:21:10 -0800
To: Tim Berners-Lee <timbl@w3.org>
Cc: public-ldp-comments@w3.org, Read-Write-Web <public-rww@w3.org>, Tabulator Developers <tabulator@lists.csail.mit.edu>
Message-ID: <OFB501AD09.D6584565-ON88257C3F.00739654-88257C3F.00754BB8@us.ibm.com>
Hi Tim,
Thank you for following up on this. I'll make sure that the WG considers 
your questions and provide a response.

Meanwhile, based on what you already know, I'd appreciate if you could 
tell me which of the following two options you prefer:

1) stick to the latest resolution: return the first page with a 200 on the 
initial GET, with the challenges you highlighted
2) revert back to having a 300 redirect to the first page and pursue 
defining 209 for LDPnext

I know neither of these options gives you what you want - 209 now - but 
given that we just can't afford defining 209 for this version of the spec, 
which of these would you consider your second best?

Thanks.
--
Arnaud  Le Hors - Software Standards Architect - IBM Software Group


Tim Berners-Lee <timbl@w3.org> wrote on 12/10/2013 06:34:18 PM:

> From: Tim Berners-Lee <timbl@w3.org>
> To: Arnaud Le Hors/Cupertino/IBM@IBMUS, 
> Cc: public-ldp-comments@w3.org, Read-Write-Web <public-rww@w3.org>, 
> Tabulator Developers <tabulator@lists.csail.mit.edu>
> Date: 12/10/2013 06:34 PM
> Subject: Re: Comments on LDP TR http://www.w3.org/TR/2013/WD-
> ldp-20130730/ ( LC-2836)
> 
> 
> On 2013-11 -15, at 20:19, lehors@us.ibm.com wrote:
> 
> > Dear Tim Berners-Lee ,
> > 
> > The Linked Data Platform (LDP) Working Group has reviewed the comments 
you
> > sent [1] on the Last Call Working Draft [2] of the Linked Data 
Platform 1.0
> > published on 30 Jul 2013. Thank you for having taken the time to 
review the
> > document and to send us comments!
> > 
> > The Working Group's response to your comment is included below.
> > 
> > Please review it carefully and let us know by email at
> > public-ldp-comments@w3.org if you agree with it or not before 29 
November
> > 2013. In case of disagreement, you are requested to provide a specific
> > solution for or a path to a consensus with the Working Group. If such 
a
> > consensus cannot be achieved, you will be given the opportunity to 
raise a
> > formal objection which will then be reviewed by the Director during 
the
> > transition of this document to the next stage in the W3C 
Recommendation
> > Track.
> > 
> > Thanks,
> > 
> > For the Linked Data Platform (LDP) Working Group,
> > Eric Prud'hommeaux
> > Yves Lafon
> > W3C Staff Contacts
> > 
> > 1. http://www.w3.org/mid/34BE20B3-86E3-434F-B454-B004E9A338F0@w3.org
> > 2. http://www.w3.org/TR/ldp/
> > 
> > 
> > =====
> > 
> > Your comment on :
> >> #########################
> >> 4.10.2.3   303 lis a basically very unsatisfactory design because of 
the
> >> round trip.  As this is a new spec, suggest defined 20X code meaning
> >> like a 303 but containing the representation of the thing 303d to. 
This
> >> has been found to a problem in LD. LDP can avoid it now.
> >> Benefit: First page back to user in one less round trip.
> >> #########################
> >> 
> >> 
> >> 4.10.2.4.3   This design puts the type and next links in the data.  I
> >> prefer I think using HTTP headers here as elsewhere.  Page control 
stuff
> >> is very meta, messy to have it in with actual data.
> >> Not a problem for containers, but for normal LDPRs IMHO.
> > 
> > 
> > Working Group Resolution (LC-2836):
> > Given the time constraints under which the WG is it is deemed 
unpractical
> > to depend on defining a new response code as suggested. However, based 
on
> > input from several HTTP experts the WG decided to return the first 
page
> > with 200 response code on initial GET which prevents the additional
> > roundtrip you objected to.
> > See http://www.w3.org/2013/meeting/ldp/2013-11-04#resolution_2
> > 
> 
> 
> Shame about 209, it was needed for other things as well, all the 
> data which currently uses 303.
> 
> Like any LD concept whose URI has no hash.
> (What is the WG's take on that -- are hashes being used everywhere?)
> 
> So the URI which the client sent in the GET is now overloaded
> as being used to identify both the collection and the first page of 
> a collection.
> 
> I am trying to understand how I should tweak my code to capture what
> has happened with the 200. 
> There is some large imaginary document which contains all the data 
> of which these are pages, and which has no URI itself, and we have 
> an abstract collection whose IRI is punned with the first page.
> 
> Supposing I am making a generic client which can make a SPARQL query
> over the some linked data, and I want it to work for this situation.
> What is its algorithm? 
> 
> I can make a function which, if looking at links from x and x is 
> punned with a a page which has a next link, then I fetch all next 
> links, aggregate all the date from them as a representation of the 
> collection document, and then query that.  Is that what I need?
> 
> I must be able to determine the state of the collection.
> 
> Maybe generically when not doing lazy  evaluation, I just follow all
> 'next' links wherever I find them, knowing that without doing that I
> just don't have all the data about them.  Then in my quad store, 
> what is the provence of the triples in the successive pages -- the 
> page or the union of them?
> 
> If I want to show that y is NOT in the collection x, then I have to 
> be sure I have looked up x.
> 
> It seems a shame to have no URI for the union, and to be overloading
> the URIs for the first page and the collection.
> 
> And questions like that.
> 
> Have members of the WG written code to do these things?
> 
> Tim
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> > Move Paging information out of the RDF content into HTTP headers.
> > See http://www.w3.org/2013/meeting/ldp/2013-09-30#resolution_2
> > 
> > 
> > ----
> > 
> > 
> > 
> 
Received on Thursday, 12 December 2013 21:21:43 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:44:38 UTC