W3C home > Mailing lists > Public > www-tag@w3.org > April 2008

Re: Uniform access to descriptions

From: Stuart Williams <skw@hp.com>
Date: Sat, 12 Apr 2008 12:09:23 +0100
Message-ID: <48009863.1090304@hp.com>
To: "wangxiao@musc.edu" <wangxiao@musc.edu>
Cc: Pat Hayes <phayes@ihmc.us>, "noah_mendelsohn@us.ibm.com" <noah_mendelsohn@us.ibm.com>, Jonathan Rees <jar@creativecommons.org>, Phil Archer <parcher@icra.org>, "www-tag@w3.org WG" <www-tag@w3.org>

Xiaoshu Wang wrote:
> Pat Hayes wrote:
>> At 1:29 AM +0100 4/12/08, Xiaoshu Wang wrote:
>>> <snip>
>>>>> Question 4: Is an HTTP-URI =  HTTP+URI?
>>>> I have no idea what this means.
>>> What I mean is this:
>>> HTTP-URI is simply an HTTP URI.
>>> HTTP+URI is when the HTTP URI is bound to the HTTP transportation
>>> protocol.
>>> Hence, the question can be rephrased as such:
>>> Is what a URI denotes the same thing as what the URI is dereferenced?
>> Sometimes but also sometimes not. http-range-14 says that when the
>> response code is 200, the answer is yes. As I say, I don't like this
>> much either; but I can't see any feasible other way to answer the
>> question/ at all/ for a given URI.
>> I take it that your answer would also be: maybe, maybe not; but that
>> you would want the decision to depend not on an http code, but instead
>> on some RDF assertions which would be accessible from the URI (in a
>> way I confess to not following yet, but ...) Is that right?
> Yes.  That is my point.  But I am not stubborn and unwilling to accept
> any other model. It is because I don't see other models that can give me
> a clear and objective way to answer the four questions that I asked.
> I think TAG's httpRange-14 is the following logic.
> Representation=Resource if HTTP=200.
I'll just repeat here what I have said previously to you offline...

That is NOT the TAG's position.
> But Conneg breaks either the "equal" sign or the if clause.
I also believe that you continue to be confused about how Conneg is 
intended to be used.
> Xiaoshu

Received on Saturday, 12 April 2008 11:14:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:21 UTC