W3C home > Mailing lists > Public > www-tag@w3.org > July 2003

Re: HTTP Range Middle ground?

From: Bill de hÓra <dehora@eircom.net>
Date: Wed, 30 Jul 2003 22:48:05 +0100
Message-ID: <3F283D15.6040404@eircom.net>
To: Paul Prescod <paul@prescod.net>
CC: www-tag@w3.org


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

So how are we to distinguish between a server, or a cluster running 
mod_backhand, or a CDN? We are constantly GETting representations of 
resources from other unamed (to us) resources.


>> ... 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'll try again. At what point you distinguish between a server and a 
cluster of servers acting as a logical server? That's the point - 
the syntactic convention won't stop at two classes of entity.

Btw, for anyone that thinks this is rarfied nonsense, with no 
practical bearing, it's not. The W3C ws architects have *exactly* 
the same problem in describing and naming services composed of 
services. It will be interesting to see how they close that issue. 
In fact it would make a fine use case over here.


> 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?

In the first case you don't have to. You just have to infer there is 
more than one resource, ideally as you pointed out by locating a 
contradiction and punting it to some software that can infer to the 
best explanation and possible force a redistibution of denotations. 
Or as you say, ask a person.

> Sorry. Don't understand.

Property based equivalence. Try this:

   <http://tap.stanford.edu/>

I believe the issue here is not so much identification of privileged 
entities, for some definition of 'identify'. It's getting your hands 
on the enough facts to come to a conclusion that we have a 
conflation of names.  How do I find the name of the entity or 
service I need? Agent folks sometimes call this the bootstrapping 
problem. There's nothing in the architecture for a semantic web DNS, 
though I /suspect/ that's meant to be the role of the current web.


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

That's more like opinion 1 ;)


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

Ok.


> 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?

Another URI, whichever it's been baptised with. The real question 
is, how do we find it?



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

It seems completely deniable. If someone declares that a URI 
denotates the Bald King of France and I GET against that URI, am I 
not in possession a representation of him?


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

Now *that's* an interesting idea. But I doubt the RDF community 
could make a model of it, or that they would want to - they have a 
model theory that works without allowing the neccessity of servers.



> 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

Unless it cannot be so for any possible world (distribution of 
resource to the URIs at hand), then yes.


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

At first thought you could say they are disjoint from other classes 
of resources. But I think I would do this by claiming that HTTP 
servers (can I use 'server' here?) have certain properties.

So I think what we are looking for is an ontology of the web 
architecture, a machine processable description of the entities, 
actors and their relations the TAG are actually discussing in their 
publications. Could be a good MSc topic for someone. Frank McCabe is 
doing something not a million miles away from this for ws-arch.

But I don't think you need a priori division of things in the 
Internet and things in the world the way the scholastics might have 
split heaven from earth - you just need a way to talk about such things.


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

Can't argue there :)

Bill de hÓra
Received on Wednesday, 30 July 2003 17:48:19 UTC

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