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

Erik,

On 22 Mar 2013, at 15:37, Erik Wilde <dret@berkeley.edu> wrote:
>> I think they will typically not be LDPRs (because LDPRs need a Turtle representation, and in general I don't expect LDP implementations to provide one for binaries). But right now I can't see a reason for *requiring* them to be non-LDPRs. So I'd say the two classes are potentially overlapping, but neither is a subclass of the other.
> 
> i am a little confused now. from the REST perspective, these things are whatever they return as their media type when you GET them, so their nature is determined/controlled by themselves. we just link them into a container by adding their identifier as a content link. i am a bit unclear how we could possibly claim that they are LDP resources (unless by pure coincidence they would actually be LDP resources, which of course is a possibility, but an edge case).

It may be not only by coincidence but by design. A common case that I expect is LDP resources that also have HTML representations. This is not an edge case.

> a resource's "nature" on the web is determined by its media type,

There is no such thing as "a resource's media type". Resources may have representations and these representations have a media type. A resource may have multiple representations, and clients may be able to interact with it through more than one media type.

Remember, the conversation is about whether we need to define a class of "non-LDPRs"; typing a resource that way would be an assertion that it does not conform to the criteria for an LDPR. I don't see a use case for this. Henry said "binary files are a use case". I disagreed with this; LDP can support "binary files" just fine. The class we need is simply "arbitrary HTTP-accessible resource", not "non-LDPR".

Best,
Richard


> and LDP does not even have control over these resources, since you can link to anything.
> 
> thanks and cheers,
> 
> dret.
>

Received on Friday, 22 March 2013 16:01:40 UTC