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

hello richard.

On 2013-03-23 6:08 , Richard Cyganiak wrote:
> 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).
> 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.

my guess is that most people can live with that. i just think it's 
interesting to think about this when we design our interactions of the 
media type. it's a suspicious design smell if we wouldn't be able to do 
this out of fundamental reasons, but we very well might not take this 
feature into consideration for our design to simplify the LDP service.

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

i such a case i would expect the client to POST text/turtle, and ideally 
by POSTing this instead of POSTing text/ldp+turtle the client would make 
clear that the representation should be treated as generic turtle, 
without any need for the server to process it according to the LDP 
processing model.

because we very likely will not use media types, both POSTs will end up 
using the same media type (text/turtle), and then we have two options 
(that i can see):

- use profiles or something similar to indicate that one is to be 
treated as opaque turtle, the other one is actually LDP payload.

- use interaction affordances that support the "we will just store 
whatever you POST here" semantics i was talking about above, so that you 
can safely POST text/turtle that looks like an LDP resource, but 
shouldn't be treated as one.

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

that might be a solution, too, but it would hide these interaction 
affordances from the HTTP level, which imho is where they belong.

cheers,

dret.

Received on Monday, 25 March 2013 05:38:40 UTC