Re: TWO PROPOSALs involving Prefer

On 23 Feb 2014, at 18:29, 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"

?? We have the Allow: header which specifies which methods can be used on a given resource at present. This needs to be
published on HEAD, GET and OPTIONS.


> Or, how to provide an unchanging copy, if the server wants to:
>    Link: <me?asOf=2014022309340102> rel="http://www.w3.org/ns/ldp#snapshotVersion"

I think there may already be some links for this in 
http://www.iana.org/assignments/link-relations/link-relations.xml

latest-version, prev-archive, next-archive, archive look worth investigating. It would be really useful to have a stable vocabulary for this.

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

That's interesting. One would need a way for the server to let the client know that it followed the link. Is that something in 209?

> 
> = 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"
> 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.

That is interesting, but I somewhat prefer the paging proposal where the initial page contains the essential data, and the pointers to the content pagination.
Why? Because I think the client that wants to POST to an ldp:DirectContainer or an ldp:IndirectContainer will want to do a conditional POST.  Otherwise how
does the client know that the server has not changed the membership properties between the time it read the content and the time the POST arrived? 
I wonder if this has been thought through enough? It seems to suggest that an ldp:(In)directContainer should not have its etag change unless those properties 
change.

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

I'd like to consider something a little bit less ad-hoc.  Perhaps something as I proposed 
Wednesday that would  allow one to easily unify membership triples and containership 
triples.

  http://lists.w3.org/Archives/Public/public-ldp-wg/2014Feb/0120.html

There I proposed that all our containers and all future containers could be subsumed by the 
relation ldp:bindingRule . We may want to extend this binding rule to specify where the triples 
end up. Now I would add to those bindingRule a triple to specify where the binding relations 
end up appearing. Let's call this ldp:bindingDocument .

Then a ldp:BasicContainer eg <http://finance.example/receipts/> could be written out like this:

<> a ldp:Container;
   ldp:bindingRule [ a ContainershipBindingRule;
                               ldp:bindingDocument <index> ] .


ContainershipBindingRules only require the bindingDocumentRelation to be filled out.
The advantage of this is that new ldp:contains relations can go to the contentListing 
document, so that a client can easily do a  GET on <http://finance.example/receipts/index> 
which would contain triples such as 

 <http://finance.example/receipts/> ldp:contains <c1>, <c2>, <c3>, <c4> ....

now a client can do a conditional POST to <http://finance.example/receipts/>,
with a high chance of success.

What is an ldp:BasicContainer then?

ldp:BasicContainer owl:equivalentClass [ owl:intersectionOf ( 
                  [ a owl:Restriction;
                    owl:onProperty ldp:bindingRule; 
                    owl:cardinality 1;                 
                 ],
                  [ a owl:Restriction;
                    owl:onProperty [ owl:propertyChainAxiom ( ldp:bindingRule rdf:type ) ];  //<- not sure about this
                    owl:hasValue ContainershipBindingRule;                 
                 ] 
            ) .


ie an ldp:BasicContainer has all the same elements as all the classes that are the intersection of classes that have only
1 ldp:bindingRule property, and the classes whose ldp:bindingRule is of type ContainershipBindingRule.

The ldp:IndirectContainer and ldp:DirectContainers have 2 bindingRules, and the types of the bindingRules are different.

Now I  am not sure how different this is to the paging proposal. The real issue is that for most containers a client would
like to be able to do conditional POSTs and  if the e-tag of the container changes on each new addition to the container, then
it could be quite difficult to get this to work.

Henry



> 
>       -- Sandro
> 

Social Web Architect
http://bblfish.net/