- From: Sandro Hawke <sandro@w3.org>
- Date: Fri, 28 Feb 2014 08:34:26 -0500
- To: "henry.story@bblfish.net" <henry.story@bblfish.net>
- CC: Linked Data Platform WG <public-ldp-wg@w3.org>
- Message-ID: <53109062.3040806@w3.org>
On 02/28/2014 05:47 AM, henry.story@bblfish.net wrote:
>
> On 23 Feb 2014, at 18:29, Sandro Hawke <sandro@w3.org
> <mailto: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.
>
This is intended more broadly to check things like access control and
integrity constraints. Is the client allowed to make this particular
change to these triples?
>
>> 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.
>
Sure. I was just making one up for the example. I don't remember
the details, but 'memento' is another possibility. It might have
baggage we don't need, though.
>>
>> 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?
>
It looks to me like the way to do this is with the Preference-Applied
header.
http://tools.ietf.org/html/draft-snell-http-prefer-18#page-7
Looking at this, we could use it instead of 209. If the client wants
the server to do 209s, it would include:
Prefer: follow-303-redirect
then get
Preference-Applied: follow-303-redirect
if the server did it. I'm not saying this is better than 209, but it's
an option to consider. In particular, the IETF bar is much lower for
new preferences than for new HTTP response codes.
(I looked at putting the "303" into a parameter, but that doesn't work,
since Preference-Applied isn't allowed to include parameters. I'd
suggest registering 301, 302, and 307 versions as well.
>>
>> = 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.
I think the pagination mechanism should be the same for all RDF
Sources. Containers should not be special-cased.
> 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.
The Working Group has not accepted your proposal that clients MUST
understand the membership triples before POSTing. I'm pretty sure many
of us would formally object to such a proposal.
>
>>
>> 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
>
Still thinking about that. Mostly I think we don't have time to work
out the details of the design, and we should just include
DirectContainer and BasicContainer for now, as they are now. Things like
IndirectContainer have all sorts of interesting issues we can figure out
later. I can live with including IndirectContainer in the LC spec,
because it does little harm just sitting there in the spec.
-- Sandro
> 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/
>
Received on Friday, 28 February 2014 13:34:38 UTC