Re: Question about the On Linking Alternative Representations TAG Finding

Richard Cyganiak wrote:
> Xiaoshu,
>
> On 8 Aug 2008, at 10:11, Xiaoshu Wang wrote:
>> The problem is there is no objective criteria that tells a *resource* 
>> from *representation*.
>
> A resource is anything named by a URI.
>
> A representation is a <bitstream, MIME type> tuple.
It sounds simple but not really.  For instance, is 
"http://dfdf.inesc-id.pt/tr/doc/web-arch/img/fig2" a resource or a 
representation?  A *representation*, in my opinion, is what is delivered 
to the client, a *resource* is whatever the provider intends it to be.   
They are always different - not in the sense if they are *bitstream* or 
not.  A *representation* of a resource denoted by a URI doesn't have to 
be delivered electronically.  This is the often wrongly conceived idea 
that http-URI must be bound to HTTP protocol.  If I bind a URI to a 
postal service as its transportation protocol, you (in principle) can go 
to a postal office to request 
"http://dfdf.inesc-id.pt/tr/doc/web-arch/img/fig2" and a hardcopy print, 
which is NOT a bitstream, can be delivered to you.  Do you consider that 
picture a resource or a representation?
>
> That's a simple and objective distinction. The interesting and 
> subjective question is how to best model an application using those 
> two modelling primitives.
>
> There are two schools of thought on this. One school maintains a 
> distinction between “documents” and “things described in the 
> documents” in their modelling; the other school says that this 
> distinction is unnecessary.
>
> The former modelling has been elevated to an axiom of Web architecture 
> by the httpRange-14 decision. It has many advantages over the latter 
> (cleaner handling of metadata, enables grouping of many descriptions 
> in a single document, ...), and it has some disadvantages (more 
> complex, ...). These have been discussed endlessly and I have no 
> interest in resurrecting that debate.
>
>> There are only two choices.  (1) As T.V Raman said, don't make any 
>> distinction between them.
>
> The distinction is made in the specs; and it's made by a large and 
> significant part of the Web community (see REST). Raman might not 
> consider it important, and that worries me a bit, but it doesn't 
> diminish the importance of the distinction.
>
>> (2) As I have always proposed, to make an absolute distinction.  That 
>> is: to think every URI denotes a *resource*
>
> No one disagrees with this.
>
>> and what is dereferenced from the URI is the *representation* of that 
>> resource.
>
> Not quite. A representation is what you get back when you do a GET on 
> the resource, or what you send when you do a POST/PUT. 
I am not sure how many people will agree on the latter part.  I cannot. 
> Dereferencing is the process of “reaching through the network” in 
> order to perform one of the supported operations on a resource.
>
>> To think whether something is *in* a document or not is just a form 
>> of self-contradiction because the goal is to make the web 
>> *self-descriptive*.  Hence, a document (or resource) is both in and 
>> not in itself.
>
> What do you mean when you say “something is in a document”? I can 
> understand the phrase “something is described in a document”. 
> Obviously a document can describe itself. I don't see the contradiction. 
I intended it the same way you described that "something described 
inside a document".  I am trying to understand what you mean that "303 
redirects are about creating URIs for “things described inside 
documents”.  Do you mean if something talks about itself, it should 303 
redirect?  Or something else?
> [snip]
>>>    some_resource
>>>       |
>>>       +--303--> description_of_some_resource
>>>                    |
>>>                    +--Content-Location--> 
>>> description_of_some_resource.{html|rdf}
>>>
>>> That's the clean and proper way of combining the 303 approach with 
>>> content negotiation!
>> It is *clean* only when the distinction of *resource* vs. 
>> *representation/description* is unambiguous, which hardly is.
>
> Those who use the approach described here simply make a modelling 
> distinction between documents and the things described in the 
> documents. That distinction *is* unambiguous. (But it is subjective.) 
> The described approach is “clean” in the sense of HTTP interactions. 
> And it is “clean” in that it enables the modelling style described above.
But the web is about facilitating ad hoc communication.  If you have an 
unambiguous but subjective distinction and I have mine?  Is it going to 
be unambiguous or not when we intend to communicate with each other?
>> In either case, i.e., the (1) and (2) solution mentioned above, 303 
>> is unnecessary.  Sure, it does no harm.  But it does slow down the 
>> web and our goal should be to make the web more efficient but less.
>
> That's why I keep insisting that you should use hash URIs, which do 
> not exhibit this downside, instead of the 303 approach. The solutions 
> mentioned above are for those who have decided to use 303s anyway, 
> despite the well-known downsides.
First, there is reality issue - such as dublin core etc., already uses 
slash.  Second, there are clear use cases where #hash URI is not 
appropriate.  Consider the document size, if a domain vocabulary, such 
as that of SNOMD, will be using #URI.  Third, there is still the issue 
of the nature of resource because what a hash URI denotes when there are 
multiple representation/variants, isn't clearly defined. If a (generic) 
resource say http://example.com/gr has two representations, an RDF and 
an HTML one, that can be get via conneg.  Let's give each of them a URI 
http://example.com/gr.rdf and http://example.com/gr.html.  What will be 
http://example.com/gr#a denoting? And what is the relationship between 
http://example.com/gr.rdf#a and http://example.com/gr.html#a?  This is a 
muddled area, which I hope TAG can find time to give some recommendations.

Regards,

Xiaoshu

Received on Friday, 8 August 2008 12:21:35 UTC