- From: Steve Speicher <sspeiche@gmail.com>
- Date: Thu, 27 Feb 2014 08:49:11 -0500
- To: Sandro Hawke <sandro@w3.org>
- Cc: Linked Data Platform WG <public-ldp-wg@w3.org>
- Message-ID: <CAOUJ7JqUcp2Rzjq1YAgm-Dm5270Lheuf13VPGSsMu+sGwFKcEA@mail.gmail.com>
Pulling up this specific part of your proposal, which we talking about at last telecon and we in general agreed that it would be worth considering: [[ So, PROPOSAL-2 is that empty-container triples MAY be available via a rel=describedby link header, and MUST be if the container is large enough to be paged. ]] The value here is that the server communicates a separate URL for non-membership and non-containment triples, which Sandro highlights some of positives below. On point of clarity, since we use rel=describedBy already in a couple places in the specification to indicate: [[ 5.2.11 LDP servers must publish any constraints on LDP clients' ability to create or update LDPRs, by adding a Link header with rel='describedby' [RFC5988] to all responses to requests which fail due to violation of those constraints. ]] and then [[ 6.4.13 ... If an LDPC server creates this associated LDP-RS it must indicate its location on the HTTP response using the HTTP Link response header with link relation describedBy and href to be the URI of the associated LDP-RS resource ]] I wonder if using rel=describedBy for empty-container is very compatible with the other definitions. Perhaps we could just mint our on rel= http://www.w3.org/ns/ldp#EmptyContainer and it would be very clear what that rel would be used for. Proposal: LDP servers MAY include a Link: rel= http://www.w3.org/ns/ldp#EmptyContainer response header to indicate the URL for a resource representation that includes no membership or containment triples. Though if folks are fine with describedBy, I could live with it. Steve Speicher On Sun, Feb 23, 2014 at 12:29 PM, Sandro Hawke <sandro@w3.org> wrote: > I tried to send this before my 'refactoring' message, but used the wrong > address. It is something I'd like to see in the spec before Last Call, > unless someone finds a problem with it. It's not a showstopper, though, > since it can be done later, with only the cost of adding to the legacy > support load. It involves revising decisions made at the > http://www.w3.org/2013/meeting/ldp/2014-01-27 meeting. The proposal we > adopted looked good at first, but I think this is better. > > = brief intro = > > Working on extensions to add to LDP, I keep coming up with cases where > there's a Link header to another resource that you might want to use > instead. > > For example, I was thinking about how to determine if one has write > access. A simple, general solution would be to have a parallel version of > a resource that acts like the real one except any changes made are lost, > like this: > Link: <sameResource?access-check=true> rel= > "http://www.w3.org/ns/ldp#noCommitVersion"<http://www.w3.org/ns/ldp#noCommitVersion> > > Or, how to provide an unchanging copy, if the server wants to: > Link: <me?asOf=2014022309340102> rel= > "http://www.w3.org/ns/ldp#snapshotVersion"<http://www.w3.org/ns/ldp#snapshotVersion> > > There's a pattern here, where the client does HEAD, finds the right Link > header, then does its GET on that. It's basically the RESTful way to add > a flag parameter. > > = proposal 1 = > > How about we generalize this as the client saying it would PREFER to save > a round trip. That is: > > Prefer: follow-link rel="http://www.w3.org/ns/ldp#snapshotVersion"<http://www.w3.org/ns/ldp#snapshotVersion> > > then, if the server chooses to do this, it will use the new 333/2xx return > code, saying it's acting like you'd fetched whatever that link pointed to. > > So a client who just wants the the first page, can say: > > Prefer: follow-link rel=first > > or the last page: > > Prefer: follow-link rel=last > > So, PROPOSAL-1 is to define Prefer: follow-link to save our clients some > round trips. It's nice, but doesn't really need to be in 1.0. But read > on: > > = proposal 2 = > > What if we consider the empty-container triples to be metadata, in > addition to data. That is, you can GET the container and see them mixed in > with everything else, or you can follow the rel=meta link and just see them. > > [ Um, wait. Is it rel=meta or rel=describedby? In 6.4.14 we say > "rel=meta" and refer to RFC-5988. But 5988 says nothing about rel=meta. > It has rel=describedby. Simple bug in our spec? ] > > The simple effect would be that instead of > > Prefer: return=representation; include= > "http://www.w3.org/ns/ldp#PreferEmptyContainer"<http://www.w3.org/ns/ldp#PreferEmptyContainer> > > we'd have the somewhat simpler: > > Prefer: follow-link rel=meta > > More generally, I think this would help in other ways. It makes updating > the empty-container triples easier, because you can just PUT or PATCH to > them, without worrying about the membership triples changing at the same > time. It might make change notification and access control easier, since > there's a clear way way to refer to the empty-contain triples separately. > It's a step toward allowing one set of clients access to to modify them but > not another, etc. > > So, PROPOSAL-2 is that empty-container triples MAY be available via a > rel=describedby link header, and MUST be if the container is large enough > to be paged. > > I see two downsides to this proposal: (1) it doesn't work without 333/2xx, > and (2) it doesn't address the membership-triples vs containment-triples > case. > > I suggest addressing (1) by putting this at risk, and forking it to > separate spec if necessary. The only normative connection is to paging, > which is already separated. > > On (2), I guess leave in the return=representation thing for containment > triples and membership triples, unless I can (in a separate thread) > convince folks that we should get rid of that division anyway. > > -- Sandro > >
Received on Thursday, 27 February 2014 13:49:40 UTC