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

hello richard.

On 2013-03-22 9:01 , Richard Cyganiak wrote:
> On 22 Mar 2013, at 15:37, Erik Wilde <dret@berkeley.edu> wrote:
>> 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.

you're of course correct, pardon my sloppy terminology here.

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

pretty much any media type i know has assumptions around where a link 
takes you. it may take you to a resource that supports the same media 
type, or not. while technically speaking, no media type should make 
assumptions about that, many applications will. when you follow an HTML 
img/@src link, you expect an image/* response, or you don't really know 
what to do. same for a/@href, you expect an HTML page, or you don't 
really know what to do.

so what a media type might want to say is when links are "within" the 
media type (linkage between various resources exposed through that media 
type), and when they (potentially) "leave" the media type. this is 
helpful for clients to know, even though strictly speaking it would be 
best to never make any assumptions about this.

i do agree that it is not necessary to define "non-LDP" resources. what 
you find and what it means to you is determined by the link you follow, 
and the media type you get when you follow it. that's all clients need 
to know.

cheers,

dret.

Received on Saturday, 23 March 2013 01:20:42 UTC