Re: HTTP Range Middle ground?

I don't understand most of what you wrote but...

Bill de hÓra wrote:
> Paul Prescod wrote:
> 
> 
>> Yes, it would be natural to say that the responder "represents" the 
>> person but we already have a meaning for that word. Representations 
>> are the things that go across the wire. Let's say that the HTTP 
>> resource proxies for the real-world resource.
> 
> That's not natural at all, to my mind. And what if the responder is a 
> web site, not a server? 

I don't follow. Web sites are served by servers. The responder is just 
the responder. It is a thing that listens for HTTP methods and does 
stuff. If RDF is to reason about these things then we need to 
distinguish them (whether in URI syntax or RDF assertions or otherwise) 
from objects that they may be proxies for like robots or human beings.

> ... Norm's example works for his network, and mine. 
> It does make sense for many of my customers. Please, this only gets 
> worse through use. What stops me declaring another URI as denoting a 
> specific server, or cluster, or site?

I don't understand anything you said there.

> ... 
> 
> I vehemently do not need, or want, anyone telling me what the syntactic 
> convention is for distinguishing Aurelius my computer from Aurelius the 
> Emperor. Or Richard Harris. 

I don't think anyone would suggest different syntaxes for Aurelius the 
computer versus Aurelius the Emporer. But some would say that it would 
bad practice to use an HTTP URI to represent either of them and at the 
same time use that URI to represent an HTTP responder that proxies for 
them because how would you decide which properties apply to the proxy 
and which to the proxied object?

> ... I can establish that by examining the 
> intersection of statement properties, (yes Pat, I know they have no 
> special standing), or inferring to the best possible explanation, if I 
> or anyone else cared to write the code, or port someone else's.

Sorry. Don't understand.

> ...
> No, we're trying to decide if the URIs canonically denote a particular 
> class of entity. 

Well we obviously have different interpretations of what we are discussing.

IMO, each URI denotes a particular entity. It is obviously bad for a 
single URI to address two entities. That's Fact 1.

SW folks are encouraged use HTTP URIs so we can address a responder in 
addition to identifying a logical SW entity. Fact 2.

We are using the address of one resource as the name of another resource 
because it is convenient and has important network effects. But what if 
we need to talk about the responder. What is its name?

I see this as being the issue.

> ... that's tricky because a) today there are no classes of 
> entity in web or semantic web architecture, there are just resources,

There are some resources that we expect to respond to 
GET/PUT/POST/DELETE and other resources (like the emperor) that we do 
not. This strikes me as undeniable. Or to put it another way, at the 
HTTP level, two URIs should only be said to address the same resource if 
the behaviour of the two is indistinguishable in terms of HTTP messages. 
But at the Semantic Web level it might make perfect sense to say that 
these two URIs name the same resource:

http://www.dictionary.com/Aurelius#
http://www.encarta.com/Aurelius#

Even if their HTTP behaviour is totally different. Is it equally valid 
to say that these two URIs represent the same resource:

http://www.dictionary.com/Aurelius
http://www.encarta.com/Aurelius

Maybe. But if so then how do I make an assertion that says that the HTTP 
responder resources are actually totally different (e.g. when it comes 
to caching, supported methods etc.)? I really don't care HOW that 
assertion is made but it seems clear to me that it should be STANDARIZED 
and not ad hoc.

> ... b) 
> when you do divide them, say into resources and information resources, 
> or servers and everything else, half the room house will disgree on the 
> split.

Maybe so.

> Personally I'm not sure the TAG has to decide anything yet. It's the 
> business of RDF and its descendents to take care of interpretive 
> functions that map URIs to resources, not an ad-hoc syntactic 
> conventions that came about because everyone was fed up and design by 
> exhaustion set in.

The syntactic convention is out there and in use. The TAG merely needs 
to say that it works, is less confusing and causes no problems. Design 
by exhaustion is sometimes how it has to work. Otherwise we would still 
be arguing about whitespace in XML to this day.

  Paul Prescod

Received on Wednesday, 30 July 2003 15:50:08 UTC