Re: Section 4: LDPR/non-LDPR formal definitions

On 23 Mar 2013, at 01:08, Erik Wilde <dret@berkeley.edu> wrote:
> that means we're unable to support a case where somebody want to POST something that looks like an LDP resource, but isn't treated as one by the server (the LDP would be treated as opaque by that server).

That's a good point.

As I read the current spec, there is no way for the client to indicate, or for the server to communicate in advance, whether a Turtle representation POSTed to a "factory-enabled" container will create a full-blown LDPR or not.

I'm not sure how much of a problem that is. I could live with it, I guess.

A use case where this would be a problem would be something like where a client wants to use an LDP server to archive some Turtle files, and the client wants assurance that the server won't mess with the POSTed file by inserting server-managed metadata.

One solution might be to introduce yet another "flag" on containers that indicates whether the container is "passive" (just stores as a new resource whatever representation is POSTed, and makes the new URL a member) or "active" (only accepts Turtle or other RDF payloads, and results in creation of an LDPR).

Best,
Richard

> if, on the other hand, we want to be able to do that, then we need two POST URIs, one that only accepts LDP resources, and another one that supports any media type (including LDP). that latter resource would then turn whatever you POST to it into member content, allowing you to have an LDP resource that has an LDP representation as content. my guess is that this latter use case is not something we absolutely need, but i may be wrong.
> 
> cheers,
> 
> dret.
>

Received on Saturday, 23 March 2013 13:08:32 UTC