- 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