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

hello richard.

On 2013-03-22 8:30 , Richard Cyganiak wrote:
> An LDPR is an HTTP-accessible resource that has a Turtle representation (and meets some additional requirements, as defined in the LDP spec). The “binary or text resources” we're talking about here are HTTP-accessible resources that have non-RDF representations. Since an HTTP-accessible resource can have multiple representations (a.k.a. content negotiation), there is no reason to presume that these two classes of resources are disjoint. There might be resources that are both LDPRs and binaries/images/text resources. I don't think that we need to say anything about this in the spec. But I don't see a reason for forbidding such uses of HTTP by specifying a class of “non-LDPR” resources.

that may or may not be true. the reason why i am saying this is the 
following: if our interaction design is done a way that you POST LDP and 
non-LDP resources to the same URI, then the service will have to decide 
by media type whether what you POST is a container member, or content 
that should be linked to one. 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). 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 01:08:55 UTC