Re: TWO PROPOSALs involving Prefer

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
>
>